RockteMQ-AI commented on issue #10941: URL: https://github.com/apache/rocketmq/issues/10941#issuecomment-5370257737
Hi @Aias00, thanks for reporting this! I've analyzed this issue against the codebase and can confirm this appears to be a **real bug**. **Root Cause:** ** In `DefaultReceiptHandleManager.clearGroup` (line 253–254), `receiptHandleGroupMap.remove(key)` is called unconditionally *before* `returnHandleGroupWorkerService.submit(...)`. If the executor rejects the submission (queue full or shutting down), a `RejectedExecutionException` is thrown and propagates up — the group has already been removed from the map but the cleanup task never ran. There is no catch block to restore the entry, so the handle state is permanently lost and the next scheduled scan cannot retry. **Affected Files:** ** `proxy/src/main/java/org/apache/rocketmq/proxy/service/receipt/DefaultReceiptHandleManager.java` **Analysis:** ** The `returnHandleGroupWorkerService` is bounded (queue sized by `getRenewThreadPoolQueueCapacity()`). Under load or during shutdown the queue can fill, causing `submit()` to throw `RejectedExecutionException`. Since the remove happens on line 253 before the submit on line 254, and no exception handling exists, the lost group will never be re-added via the `putIfAbsent` path in `returnHandleGroup` (which is only reached if the task actually runs). The proxy permanently loses the receipt handles for that group. I'll prepare a fix spec and work on a PR. The community is welcome to provide feedback on the approach before implementation. --- 🤖 *Automated issue analysis by github-manager* -- 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]
