f1amingo opened a new issue, #11129: URL: https://github.com/apache/rocketmq/issues/11129
### Before Creating the Bug Report - [x] I found a bug, not just asking a question. - [x] I have searched the GitHub Issues and Discussions and believe this is not a duplicate. - [x] I have confirmed this bug belongs to the current repository. ### Runtime platform environment OS: Linux / macOS ### RocketMQ version branch: develop ### JDK Version Compiler: Oracle JDK 11 ### Describe the Bug When a broker serves Lite Topic pop requests with pop order lock release notification enabled, a dedicated timer (Netty HashedWheelTimer, backed by a non-daemon thread) is created but never shut down during the broker shutdown flow. On broker exit, Netty logs the "LEAK: HashedWheelTimer" warning, and if any timer task has ever been scheduled, the non-daemon thread prevents the JVM from exiting. ### Steps to Reproduce 1. Start a broker and enable pop order lock release notification (enableNotifyAfterPopOrderLockRelease). 2. Pop messages from a Lite Topic in a way that triggers the order lock notify path. 3. Shut down the broker. ### What Did You Expect to See? All timer resources are released during broker shutdown; no Netty LEAK warning is logged and the JVM exits normally. ### What Did You See Instead? Netty logs `LEAK: HashedWheelTimer was not shut down before it was garbage-collected; see https://netty.io/wiki/reference-counted-objects.html for more information.` ### Additional Context The Lite pop processor holds its own ConsumerOrderInfoManager instance (separate from the main one that IS shut down by BrokerController). Its internal lock manager creates the timer, and the Lite shutdown block only stops the lock manager and long-polling service. -- 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]
