fresh-borzoni commented on code in PR #3649:
URL: https://github.com/apache/fluss/pull/3649#discussion_r3595762706
##########
fluss-server/src/main/java/org/apache/fluss/server/coordinator/CoordinatorLeaderElection.java:
##########
@@ -186,18 +140,138 @@ public void notLeader() {
public void close() {
LOG.info("Closing LeaderLatch for server {}.", serverId);
- if (leaderLatch != null) {
+ if (closing.compareAndSet(false, true)) {
try {
leaderLatch.close();
} catch (Exception e) {
LOG.error("Failed to close LeaderLatch for server {}.",
serverId, e);
}
+
+ // Events submitted after closing starts are ignored by their
executor-side check.
+ // Since the executor is single-threaded, this task runs after all
leadership work
+ // already queued before close and completes only after leader
cleanup has finished.
+ leaderCallbackExecutor.execute(
+ () -> {
+ try {
+ boolean cleanupRequired = state == State.LEADER;
+ state = State.CLOSED;
+ if (cleanupRequired) {
+ cleanupLeaderServices(null);
+ }
+ } finally {
+ closeFuture.complete(null);
+ }
+ });
}
- leaderCallbackExecutor.shutdownNow();
+ closeFuture.join();
Review Comment:
Think my earlier "can't hang" only covered init - cleanup takes lock and
shuts down the event processor / channel manager, none of which are
curator-bounded, so close() can now block the shutdown thread until it's
SIGKILL'd.
The callback threads are daemon and old close() didn't wait at all, so maybe
just bound the wait (timeout on join) and move on? shutdownNow() won't help if
it's stuck on lock anyway. wdyt?
btw there are two waits here - join() and
awaitCallbackExecutorTermination(). Both need bounding, else the hang just
moves to the second one.
--
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]
