RockteMQ-AI commented on issue #11129: URL: https://github.com/apache/rocketmq/issues/11129#issuecomment-5630787116
**Issue Evaluation** Category: `type/bug` | Status: **Confirmed** The reported issue has been verified against the current codebase on the `develop` branch. **Root Cause:** `PopLiteMessageProcessor` creates its own `MemoryConsumerOrderInfoManager` instance (line 95), which extends `QueueLevelConsumerManager` and internally holds a `QueueLevelConsumerOrderInfoLockManager` with a `HashedWheelTimer` (non-daemon thread). During broker shutdown in `BrokerController`, the shutdown block only calls: - `popLiteMessageProcessor.stopPopLiteLockManager()` — stops the `PopLiteLockManager` ServiceThread - `popLiteMessageProcessor.getPopLiteLongPollingService().shutdown()` — stops long polling But it **never** shuts down the Lite processor's internal `MemoryConsumerOrderInfoManager`. The main `BrokerController.consumerOrderInfoManager` IS shut down, but the Lite processor's separate instance is not. **Impact:** - Netty logs `LEAK: HashedWheelTimer was not shut down before it was garbage-collected` - If any timer task was scheduled, the non-daemon thread prevents JVM exit during broker shutdown **Severity:** Medium — resource leak on shutdown; does not affect runtime message processing but blocks clean JVM exit. **Suggested Fix:** Add a call to shut down the Lite processor's `ConsumerOrderInfoManager` in the broker shutdown flow, alongside the existing `stopPopLiteLockManager()` call in `BrokerController`. An automated fix proposal can be generated. Reply `/approve` to proceed with PR generation. --- *Automated evaluation by RockteMQ-AI* -- 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]
