tju-yxq opened a new issue, #3043: URL: https://github.com/apache/rocketmq-dashboard/issues/3043
## Problem `InstanceService.listInstances` runs per-instance topic and consumer-group counts on a fixed executor and applies a shared three-second deadline. The worker still mutates the `InstanceVO` directly, however. If a cloud SDK ignores `Future.cancel(true)` while an HTTP request is in flight, the list call marks that row unavailable and returns, but the worker can later finish and change the already-returned object back to available with new counts. The executor is also created with `Executors.newFixedThreadPool`, whose work queue is unbounded. Repeated or concurrent list requests can therefore enqueue more count jobs behind providers that do not respond promptly, including jobs that callers have already timed out and cancelled. A latch-based reproduction is deterministic: block `countTopics`, ignore the timeout interrupt, let `listInstances` return an unavailable row, then release the provider. The same returned row currently changes after the request has completed. ## Expected behavior - count jobs should produce detached results rather than mutate response objects from worker threads; - only results completed within the batch deadline should be applied; - the executor queue should be bounded, with saturated rows degraded to unavailable rather than allowing backlog growth; - timeout, caller interruption, and shutdown should cancel outstanding work without allowing late results to alter the response. This is a follow-up to the shared-deadline change in #2525: that change bounds one request's wait time, while this issue covers job lifetime, late mutation, and backlog bounds. -- 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]
