Before Creating the Bug Report
Runtime platform environment
- GitHub Actions
ubuntu-latest, running the Build and Run Tests by Bazel workflow with remote execution.
- Local reproduction: macOS 15.7.7 arm64, OpenJDK 21.0.12, Maven 3.9.9.
RocketMQ version
JDK Version
- Local reproduction: OpenJDK 21.0.12
- The Bazel workflow uses its configured Java toolchain and does not explicitly pin a JDK in the workflow file.
Describe the Bug
BrokerShutdownTest contains four test methods, and every method creates, initializes, starts, and shuts down a complete BrokerController. A broker shutdown serially stops Netty event executors, message-store services, POP services, timer services, and many background executors.
The four methods therefore repeat the same expensive lifecycle even though two of them do not add meaningful shutdown-path coverage:
testChainedShutdownOrdering does not verify ordering; its two AtomicBoolean variables are unused and it ends with assertThat(true).isTrue().testResourceCleanupDuringShutdown only checks that components are non-null before shutdown and performs a second shutdown without asserting the final message-store state.
In a local JDK 21 reproduction, the complete class took 82.6 seconds. Running only the synchronous graceful-shutdown and asynchronous shutdown scenarios took 39.96 seconds. The GitHub Actions Bazel target timed out after 61.6 seconds under its default small classification.
This is related to, but distinct from, #10822: that issue adjusts the Bazel test-size classification, while this issue improves the test itself so it can complete within the small timeout with meaningful assertions.
Steps to Reproduce
Run the full test class:
mvn -pl broker -am \
-Dtest=BrokerShutdownTest \
-DfailIfNoTests=false \
-DskipITs \
-Dspotbugs.skip=true \
-Djacoco.skip=true \
test
Or run the Bazel target:
bazel test --config=remote //broker:src/test/java/org/apache/rocketmq/broker/BrokerShutdownTest
What Did You Expect to See?
The test should cover synchronous shutdown, shutdown from another thread, resource cleanup, timeout handling, and repeated shutdown without unnecessarily starting four complete brokers. The class should reliably complete within the Bazel small timeout.
What Did You See Instead?
The test repeats the full broker lifecycle four times and can exceed 60 seconds:
//broker:src/test/java/org/apache/rocketmq/broker/BrokerShutdownTest TIMEOUT in 61.6s
Additional Context
Proposed optimization:
- Keep one synchronous graceful-shutdown lifecycle and merge resource-state and repeated-shutdown assertions into it.
- Keep one shutdown-from-another-thread lifecycle and propagate failures with
Future.get(timeout).
- Remove the placeholder ordering test, which currently does not assert ordering.
- Assert that the message store reaches
SHUTDOWN_OK after each shutdown.
- Keep the default broker configuration so POP, timer, Netty, storage, and other shutdown paths remain covered.
This reduces four complete broker lifecycles to two without changing production behavior, APIs, protocols, or persisted data.
Before Creating the Bug Report
Runtime platform environment
ubuntu-latest, running theBuild and Run Tests by Bazelworkflow with remote execution.RocketMQ version
developJDK Version
Describe the Bug
BrokerShutdownTestcontains four test methods, and every method creates, initializes, starts, and shuts down a completeBrokerController. A broker shutdown serially stops Netty event executors, message-store services, POP services, timer services, and many background executors.The four methods therefore repeat the same expensive lifecycle even though two of them do not add meaningful shutdown-path coverage:
testChainedShutdownOrderingdoes not verify ordering; its twoAtomicBooleanvariables are unused and it ends withassertThat(true).isTrue().testResourceCleanupDuringShutdownonly checks that components are non-null before shutdown and performs a second shutdown without asserting the final message-store state.In a local JDK 21 reproduction, the complete class took 82.6 seconds. Running only the synchronous graceful-shutdown and asynchronous shutdown scenarios took 39.96 seconds. The GitHub Actions Bazel target timed out after 61.6 seconds under its default
smallclassification.This is related to, but distinct from, #10822: that issue adjusts the Bazel test-size classification, while this issue improves the test itself so it can complete within the
smalltimeout with meaningful assertions.Steps to Reproduce
Run the full test class:
mvn -pl broker -am \ -Dtest=BrokerShutdownTest \ -DfailIfNoTests=false \ -DskipITs \ -Dspotbugs.skip=true \ -Djacoco.skip=true \ testOr run the Bazel target:
bazel test --config=remote //broker:src/test/java/org/apache/rocketmq/broker/BrokerShutdownTestWhat Did You Expect to See?
The test should cover synchronous shutdown, shutdown from another thread, resource cleanup, timeout handling, and repeated shutdown without unnecessarily starting four complete brokers. The class should reliably complete within the Bazel
smalltimeout.What Did You See Instead?
The test repeats the full broker lifecycle four times and can exceed 60 seconds:
Additional Context
Proposed optimization:
Future.get(timeout).SHUTDOWN_OKafter each shutdown.This reduces four complete broker lifecycles to two without changing production behavior, APIs, protocols, or persisted data.