Type Members

1.  trait Bulkhead extends AnyRef

   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.

2.  trait CircuitBreaker[-E] extends AnyRef

   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: 1) 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?

   2) Failure rate. When the fraction of failed calls in some sample period exceeds a threshold (between 0 and 1), the circuit breaker is tripped. The decision to trip the Circuit Breaker is made after every call (including successful ones!)

   CircuitBreaker can record the following metrics, if a non-empty set of MetricLabels is given:

   • rezilience_circuit_breaker_state: current state (0 = closed, 1 = half-open, 2 = open)
   • rezilience_circuit_breaker_state_changes: number of state changes
   • rezilience_circuit_breaker_calls_success: number of successful calls
   • rezilience_circuit_breaker_calls_failure: number of failed calls
   • rezilience_circuit_breaker_calls_rejected: number of calls rejected in the open state
3.  trait Policy[-E] extends AnyRef

   Represents a composition of one or more rezilience policies

4.  trait RateLimiter extends AnyRef

   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.

5.  trait Retry[-E] extends AnyRef
6.  trait SwitchablePolicy[E] extends Policy[E]

   A Policy that can be replaced safely at runtime

7.  trait Timeout extends AnyRef

   Applies a timeout to effects

   Applies a timeout to effects

   Just a thin wrapper around ZIO's retry mechanisms for easy composition with other Policys.

8.  trait TrippingStrategy extends AnyRef

   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