Copilot commented on code in PR #3659:
URL: https://github.com/apache/celeborn/pull/3659#discussion_r3214324172
##########
master/src/main/scala/org/apache/celeborn/service/deploy/master/Master.scala:
##########
@@ -1564,6 +1565,19 @@ private[celeborn] class Master(
override def initialize(): Unit = {
super.initialize()
logInfo("Master started.")
+
+ // Register a shutdown hook so that SIGTERM triggers a graceful stop.
+ ShutdownHookManager.get().addShutdownHook(
+ ThreadUtils.newThread(
+ new Runnable {
Review Comment:
`ShutdownHookManager.addShutdownHook(...)` without an explicit timeout will
use the global default timeout derived from
`celeborn.worker.graceful.shutdown.timeout` (via a new `CelebornConf`) rather
than a master-specific value. This can make master shutdown unexpectedly wait
up to that timeout if `stop()` blocks (e.g., during Raft close). Consider using
the overload that sets a timeout explicitly (and/or basing it on an HA-master
config) so shutdown behavior is predictable for master deployments.
##########
master/src/main/scala/org/apache/celeborn/service/deploy/master/Master.scala:
##########
@@ -1564,6 +1565,19 @@ private[celeborn] class Master(
override def initialize(): Unit = {
super.initialize()
logInfo("Master started.")
+
+ // Register a shutdown hook so that SIGTERM triggers a graceful stop.
+ ShutdownHookManager.get().addShutdownHook(
+ ThreadUtils.newThread(
+ new Runnable {
+ override def run(): Unit = {
+ logInfo("Shutdown hook called for Master.")
+ stop(CelebornExitKind.EXIT_IMMEDIATELY)
+ }
Review Comment:
The shutdown hook comment says SIGTERM triggers a “graceful stop”, but it
calls `stop(CelebornExitKind.EXIT_IMMEDIATELY)`. Because `EXIT_IMMEDIATELY`
forces the HttpServer stop timeout to 0 (see `HttpServer.stopInternal`), this
can abruptly terminate in-flight HTTP requests. If the intent is graceful
draining, use a non-immediate exit kind (or introduce a master-specific
graceful exit kind) or update the comment to match the behavior.
##########
master/src/test/java/org/apache/celeborn/service/deploy/master/clustermeta/ha/RatisMasterStatusSystemSuiteJ.java:
##########
@@ -1872,6 +1872,66 @@ public void testReviseShuffles() throws
InterruptedException {
Assert.assertEquals(STATUSSYSTEM3.registeredShuffleCount(), 8);
}
+ @Test
+ public void testLeaderStepDownOnLogFailed() {
+ // Identify the current leader
+ HARaftServer leader = null;
+ for (HARaftServer server : Arrays.asList(RATISSERVER1, RATISSERVER2,
RATISSERVER3)) {
+ if (server.isLeader()) {
+ leader = server;
+ break;
+ }
+ }
+ Assert.assertNotNull("A leader should exist before the test", leader);
+ Assert.assertTrue("Leader node should report isLeader=true",
leader.isLeader());
+
+ // Do not stop() the shared static server used by the suite, since that
permanently
+ // closes one of RATISSERVER1/2/3 and can break later tests depending on
execution order.
+ // Instead, trigger the leader to step down without closing the underlying
server.
+ leader
+ .getMasterStateMachine()
+ .notifyLogFailed(new Exception("test leader graceful step down"),
null);
+
+ Assert.assertFalse(
+ "Leader should step down without closing the shared server",
leader.isLeader());
+ Assert.assertNotEquals(
+ "Raft server should remain available to the rest of the suite",
+ "CLOSED",
+ leader.getServer().getLifeCycleState().name());
Review Comment:
This assertion compares the Raft server lifecycle state to the string
literal "CLOSED". Using the enum value (e.g., `LifeCycle.State.CLOSED`) or the
existing `getServerState()` helper is less brittle and avoids failures if the
underlying enum name/state representation changes.
##########
master/src/main/java/org/apache/celeborn/service/deploy/master/clustermeta/ha/HARaftServer.java:
##########
@@ -628,13 +658,13 @@ void stepDown() {
REQUEST_TIMEOUT_MS);
Review Comment:
`stepDown()` uses a hard-coded `REQUEST_TIMEOUT_MS = 60_000` for the
transfer-leadership request, even though HA/Ratis timeouts are configurable in
`CelebornConf` (e.g., client RPC timeout / request timeout). Since this is now
part of the graceful shutdown path, consider deriving the timeout from the
relevant config so operators can tune stepdown behavior for their environments
instead of being fixed at 60s.
--
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]
