[Bug] Remoting sub-servers do not honor graceful shutdown

[qianye1001]

Runtime platform environment

macOS aarch64, JDK 11.

RocketMQ version

develop, commit d38f81e787.

Describe the Bug

Sub-servers created by NettyRemotingServer.newRemotingServer(port) do not honor the parent's graceful-shutdown configuration. SubRemotingServer.shutdown() sets its shutdown flag and immediately closes its listening channel. During the configured grace period, new connections therefore fail instead of receiving GO_AWAY responses for supported client versions.

Calling only the parent's shutdown() has another gap: it marks only the parent as shutting down, so sub-servers can continue processing requests until the shared event loops shut down. Concurrent shutdown calls also need coordination: a repeated call must not bypass the first call's grace period and close the listener or shared resources early.

Steps to Reproduce

1. Start a NettyRemotingServer with enableShutdownGracefully=true and shutdownWaitTimeSeconds=5.
2. Create and start sub-servers on other ports, and register a request processor on each server.
3. Establish a connection and send a request using a protocol version newer than V5_3_1.
4. Call a sub-server's shutdown() on another thread. During the grace period, send another request over the existing connection and try a fresh connection to that port.
5. Separately, call only the parent server's shutdown() and send requests to the sub-server ports during the grace period.

What Did You Expect to See?

A standalone sub-server shutdown keeps its listener available during the configured grace period and uses the existing GO_AWAY handling, without shutting down other ports or shared resources.

Each sub-server measures its own grace period from when it first enters the draining state. Repeated shutdown calls must not reset that deadline. A parent shutdown marks all its sub-servers as draining and waits until its own and all child grace periods have elapsed before releasing shared resources. Main/sub shutdowns and repeated calls may run concurrently; the independent grace periods must overlap rather than being waited one after another.

What Did You See Instead?

The standalone sub-server closes its listener immediately. Parent-only shutdown leaves sub-servers outside the draining state. A regression test on the unmodified commit times out waiting for a child to enter that state after parent shutdown starts.

[RockteMQ-AI]

Issue Evaluation

Category: bug | Status: Confirmed

The reported issue has been verified against the current codebase (commit d38f81e787).

Root Cause:
SubRemotingServer.shutdown() (line 762-770 in NettyRemotingServer.java) immediately closes its listening channel with only a 5-second await, without honoring the parent's enableShutdownGracefully or shutdownWaitTimeSeconds configuration. The parent's shutdown() method properly checks these settings and sleeps for the configured grace period before releasing resources.

Additionally:

• Sub-servers use isShuttingDown.set(true) instead of CAS, so concurrent shutdown calls aren't coordinated
• The parent's shutdown() only marks itself as shutting down, leaving sub-servers to continue processing until shared event loops shut down
• No GO_AWAY response handling in sub-servers during the grace period

Impact: Clients connecting to sub-server ports during graceful shutdown will experience connection failures instead of receiving proper GO_AWAY responses, breaking the graceful shutdown contract.

Severity: Medium - affects production deployments using graceful shutdown with multiple ports

Affected Files:

• remoting/src/main/java/org/apache/rocketmq/remoting/netty/NettyRemotingServer.java (SubRemotingServer inner class)

An automated fix proposal will be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by RockteMQ-AI

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The issue is valid. SubRemotingServer.shutdown() bypasses the parent's graceful-shutdown configuration entirely:

1. Missing grace period: The sub-server sets its shutdown flag and immediately closes the listening channel, without waiting for the configured shutdownWaitTimeMs.
2. No GO_AWAY response: During the grace period, new connections should receive GO_AWAY responses for supported client versions, but the sub-server just drops them.
3. Inconsistent behavior: Clients connected to the sub-server port experience abrupt disconnection during rolling restarts, while clients on the main port get graceful handling.

The proposed fix — propagating gracefulShutdown flag and shutdownWaitTimeMs to SubRemotingServer — is correct. Additional note: the SubRemotingServer should also register its ChannelFuture with the parent's shutdown hook to ensure ordered teardown.

An automated fix proposal may be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by github-manager