Stopping the server after a failed startup hangs on Derby
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 65/100
Hướng nghiên cứu
Start with Mirth.startup(), Mirth.shutdown(), and the shutdown-hook registration in Mirth.run(), then inspect the engine and database shutdown calls involved in the Derby path. Reproduce with a fresh Derby install, an invalid SCHEMA_INFO.VERSION, failed startup, and SIGTERM as described. Done means startup failure leaves no engine/database shutdown work that requires a connection, and the process exits promptly without writing the shutdown event; verify both Derby and PostgreSQL behavior where possible.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
After a startup failure such as a MigrationException, the process keeps running (#498). Stopping it normally runs the JVM shutdown hook, which calls Mirth.shutdown() as if the server had started. That stops the engine, which reads from the database, and dispatches a "Server shutdown" event, which a separate listener thread writes to the EVENT table.
- Derby: the hook hangs. Startup already shut Derby down, so the engine waits for a pooled connection that never comes. The process has to be killed with SIGKILL.
- PostgreSQL: the process exits about 2 seconds after SIGTERM. With
log_statement = 'all', the only statements from the hook were a read-onlySELECT VALUEfromCONFIGURATION, run while stopping the engine. No "Server shutdown" event was written in two runs. The event is inserted by theAuditableEventListenerthread, so the JVM halting first is timing, not design; on a slower shutdown the insert could reach a database that startup refused to migrate.
MySQL, Oracle and SQL Server were not tested; they share the PostgreSQL path, because stopDatabase() only acts on Derby.
Steps to reproduce
With the default Derby database, from the server's install directory:
- Start a fresh install once so the database is created, then stop it (Ctrl+C once startup has finished):
./oieserver - With the server stopped, force a migration failure by setting a schema version this release doesn't know:
java -cp 'server-lib/database/*' org.apache.derby.tools.ij <<'EOF' connect 'jdbc:derby:appdata/mirthdb'; UPDATE SCHEMA_INFO SET VERSION = '99.0.0'; exit; EOF - Start the server again. Startup fails and the process keeps running (#498):
The migration fails with or without the fix for #496 (unrecognized schema version). Only the logged error differs../oieserver - Press Ctrl+C, or send SIGTERM to the Java process.
Expected
The process exits promptly without touching the database.
Actual (Derby)
The log shows shutting down mirth due to normal request and nothing more. The process was still running more than three minutes later, and SIGKILL was needed. The shutdown hook thread was parked in HikariCP (2.5.1) waiting for a connection:
HikariPool.getConnection
...
DefaultConfigurationController.getProperty(DefaultConfigurationController.java:1029)
DefaultConfigurationController.getChannelDependencies(DefaultConfigurationController.java:1132)
ChannelDependencyServerUtil.getOrderedChannels(ChannelDependencyServerUtil.java:30)
DonkeyEngineController.undeployChannels(DonkeyEngineController.java:462)
DonkeyEngineController.stopEngine(DonkeyEngineController.java:275)
Mirth.stopEngine(Mirth.java:461)
Mirth.shutdown(Mirth.java:417)
Mirth$ShutdownHook.run(Mirth.java:531)
No new row was written to EVENT on Derby, and SCHEMA_INFO was unchanged.
Cause
The MigrationException handler in Mirth.startup() calls stopDatabase() (which only shuts down Derby) and returns. The ShutdownHook registered in Mirth.run() then calls shutdown() unconditionally. shutdown() assumes a started server: it stops the engine, opens a database session to dispatch the "Server shutdown" event, and stops the web server, plugins and database.
On Derby the wait never ends because HikariConnectionPool sets connectionTimeout to 0, which HikariCP treats as no timeout. Once Derby is shut down, no connection can be created, so the hook waits forever.
A port conflict doesn't reach this path, because Mirth.run() returns before the hook is registered.
Suggested fix
Track whether startup completed, and have shutdown() skip stopping the engine and dispatching the event when it did not. Fix this together with #498. Making the process exit on a startup failure means calling System.exit, which runs this hook, so on Derby that fix would hang here unless this one lands with it.
🤖 Drafted with Claude Code
- Ngôn ngữ chính
- Java
- Star
- 227
- Fork
- 81
- Merge trung bình
- 3 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 15
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của OpenIntegrationEngine/engine
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
OpenIntegrationEngine/engine#485 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
OpenIntegrationEngine/engine#478 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
OpenIntegrationEngine/engine#355 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
OpenIntegrationEngine/engine#347 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Fix call-home in test runĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
OpenIntegrationEngine/engine#313 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của OpenIntegrationEngine/engine
Issue tương tự
-
enhancement Improvement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
zowe/zowe-client-java-sdk#647 ·
-
NullPointerException when a `DeserializationProblemHandler` returns `null` for `byte[]` (single value unwrapped) and `char[]` elementsCó thể đã có người làm @Marti2203 đã nhận hôm nay. Đang mở
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 88/100
FasterXML/jackson-databind#6300 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
content good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 95/100
cpinitiative/usaco-guide#6699 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
BC remittance upload: a claim MSP refused (S03) is saved with a blank status instead of refused (F)Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởtype: bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
carlos-emr/carlos#4933 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[studio] Data source connection tests leak loading and results across modal sessionsCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
apache/rocketmq-dashboard#6925 ·
Maintainer thường phản hồi trong vòng 3 ngày