Description
Understanding how Rate limter works it we use limiter.tryAcuire() methods
- Configured Rate: 1000 permits/second → effectively 1 permit every 1 millisecond (ms).
Timeline Example:
-
t = 0 ms: The token bucket is initially empty and starts filling — 1 permit per ms.
-
t ≈ 1 ms: 1 permit is available.
- Request A calls
tryAcquire()
→ succeeds, consumes 1 permit → bucket is empty.
- Request A calls
-
t = 1.2 ms:
- Request B arrives → fails, since only 0.2 ms has passed and no new permit is available.
-
t = 2 ms: Another permit becomes available.
- Request C at t = 2.1 ms → succeeds.
This continues as per the configured rate.
Here is the some value of variable during drop
DENIED ] permits=1, nowMicros=2086708445, nextFreeTicketMicros=2086708739, storedPermits=0.000, timeout=0 ?s
Since nowMicros < nextFreeTicketMicros there for below method return zero
private boolean canAcquire(long nowMicros, long timeoutMicros) {
return queryEarliestAvailable(nowMicros) - timeoutMicros <= nowMicros;
}
So this issue might be due to permits deny because number of requests comes more with in milliseconds. i.e sudden brust.
It would be helpful if someone provide any solution without adding any latency in code.
Is similar issue is reported by anyone let us know
Thank you.