fuyou001 opened a new issue, #10823: URL: https://github.com/apache/rocketmq/issues/10823
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in GitHub Discussions. - [x] I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### 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 - Branch: `develop` - Observed workflow run: https://github.com/apache/rocketmq/actions/runs/31065433437/job/92502049511 ### 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: ```shell mvn -pl broker -am \ -Dtest=BrokerShutdownTest \ -DfailIfNoTests=false \ -DskipITs \ -Dspotbugs.skip=true \ -Djacoco.skip=true \ test ``` Or run the Bazel target: ```shell 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: ```text //broker:src/test/java/org/apache/rocketmq/broker/BrokerShutdownTest TIMEOUT in 61.6s ``` ### Additional Context Proposed optimization: 1. Keep one synchronous graceful-shutdown lifecycle and merge resource-state and repeated-shutdown assertions into it. 2. Keep one shutdown-from-another-thread lifecycle and propagate failures with `Future.get(timeout)`. 3. Remove the placeholder ordering test, which currently does not assert ordering. 4. Assert that the message store reaches `SHUTDOWN_OK` after each shutdown. 5. 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. -- 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]
