[I] Throughput of in-flight message renewal degrades while some handle data locks have expired [rocketmq]

["redlsz (via GitHub)" <gi...@apache.org>]

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: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org