RockteMQ-AI commented on issue #11433: URL: https://github.com/apache/rocketmq/issues/11433#issuecomment-6163839224
**Issue Evaluation** Category: `type/bug` | Status: **Confirmed** The reported issue has been verified against the current codebase. **Root Cause:** Two race conditions in `PopLiteLongPollingService` cause suspended lite long-polling requests to become unreachable after being admitted: 1. **Race with `cleanUnusedResource()`:** Between `pollingMap.get()` and `queue.add()` in `polling()`, the cleanup thread can remove the empty queue entry. The request is then added to an orphaned queue that neither `notifyMessageArriving()` nor the timeout sweep can find. 2. **Capacity eviction in `polling()`:** When the queue is full, the request is returned to the caller without ever being suspended, but the caller treats it as suspended. **Impact:** Affected clients experience indefinite hangs on lite long-polling requests. The classic `PopLongPollingService` does not have this race because its cleanup checks topic/group meta before removing. **Severity:** medium — availability/latency defect for lite pop consumers. **Fix direction:** - In `polling()`: after a successful `queue.add()`, re-check that the queue is still in `pollingMap`; if not, wake the request immediately. - In `cleanUnusedResource()`: before removing an empty queue, verify no in-flight `polling()` call is about to add to it (or adopt the classic pattern of checking meta). - For capacity eviction: when the queue is full, return `POLLING_FULL` instead of silently dropping. An automated fix proposal will be generated. Reply `/approve` to proceed with PR generation. --- *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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
