RockteMQ-AI commented on issue #2580: URL: https://github.com/apache/rocketmq-dashboard/issues/2580#issuecomment-5410797116
## Bot Evaluation **Classification:** Bug — Performance / Scalability **Severity:** MEDIUM-HIGH **Status:** ✅ Confirmed ### Verification Code verified on `rocketmq-studio` branch. **Issue 1 — Unbounded alert listing:** `AlertService.listAlerts()` (line 222) delegates to `alertRepository.findAlerts(level)` which returns the full result set with no pagination, no bounded page size, and no server-side total count. **Issue 2 — O(n) scan for single-row acknowledge:** `AlertService.acknowledgeAlert(Long id)` (line 228) calls `alertRepository.findAlerts(null)` to load **every** alert into memory, then performs a linear stream filter to locate one row by primary key. This is an O(n) operation for what should be an O(1) primary-key lookup. ### Assessment Both problems are real and will degrade as the `rmq_system_alert` table grows. The acknowledge path is particularly wasteful — it performs a full table scan to update a single row. ### Suggested Fix Direction 1. Add a paginated `findAlertsPage(level, page, pageSize)` repository method with DB-level filtering, ordering, and `LIMIT/OFFSET`. 2. Add `findById(Long id)` to `AlertRepository` for direct primary-key lookup in the acknowledge path. 3. Keep the existing unpaginated endpoint for backward compatibility. 4. Frontend: switch Alert Events page to server-driven pagination with `items`, `total`, `page`, `size` response contract. --- *Evaluated by github-manager bot · [issue-evaluator]* -- 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]
