RockteMQ-AI commented on issue #11383:
URL: https://github.com/apache/rocketmq/issues/11383#issuecomment-6129826214
**Issue Evaluation**
Category: `type/bug` | Status: **Confirmed**
The reported issue has been verified against the current codebase
(develop@b764205).
**Root Cause:** Multiple pop/ack paths use bare busy-wait loops (`while
(!tryLock()) {}`) without `Thread.yield()`, pinning CPU threads at 100% during
lock contention.
**Verified Locations:**
- `AckMessageProcessor.java:405` — `queueLockManager.tryLock(lockKey)` in
`ackOrderly`
- `AckMessageProcessor.java:448` —
`consumerLockService.tryLock(consumeGroup, topic)` in `ackOrderly` (KV path)
- `AckMessageProcessor.java:538` — `consumerLockService.tryLock(lockKey)` in
`ackLite`
- `ChangeInvisibleTimeProcessor.java:203, :235, :389` — same pattern in
`changeInvisibilityDuration`
**Impact:** Under `(group, topic)` contention, multiple `ackMessageExecutor`
workers can spin simultaneously, reducing effective parallelism. On
core-saturated brokers, spinning threads compete with lock holders, extending
wait times.
**Correct Pattern:** `PopConsumerService#tryLockForPop` (line 480-497)
already implements the correct pattern with `Thread.yield()` inside the spin
loop.
**Severity:** Medium — performance/fairness issue, not data loss. Practical
impact depends on real-world lock contention frequency.
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]
