Releases: kasapdev/java-rate-limiter
Releases · kasapdev/java-rate-limiter
Release list
v1.3.0
Added
LeakyBucketRateLimiter— a new rate limiting strategy, distinct from the existing token-bucket and sliding-window limiters. The bucket starts empty and each admittedtryAcquire()call raises its fill level by one, up to a fixedcapacity; the bucket continuously leaks (drains) at a constantleakRatePerSecond, computed lazily from elapsed wall-clock time (System.nanoTime()) on every call — no background thread, the same lazy-recompute approachTokenBucketRateLimiteruses for refill.LeakyBucketRateLimiter(int capacity, double leakRatePerSecond)boolean tryAcquire()int currentLevel()
- Test coverage: basic fill/exhaustion behavior, leak-rate math asserted against real measured elapsed time (no long sleeps), invalid-argument rejection, and two concurrency tests (zero-leak exact-capacity admission, and nonzero-leak admissions bounded by capacity + leaked-over-elapsed-time math), matching the style of the existing limiters' tests.
- README: new "Leaky Bucket Rate Limiter" section with a runnable example, a third Usage example, and updated API reference.
Fixed
- A bug caught while writing the concurrency test:
tryAcquire()originally admitted whenevercurrentLevel < capacity, but a level that had leaked to a hair under capacity (floating-point residue from a near-zero elapsed time between back-to-back calls) satisfied that check and then had a full unit added on top, pushing the level past capacity. Fixed to checkcurrentLevel + 1 <= capacity, with a dedicated tight-loop regression test added to lock it in.
See CHANGELOG.md for full details. Note: v1.2.0 was recorded in the changelog for a prior blocking-tryAcquire feature but was never tagged as a release, so this release jumps straight to v1.3.0 to keep the changelog and release history consistent.