Reference to Akka scheduler
Maximum number of failures before opening the circuit
scala.concurrent.duration.FiniteDuration of time after which to consider a call a failure
scala.concurrent.duration.FiniteDuration of time after which to attempt to close the circuit
scala.concurrent.ExecutionContext used for execution of state transition listeners
(Since version 2.5.12) Use the overloaded one which accepts java.time.Duration instead.
JavaAPI for onCallBreakerOpen.
JavaAPI for onCallBreakerOpen.
Handler to be invoked on call failed due to open breaker.
CircuitBreaker for fluent usage
JavaAPI for onCallFailure
JavaAPI for onCallFailure
Handler to be invoked on failed call, where passed value is elapsed time in nanoseconds.
CircuitBreaker for fluent usage
JavaAPI for onCallSuccess
JavaAPI for onCallSuccess
Handler to be invoked on successful call, where passed value is elapsed time in nanoseconds.
CircuitBreaker for fluent usage
JavaAPI for onCallTimeout
JavaAPI for onCallTimeout
Handler to be invoked on call finished with timeout, where passed value is elapsed time in nanoseconds.
CircuitBreaker for fluent usage
JavaAPI for onClose
JavaAPI for onClose
Handler to be invoked on state change
CircuitBreaker for fluent usage
JavaAPI for onHalfOpen
JavaAPI for onHalfOpen
Handler to be invoked on state change
CircuitBreaker for fluent usage
Java API for onOpen
Java API for onOpen
Handler to be invoked on state change
CircuitBreaker for fluent usage
Java API for #withCircuitBreaker
Java API for #withCircuitBreaker
Call needing protected
function that define what should be consider failure and thus increase failure count
scala.concurrent.Future containing the call result or a
scala.concurrent.TimeoutException
if the call timed out
Java API for #withCircuitBreaker
Java API for #withCircuitBreaker
Call needing protected
scala.concurrent.Future containing the call result or a
scala.concurrent.TimeoutException
if the call timed out
Java API (8) for #withCircuitBreaker
Java API (8) for #withCircuitBreaker
Call needing protected
function that define what should be consider failure and thus increase failure count
java.util.concurrent.CompletionStage containing the call result or a
scala.concurrent.TimeoutException
if the call timed out
Java API (8) for #withCircuitBreaker
Java API (8) for #withCircuitBreaker
Call needing protected
java.util.concurrent.CompletionStage containing the call result or a
scala.concurrent.TimeoutException
if the call timed out
Java API for #withSyncCircuitBreaker.
Java API for #withSyncCircuitBreaker. Throws java.util.concurrent.TimeoutException if the call timed out.
Call needing protected
function that define what should be consider failure and thus increase failure count
The result of the call
Java API for #withSyncCircuitBreaker.
Java API for #withSyncCircuitBreaker. Throws java.util.concurrent.TimeoutException if the call timed out.
Call needing protected
The result of the call
Mark a failed call through CircuitBreaker.
Mark a failed call through CircuitBreaker. Sometimes the callee of CircuitBreaker sends back a message to the caller Actor. In such a case, it is convenient to mark a failed call instead of using Future via withCircuitBreaker
Return true if the internal state is Closed.
Return true if the internal state is Closed. WARNING: It is a "power API" call which you should use with care. Ordinal use cases of CircuitBreaker expects a remote call to return Future, as in withCircuitBreaker. So, if you check the state by yourself, and make a remote call outside CircuitBreaker, you should manage the state yourself.
Return true if the internal state is HalfOpen.
Return true if the internal state is HalfOpen. WARNING: It is a "power API" call which you should use with care. Ordinal use cases of CircuitBreaker expects a remote call to return Future, as in withCircuitBreaker. So, if you check the state by yourself, and make a remote call outside CircuitBreaker, you should manage the state yourself.
Return true if the internal state is Open.
Return true if the internal state is Open. WARNING: It is a "power API" call which you should use with care. Ordinal use cases of CircuitBreaker expects a remote call to return Future, as in withCircuitBreaker. So, if you check the state by yourself, and make a remote call outside CircuitBreaker, you should manage the state yourself.
Adds a callback to execute when call was failed due to open breaker.
Adds a callback to execute when call was failed due to open breaker.
The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Handler to be invoked on call failed due to open breaker.
CircuitBreaker for fluent usage
Adds a callback to execute when call finished with failure.
Adds a callback to execute when call finished with failure.
The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Handler to be invoked on failed call, where passed value is elapsed time in nanoseconds.
CircuitBreaker for fluent usage
Adds a callback to execute when call finished with success.
Adds a callback to execute when call finished with success.
The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Handler to be invoked on successful call, where passed value is elapsed time in nanoseconds.
CircuitBreaker for fluent usage
Adds a callback to execute when call finished with timeout.
Adds a callback to execute when call finished with timeout.
The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Handler to be invoked on call finished with timeout, where passed value is elapsed time in nanoseconds.
CircuitBreaker for fluent usage
Adds a callback to execute when circuit breaker state closes
Adds a callback to execute when circuit breaker state closes
The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Handler to be invoked on state change
CircuitBreaker for fluent usage
Adds a callback to execute when circuit breaker transitions to half-open The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Adds a callback to execute when circuit breaker transitions to half-open The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Handler to be invoked on state change
CircuitBreaker for fluent usage
Adds a callback to execute when circuit breaker opens
Adds a callback to execute when circuit breaker opens
The callback is run in the scala.concurrent.ExecutionContext supplied in the constructor.
Handler to be invoked on state change
CircuitBreaker for fluent usage
scala.concurrent.duration.FiniteDuration of time after which to attempt to close the circuit
Mark a successful call through CircuitBreaker.
Mark a successful call through CircuitBreaker. Sometimes the callee of CircuitBreaker sends back a message to the caller Actor. In such a case, it is convenient to mark a successful call instead of using Future via withCircuitBreaker
Wraps invocations of asynchronous calls that need to be protected
Wraps invocations of asynchronous calls that need to be protected
Call needing protected
scala.concurrent.Future containing the call result or a
scala.concurrent.TimeoutException
if the call timed out
Wraps invocations of asynchronous calls that need to be protected
Wraps invocations of asynchronous calls that need to be protected
Call needing protected
function that define what should be consider failure and thus increase failure count
scala.concurrent.Future containing the call result or a
scala.concurrent.TimeoutException
if the call timed out
The resetTimeout
will be increased exponentially for each failed attempt to close the circuit.
The resetTimeout
will be increased exponentially for each failed attempt to close the circuit.
The default exponential backoff factor is 2.
the upper bound of resetTimeout
The resetTimeout
will be increased exponentially for each failed attempt to close the circuit.
The resetTimeout
will be increased exponentially for each failed attempt to close the circuit.
The default exponential backoff factor is 2.
the upper bound of resetTimeout
Wraps invocations of synchronous calls that need to be protected
Wraps invocations of synchronous calls that need to be protected
Calls are run in caller's thread. Because of the synchronous nature of
this call the scala.concurrent.TimeoutException
will only be thrown
after the body has completed.
Throws java.util.concurrent.TimeoutException if the call timed out.
Call needing protected
function that define what should be consider failure and thus increase failure count
The result of the call
Wraps invocations of synchronous calls that need to be protected
Wraps invocations of synchronous calls that need to be protected
Calls are run in caller's thread. Because of the synchronous nature of
this call the scala.concurrent.TimeoutException
will only be thrown
after the body has completed.
Throws java.util.concurrent.TimeoutException if the call timed out.
Call needing protected
The result of the call
JavaAPI for onClose
JavaAPI for onClose
Handler to be invoked on state change
CircuitBreaker for fluent usage
(Since version 2.5.0) Use addOnCloseListener instead
JavaAPI for onHalfOpen
JavaAPI for onHalfOpen
Handler to be invoked on state change
CircuitBreaker for fluent usage
(Since version 2.5.0) Use addOnHalfOpenListener instead
Java API for onOpen
Java API for onOpen
Handler to be invoked on state change
CircuitBreaker for fluent usage
(Since version 2.5.0) Use addOnOpenListener instead
Provides circuit breaker functionality to provide stability when working with "dangerous" operations, e.g. calls to remote systems
Transitions through three states: - In *Closed* state, calls pass through until the
maxFailures
count is reached. This causes the circuit breaker to open. Both exceptions and calls exceedingcallTimeout
are considered failures. - In *Open* state, calls fail-fast with an exception. AfterresetTimeout
, circuit breaker transitions to half-open state. - In *Half-Open* state, the first call will be allowed through, if it succeeds the circuit breaker will reset to closed state. If it fails, the circuit breaker will re-open to open state. All calls beyond the first that execute while the first is running will fail-fast with an exception.