iloveeyjafjalla opened a new issue, #11427: URL: https://github.com/apache/rocketmq/issues/11427
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/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 OS: any (client side, `DefaultMQPushConsumer`) ### RocketMQ version branch: develop Git commit id: a7edeecfb ### JDK Version Compiler: Temurin 1.8.0_504 (target 1.8, same as CI) ### Describe the Bug `DefaultMQPushConsumerImpl.start()` creates **and starts** two consume services, but `shutdown()` stops only the first one: ```java this.consumeMessageService.start(); // POPTODO this.consumeMessagePopService.start(); // DefaultMQPushConsumerImpl.java:984-986 ``` ```java case RUNNING: this.consumeMessageService.shutdown(awaitTerminateMillis); // :908 — the pop service is never stopped ``` The pop service is not idle after it is started: `ConsumeMessagePopOrderlyService.start()` schedules `lockMQPeriodically()` at a fixed rate on a single-thread executor created with `new ThreadFactoryImpl("ConsumeMessageScheduledThread_")` (`client/.../ConsumeMessagePopOrderlyService.java:64-77`), and `ThreadFactoryImpl` creates **non-daemon** threads by default (`common/.../ThreadFactoryImpl.java:35`, `:59`). `ConsumeMessagePopConcurrentlyService.start()` likewise starts its consume executor. Both services implement `shutdown(long)` (`ConsumeMessagePopOrderlyService.java:80-88`, `ConsumeMessagePopConcurrentlyService.java:70`), and no code in the client module ever calls it — the only references to the field are the two assignments, `start()` and `submitPopConsumeRequest`. The same omission exists in the failed-start branch, which stops only `consumeMessageService` when the consumer group is already registered (`DefaultMQPushConsumerImpl.java:991-993`). ### Steps to Reproduce 1. `DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("group"); consumer.subscribe("topic", "*"); consumer.registerMessageListener(listener);` 2. `consumer.start(); consumer.shutdown();` 3. The pop service is still running: for CLUSTERING (the default) the `ConsumeMessageScheduledThread_` thread keeps firing `lockMQPeriodically()` every `REBALANCE_LOCK_INTERVAL` on an empty process-queue table, the threads are non-daemon, so a JVM that relies on the consumer's shutdown to release its resources never terminates. At the unit level the existing harness covers it: `DefaultMQPushConsumerImplTest` already injects a mocked `consumeMessagePopService` (line ~250-254) and has a `testShutdown`, so asserting that the service is shut down with `shutdown()` fails deterministically today. ### What Did You Expect to See? `DefaultMQPushConsumer.shutdown()` "shut down this client and releasing underlying resources" (`client/.../consumer/DefaultMQPushConsumer.java:789`) — i.e. both consume services are stopped, exactly like the non-pop one in the same method. The pop services' own `shutdown(long)` methods are the proof that this was the intent. ### What Did You See Instead? After `shutdown()` the consumer's pop scheduler (and, for pop consumers, the pop consume executor) keeps running with non-daemon threads; the client appears stopped (`serviceState = SHUTDOWN_ALREADY`) while resources are still held, which can leave the JVM unable to exit. ### Additional Context Minimal fix: stop `consumeMessagePopService` next to `consumeMessageService` in both places — the normal shutdown path and the register-failure path. I will open a PR with those two one-line changes plus a regression test in `DefaultMQPushConsumerImplTest` (red before: the pop service receives no `shutdown` call). -- 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]
