nl.vroste.rezilience
Type members
Classlikes
Limits the number of simultaneous in-flight calls to an external resource
Limits the number of simultaneous in-flight calls to an external resource
A bulkhead limits the resources used by some system by limiting the number of concurrent calls to that system.
Calls that exceed that number are rejected with a BulkheadError
. To ensure good utilisation of the system, however,
there is a queue/buffer of waiting calls.
It also prevents queueing up of requests, which consume resources in the calling system, by rejecting calls when the queue is full.
- Companion
- object
CircuitBreaker protects external resources against overload under failure
CircuitBreaker protects external resources against overload under failure
Operates in three states:
-
Closed (initial state / normal operation): calls are let through normally. Call failures and successes update the call statistics, eg failure count. When the statistics satisfy some criteria, the circuit breaker is 'tripped' and set to the Open state. Note that after this switch, in-flight calls are not canceled. Their success or failure does not affect the circuit breaker anymore though.
-
Open: all calls fail fast with a
CircuitBreakerOpen
error. After the reset timeout, the states changes to HalfOpen -
HalfOpen: the first call is let through. Meanwhile all other calls fail with a
CircuitBreakerOpen
error. If the first call succeeds, the state changes to Closed again (normal operation). If it fails, the state changes back to Open. The reset timeout is governed by a reset policy, which is typically an exponential backoff.
Two tripping strategies are implemented:
- Failure counting. When the number of successive failures exceeds a threshold, the circuit breaker is tripped.
Note that the maximum number of failures before tripping the circuit breaker is not absolute under concurrent execution. I.e. if you make 20 calls to a failing system in parallel via a circuit breaker with max 10 failures, the calls will be running concurrently. The circuit breaker will trip after 10 calls, but the remaining 10 that are in-flight will continue to run and fail as well.
TODO what to do if you want this kind of behavior, or should we make it an option?
- Failure rate. When the fraction of failed calls in some sample period exceeds a threshold (between 0 and 1), the circuit breaker is tripped.
- Companion
- object
Represents a composition of one or more rezilience policies
Represents a composition of one or more rezilience policies
- Companion
- object
Limits the number of calls to a resource to a maximum amount in some interval
Limits the number of calls to a resource to a maximum amount in some interval
Uses a token bucket algorithm
Note that only the moment of starting the effect is rate limited: the number of concurrent executions is not bounded. For that you may use a Bulkhead
Calls are queued up in an unbounded queue until capacity becomes available.
- Companion
- object
A Policy that can be replaced safely at runtime
A Policy that can be replaced safely at runtime
- Companion
- object
Keeps track of successful calls and failures and determines when the circuit breaker should trip from Closed to Open state
Keeps track of successful calls and failures and determines when the circuit breaker should trip from Closed to Open state
Custom implementations are supported
- Companion
- object