Before Creating the Enhancement Request
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
Before Creating the Enhancement Request
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