iloveeyjafjalla opened a new issue, #11477: URL: https://github.com/apache/rocketmq/issues/11477
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in Apache RocketMQ, not a usage question. - [x] I can reproduce this on the current `develop` branch. ### RocketMQ Version develop @ `57c2dc04f78cc7e73e6b8c9436ee0fff0d0f46c3` (the revision this was verified on) ### Describe the Bug `BrokerContainer.initialize()` schedules its periodic work on one scheduler: ```java this.scheduledExecutorService.scheduleAtFixedRate(/* updateNamesrvAddr */, ...); // when namesrvAddr is set this.scheduledExecutorService.scheduleAtFixedRate(/* fetchNameServerAddr */, ...); // when fetching from the address server this.scheduledExecutorService.scheduleAtFixedRate( () -> BrokerContainer.this.brokerOuterAPI.refreshMetadata(), 10, 5, TimeUnit.SECONDS); // always ``` `shutdown()` stops the brokers, both remoting servers, the request executor and the outer API - but never that scheduler: ```java ThreadUtils.shutdown(this.brokerContainerExecutor); if (this.brokerOuterAPI != null) { this.brokerOuterAPI.shutdown(); } ``` So a shut-down container keeps its periodic tasks alive: every five seconds it calls `refreshMetadata()` on the `brokerOuterAPI` that `shutdown()` has just closed, logs ``` ScheduledTask refresh metadata exception ``` with the resulting exception, and never releases the scheduler thread - a container that is started and stopped repeatedly (the restart path the existing test exercises) accumulates one such thread per cycle. This is the same shape as #11427 and #11456: work started in `initialize()`/the constructor that the owner's shutdown never stops. ### Steps to Reproduce 1. Start a broker container (container mode with any broker registered, or just `BrokerContainerTest#testBrokerContainerRestart`'s `initialize() -> start() -> shutdown()`). 2. Call `shutdown()` and keep watching the log: `ScheduledTask refresh metadata exception` appears every five seconds afterwards. 3. `jstack` still shows the `BrokerContainerScheduledThread` running after `shutdown()` returned. The added test asserts the scheduler's `isShutdown()` right after `shutdown()`; with the current code it fails with `Expecting value to be true but was false`. ### What Did You Expect to See? `shutdown()` stops the scheduler it created in `initialize()`, so nothing of the container keeps running (and nothing keeps calling the closed `brokerOuterAPI`) after the shutdown. ### What Did You See Instead? The metadata-refresh task keeps running against the closed API and logs an error every five seconds; the scheduler thread is leaked. ### Additional Context `#11408` reports a different defect in the same class (the container never initializes its AuthConfig identity). The scheduler thread is a daemon, so the JVM still exits - the defect is the work that keeps running and the leaked thread, not a shutdown hang. -- 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]
