You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "tju-yxq (via GitHub)" <gi...@apache.org> on 2026/09/04 18:50:25 UTC

[I] DLQ group list waits for serial topic-stats RPCs and fires a request per keystroke [rocketmq-dashboard]

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: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] DLQ group list waits for serial topic-stats RPCs and fires a request per keystroke [rocketmq-dashboard]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] closed issue #3167: DLQ group list waits for serial topic-stats RPCs and fires a request per keystroke
URL: https://github.com/apache/rocketmq-dashboard/issues/3167


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] DLQ group list waits for serial topic-stats RPCs and fires a request per keystroke [rocketmq-dashboard]

Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #3167:
URL: https://github.com/apache/rocketmq-dashboard/issues/3167#issuecomment-5545262518

   **Issue Evaluation**
   
   Category: `enhancement` | Status: **Evaluated**
   
   **Feasibility:** Feasible
   **Scope:** `RocketMQDLQProvider.listDLQGroups()` (backend), DLQ search component (frontend)
   **Compatibility:** No breaking changes — internal performance improvement.
   
   This is a well-identified performance issue. The two problems are independent and both worth fixing:
   
   1. **Serial `examineTopicStats` calls** — With a page size of 20, the current code waits for 20 sequential admin RPCs. Bounding parallelism (e.g., `CompletableFuture` with a semaphore of 4–8) would cut wall-clock latency significantly while keeping deterministic ordering by collecting results into the original slot order.
   
   2. **Keystroke-triggered scans** — The search input fires a full backend scan on every character. Adding a debounce (300–500ms) on the input state change — while keeping the initial load and explicit search-submit immediate — would eliminate redundant scans without affecting UX.
   
   Both changes are localized and low-risk. A single topic-stats failure isolating to `UNAVAILABLE` for that row (while returning the rest) is also good defensive behavior.
   
   ---
   *Automated evaluation by @RockteMQ-AI*


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] DLQ group list waits for serial topic-stats RPCs and fires a request per keystroke [rocketmq-dashboard]

Posted by "Yanghanrui666 (via GitHub)" <gi...@apache.org>.
Yanghanrui666 commented on issue #3167:
URL: https://github.com/apache/rocketmq-dashboard/issues/3167#issuecomment-5755650895

   I would like to claim this issue. I will implement bounded parallel DLQ topic-stats loading with deterministic ordering and per-row UNAVAILABLE fallback, plus debounced search, with focused backend and frontend tests.
   
   /assign


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] DLQ group list waits for serial topic-stats RPCs and fires a request per keystroke [rocketmq-dashboard]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #3167:
URL: https://github.com/apache/rocketmq-dashboard/issues/3167#issuecomment-6159447803

   This issue has been automatically closed because there has been no activity for 7 days. If you believe this issue is still relevant, please reopen it with updated information.


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org