redlsz opened a new issue, #10225: URL: https://github.com/apache/rocketmq/issues/10225
### Before Creating the Enhancement Request - [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature. ### Summary In ReceiptHandleGroup.HandleData.lock(long timeoutMs), the current implementation always blocks for the full timeoutMs (default 3 seconds) on semaphore.tryAcquire(timeoutMs, ...) before checking whether the lock has expired. This means even when the lock holder has been stuck for well over the expiration threshold (9 seconds), the calling thread still wastes up to 3 seconds waiting on the semaphore before it discovers it can force-acquire via the expiration path. This unnecessary blocking impacts proxy throughput in scenarios like message renewal and could lead to significant duplicate consumptions due to untimely renewal. ### Motivation Optimize in-flight message renewal throughput in lock expired scenario. ### Describe the Solution You'd Like Add a non-blocking tryAcquire() as the fast path, and check the expiration condition before falling through to the blocking tryAcquire(timeout, unit) ### Describe Alternatives You've Considered / ### Additional Context _No response_ -- 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]
