github-actions[bot] commented on code in PR #69525:
URL: https://github.com/apache/doris/pull/69525#discussion_r4358373884
##########
fe/fe-core/src/main/java/org/apache/doris/persist/EditLog.java:
##########
@@ -265,8 +282,7 @@ private void flushEditLog() {
if (journal instanceof BDBJEJournal) {
LOG.error("BDBJE stats : {}", ((BDBJEJournal)
journal).getBDBStats());
}
- LOG.error("Fatal Error : write stream Exception", t);
- System.exit(-1);
+ exitOnWriteFailure(t);
Review Comment:
[P2] Signal BDB write failures before invoking shutdown
This handler is never reached for BDBJE's own fatal write paths:
`BDBJEJournal.write(JournalBatch)` calls `System.exit(-1)` directly on
`ReplicaWriteException` and after exhausting `DatabaseException` retries (lines
197/225), and direct writes do the same (301/317). Consequently `writeFailed`
stays false for those durable-write failures. An INSERT waiting for that
journal write keeps its coordinator registered, so `gracefulShutdown()` still
waits up to 300 seconds before stopping the query/RPC/HTTP services. The new
fast-shutdown behavior therefore misses these BDB failures. Route those exits
through the shared failure signal, or propagate them to this handler, and cover
an actual journal failure rather than only presetting the flag.
##########
fe/fe-core/src/main/java/org/apache/doris/DorisFE.java:
##########
@@ -725,7 +727,15 @@ public static boolean isServerReady() {
return serverReady.get();
}
- private static void gracefulShutdown() {
+ @VisibleForTesting
+ static void gracefulShutdown() {
+ if (EditLog.isWriteFailed()) {
Review Comment:
[P2] Recheck the failure signal while draining queries
The flag is sampled only on entry. If SIGTERM starts this hook while an
INSERT is still committing, and serialization or a journal write then fails,
`exitOnWriteFailure()` sets the flag after this check. The drain loop below
never reads it again, while the failed commit cannot finish and unregister its
coordinator. The hook consequently waits for the same 300-second timeout before
stopping services despite the fatal-write signal being true. Include the signal
in the loop's continuation condition (or wake the hook on failure), and test a
false-to-true transition after draining starts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
