Class KeyValueRateLimiter
- All Implemented Interfaces:
RateLimiter
Counts in the server's key/value store -- Redis once cn1.kv.url names one
-- so every process of a deployment shares one limit, at one round trip per
request and with no table to clean up.
http.rateLimit("/login", RateLimitKeys.clientAddress(),
new KeyValueRateLimiter("login", 5, 60));
A fixed window, as JdbcRateLimiter counts: permits requests in each
periodSeconds, counted from the first request of the window. A request is
one atomic increment of a counter that expires with its window, so two
processes counting at once cannot both take the last permit. A store that
cannot be reached refuses nobody, as the database limiter does not.
-
Constructor Summary
ConstructorsConstructorDescriptionKeyValueRateLimiter(KeyValueStore store, String name, int permits, long periodSeconds) A limiter instore; null means the calling thread's server's store.KeyValueRateLimiter(String name, int permits, long periodSeconds) A limiter in the calling thread's server's store. -
Method Summary
Modifier and TypeMethodDescriptionA limiter that keeps its counts where this one does, apart from this one's, with a limit of its own; null when this limiter cannot make one, which is what it answers unless it says more.voidForgets what was counted underkey, so the next request under it is counted from nothing.longretryAfterSeconds(String key) How many seconds a request just refused underkeyshould wait before trying again: what itsRetry-Aftersays.booleantryAcquire(String key) Counts one request underkey.
-
Constructor Details
-
KeyValueRateLimiter
A limiter in the calling thread's server's store.
name: what keeps this limiter's counts apart from another's; two limiters of one name share their counts on purpose
-
KeyValueRateLimiter
A limiter instore; null means the calling thread's server's store.
-
-
Method Details
-
derive
Description copied from interface:RateLimiterA limiter that keeps its counts where this one does, apart from this one's, with a limit of its own; null when this limiter cannot make one, which is what it answers unless it says more.
The parts of the layer that count something themselves -- attempts at a second factor, tries at a device's code -- ask the application's limiter bean for one each. That is how a bean declared to throttle an API at 600 a minute comes to count guesses at a one-time code at five in five minutes, in the same database, without the two sharing either a count or a limit.
- Specified by:
derivein interfaceRateLimiter- Parameters:
name- what keeps the new limiter's counts apartpermits- how many requests a key may make in a periodperiodSeconds- the length of the period
-
tryAcquire
Description copied from interface:RateLimiterCounts one request underkey.- Specified by:
tryAcquirein interfaceRateLimiter- Returns:
- whether the request is within the limit
-
reset
Description copied from interface:RateLimiterForgets what was counted under
key, so the next request under it is counted from nothing.A bound on wrong guesses uses this: the guess is counted before it is looked at, so that guesses made together cannot each be let through as the last one, and a right one hands the count back. A limiter that cannot forget does nothing here, which is what it does unless it says more; a right guess then costs what a wrong one does.
- Specified by:
resetin interfaceRateLimiter
-
retryAfterSeconds
Description copied from interface:RateLimiterHow many seconds a request just refused underkeyshould wait before trying again: what itsRetry-Aftersays. One second unless the limiter knows better.- Specified by:
retryAfterSecondsin interfaceRateLimiter
-