zmuxuny opened a new issue, #7168: URL: https://github.com/apache/rocketmq-dashboard/issues/7168
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version `rocketmq-studio` at `127c47b06a268cc74224d5f34c56ec7c36ac0d55`, built from source for focused tests. ### Runtime Environment Linux x86_64; deterministic provider tests. Database rows and broker replies are controlled fixtures. No MySQL or browser integration run is claimed. ### Connected RocketMQ Cluster No live cluster is required. The tests use `DefaultMQAdminExt` mocks with latch-controlled connection calls that ignore interruption, matching the existing late-result regressions in `RocketMQMetadataProviderTest`. ### Build Toolchain JDK 21.0.12.1, Maven 3.9.12, repository-pinned dependencies from a local offline cache. ### Describe the Bug Both consumer-group inventory endpoints call `RocketMQMetadataProvider.enrichLiveStats`. It submits each returned group to the shared eight-worker executor and waits up to one three-second batch deadline. Two exit paths fail to release queued work owned by the finished batch: - On timeout, `Future.cancel(true)` leaves cancelled FutureTasks in the ThreadPoolExecutor queue until a worker can dequeue them. Repeated pages can accumulate cancelled queue nodes while all workers remain occupied. - On caller interruption, the method restores the interrupt flag and returns without cancelling any unfinished Futures. Groups still queued at return later start broker reads that no caller is waiting for. The response snapshot isolation and batch deadline already work; the missing behavior is cleanup of tasks belonging to a finished request. ### Steps to Reproduce 1. Supply a normal page containing 20 consumer groups. 2. Block the first eight broker connection calls on a latch while allowing them to ignore cancellation. 3. Invoke the public `listConsumerGroupsPage` twice, allowing each call to return at its normal three-second deadline. 4. Inspect the shared executor's pending queue after each completed call: it contains 12 and then 32 cancelled entries. 5. Separately, call the public nonpaged list on a thread with the same 20-group fixture. Once eight tasks are running and twelve queued, interrupt the caller and confirm it returns with the interrupt flag preserved. 6. Release the blocked calls. The formerly queued `group-8` connection lookup still runs after the request returned. ### What Did You Expect to See? Every batch exit should cancel its unfinished work and remove its cancelled queued tasks. Tasks already in an interrupt-ignoring RPC may finish, but queued work belonging to the completed batch should not start later. Preserve the current response defaults and partial completed snapshots. ### What Did You See Instead? The two focused regressions fail on unchanged production source: - `timedOutGroupPagesShouldReleaseTheirQueuedTasksTest`: expected retained queue sizes `[0, 0]`, observed `[12, 32]`. - `interruptedGroupListShouldNotRunItsQueuedBrokerLookupsTest`: `NeverWantedButInvoked` for `examineConsumerConnectionInfo("group-8")`. Result: 2 tests, 2 failures, 0 errors; Checkstyle reports zero violations. ### Additional Context GET `/api/groups/page` defaults to 20 rows, and the consumer page's optional automatic refresh runs every two seconds. GET `/api/groups` uses the same enrichment method. The interruption test verifies the provider's cancellation boundary; it does not assume that browser disconnects interrupt servlet threads. This is separate from merged #4877 (one batch deadline), merged #5229 (late response mutation), and #5974/#7144 (the cancelled group's online-client sentinel). #3044 fixed an analogous lifetime problem in the separate instance resource-count runner. This report does not propose changing the existing stats/default-value contract discussed in #4361. The pool already bounds worker threads, and cancelled FutureTasks release their callable. These results establish retained queue nodes and unnecessary post-return reads, not an unbounded thread leak, a measured OOM, or a live-cluster outage. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
