tju-yxq opened a new issue, #3167: URL: https://github.com/apache/rocketmq-dashboard/issues/3167
## Problem The DLQ page fetches topic statistics for every group on the current page serially. `RocketMQDLQProvider.listDLQGroups(...)` slices the current page, then for each `%DLQ%` topic calls: ```java adminExt.examineTopicStats(dlqTopic) ``` one after another. With the default page size of 20, a page can therefore wait for 20 serial admin RPCs before returning. If brokers are slow, the page latency is roughly the sum of all stats calls. The frontend also updates the DLQ search input state on every keystroke. That state is in the effect dependency list, so every character starts a new full group-list request and immediately increments the request generation. On a large cluster, typing a short group name can trigger several expensive backend scans in quick succession. The request-generation guard prevents stale responses from overwriting newer results, but it does not prevent the redundant requests from being sent. ## Expected behavior - Topic-stats calls for one DLQ page should run with bounded parallelism, rather than one-by-one. - Page order should remain deterministic and unchanged. - A single topic-stats failure should only mark that row `UNAVAILABLE`; other rows should still be returned. - The DLQ search input should debounce requests while the user is typing. - Debouncing must not delay the initial page load or a direct search submission. ## Why this matters Operators open the DLQ page during incident triage. Waiting for serial stats RPCs or firing a scan per keystroke makes the page unnecessarily slow and increases load on brokers at exactly the time they may already be unhealthy. -- 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]
