failsafe v2.0 Release Notes
-
๐ Improvements
- ๐ [Policy composition](README.md#policy-composition) is now supported.
- [A Policy SPI](README.md#policy-spi) is now available.
- โฑ Async execution is now supported without requiring that a
ScheduledExecutorService
orScheduler
be configured. When no scheduler is configured, theForkJoinPool
's common pool will be used by default. - ๐
Fallback
now support async execution viaofAsync
. - ๐
CircuitBreaker
supports execution metrics (see below). - ๐ Strong typing based on result types is supported throughout the API.
Behavior Changes
- 0๏ธโฃ
RetryPolicy
now has 3 max attempts by default. - 0๏ธโฃ
CircuitBreaker
now has a 1 minute delay by default.
JRE Changes
- Java 8+ is now required
API Changes
Failsafe 2.0 includes a few API changes from 1.x that were meant to consolidate behavior such as the execution APIs, which are now based on common
Policy
implementations, while adding some new features such asPolicy
composition.- Policies
- Policy implementations now take a type parameter
R
that represents the expected result type. - Some of the time related policy configurations have been changed to use
Duration
instead oflong
+TimeUnit
.
- Policy implementations now take a type parameter
- ๐ง Policy configuration
- Multiple policies can no longer be configured by chaining multiple
Failsafe.with
calls. Instead they must be supplied in a singleFailsafe.with
call. This is was intentional to require users to consider the ordering of composed policies. See the README section on [policy composition](README.md#policy-composition) for more details.
- Multiple policies can no longer be configured by chaining multiple
- RetryPoilicy
- The
retryOn
,retryIf
, andretryWhen
methods have been replace withhandleOn
, etc.
- The
- CircuitBreaker
- The
failOn
,failIf
, andfailWhen
methods have been replace withhandleOn
, etc.
- The
- Fallbacks
- Fallbacks must be wrapped in a
Fallback
instance viaFallback.of
- Fallbacks must be wrapped in a
- Failsafe APIs
Supplier
s are now used instead ofCallable
s.java.util.function.Predicate
is used instead of Failsafe's internal Predicate.withFallback
is no longer supported. Instead,Failsafe.with(fallback...)
should be used.
- Async execution
- Async execution is now performed with the
getAsync
,runAsync
,getStageAsync
, etc. methods. - Async API integration is now supported via the
getAsyncExecution
,runAsyncExecution
, etc. methods.
- Async execution is now performed with the
- Event listeners
- Event listeners now all consume a single
ExecutionEvent
object, which includes references to the result, failure, and other information. - Event listeners that are specific to policies, such as
onRetry
forRetryPolicy
, must now be configured through the policy instance. The top levelFailsafe
API only supportsonComplete
,onSuccess
, andonFailure
. IndividualPolicy
implementations still supportonSuccess
andonFailure
in addition to policy specific events. - The top level
Failsafe.onSuccess
event listener will only be called if all configured policies consider an execution to be successful, otherwiseonFailure
will be called. - The
Listeners
class was removed, since it was mostly intended for Java 6/7 users. - The async event listener APIs were removed. Events will always be delivered in the same thread as the execution that they follow or preceed, including for async executions.
- Event listeners now all consume a single
- Java 8
java.time.Duration
is used instead of Failsafe's ownDuration
impl.ChronoUnit
is used instead ofTimeUnit
in policies.
ExecutionContext.getExecutions
is nowgetAttemptCount
.- โฑ
Schedulers.of(ScheduledExecutorService)
was moved to theScheduler
interface.
API Additions
CircuitBreaker
preExecute
is now exposed to support standalone usage.- Execution metrics are available via
getFailureCount
,getFailureRatio
,getSuccessCount
, andgetSuccessRatio
.
๐ Bug Fixes
- Issue #152 - Min/max delay was not being computed correctly