Class GuardRateLimiterRegistry
java.lang.Object
org.frontcache.guard.ratelimit.GuardRateLimiterRegistry
Holds the
WindowLimiter of every rate-limit bucket, keyed by bucket name.
Process-scoped on purpose. FrontCacheEngine.reload() constructs a new
GuardRuleEngine, and reload-guard-rules rebuilds the rule list; if the slot array lived in
the predicate, either would wipe every client's count - so an operator editing an unrelated rule
during an attack would hand every attacker a fresh window. This registry outlives both. Arrays
whose bucket is no longer referenced after a load are dropped by retain(Set), and an
array whose limit or window changed is rebuilt (its counts cannot be reinterpreted under a
different window).
Static state is otherwise hostile to tests, so reset() exists for them.-
Field Summary
Fields -
Method Summary
Modifier and TypeMethodDescriptionstatic Collection<WindowLimiter> static booleanstatic WindowLimiterlimiter(RateLimitSpec spec) The limiter for one bucket, created on first use and reused across reloads when its limit and window are unchanged - which is what makes counts survive a reload.static voidreset()for testsstatic voidDrops the limiters of buckets no longer named by any loaded rule.
-
Field Details
-
SLOTS_PROPERTY
- See Also:
-
MAX_TOTAL_SLOTS_PROPERTY
- See Also:
-
ENABLED_PROPERTY
- See Also:
-
-
Method Details
-
isEnabled
public static boolean isEnabled()- Returns:
- true unless the master switch is off. Read at load time - it is a property, so it applies at the next restart, like every other property-level switch in the pipeline.
-
limiter
The limiter for one bucket, created on first use and reused across reloads when its limit and window are unchanged - which is what makes counts survive a reload.- Throws:
GuardConfigException- when allocating it would exceed max-total-slots, so the offending rule is skipped with an error instead of the node running out of heap
-
retain
-
getLimiters
-
reset
public static void reset()for tests
-