All Versions
53
Latest Version
Avg Release Cycle
87 days
Latest Release
-
Changelog History
Page 3
Changelog History
Page 3
-
v2.3.0 Changes
August 16, 2019Behavior Changes
FailsafeExecutor.get
andFailsafeExecutor.run
will no longer wrapError
instances inFailsafeException
before throwing.
๐ Bug Fixes
- ๐ Fixed potential race between
Timeout
interrupts and execution completion.
-
v2.2.0 Changes
August 12, 2019๐ Improvements
- โ Added a new
Timeout
policy that fails withTimeoutExceededException
. - โ Added
ExecutionContext.isCancelled()
. - โ Added
ExecutionContext.getElapsedAttemptTime()
. - โฑ Made the internal delay scheduler more adaptive.
API Changes
- ๐ Deprecated
CircuitBreaker.withTimeout
in favor of using a separateTimeout
policy.
๐ Bug Fixes
- ๐ Reset interrupt flag when a synchronous execution is interrupted.
- ๐ Improved handling around externally completing a Failsafe
CompletableFuture
.
- โ Added a new
-
v2.1.1 Changes
July 29, 2019๐ Improvements
- โ Added support for
CircuitBreaker.withDelay(DelayFunction)
- โ Added
Fallback.ofException
for returning custom exceptions. - โ Added
ExecutionContext.getLastResult
and.getLastFailure
to support retries that depend on previous executions - โ Added
CircuitBreakerOpenException.getCircuitBreaker
API Changes
- ๐ฆ
RetryPolicy.DelayedFunction
was moved to thenet.jodah.failsafe.function
package. - โ Removed
RetryPolicy.canApplyDelayFn
- โ Added support for
-
v2.1.0 Changes
July 20, 2019๐ Improvements
- โ Added support for
Failsafe.with(List<Policy<R>>)
. - ๐ Allow
null
Fallback
values.
๐ Bug Fixes
- Issue #190 - Failure listener called on success for async executions.
- Issue #191 - Add missing listeners to RetryPolicy copy constructor.
- Issue #192 - Problem with detecting completion when performing async execution.
Behavior Changes
- A standalone or async execution will only be marked as complete when all policies are complete.
Execution.isComplete
reflects this.
- โ Added support for
-
v2.0.1 Changes
February 03, 2019๐ Improvements
- โ Added support for using
ExecutorService
viaFailsafeExecutor.with(ExecutorService)
. - โ Added interruptable cancellation for executions ran on
ForkJoinPool
viaCompletableFuture.cancel(true)
.
๐ Bug Fixes
- Issue #171 - Handle completed futures when using
getStageAsync
.
- โ Added support for using
-
v2.0 Changes
๐ 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
-
v1.1.1
November 23, 2018 -
v1.1.0 Changes
April 06, 2018๐ Bug Fixes
- Issue #115 - Jitter bigger than Delay causes a (random) failure at runtime
- Issue #116 - Setting jitter without a delay works fine bug
- Issue #123 - Ability to reset the jitterFactor
๐ Improvements
- ๐ Issue #110 - Added support for computed delays:
RetryPolicy.withDelay(DelayFunction)
- ๐ Issue #126 - Added support for random delays:
RetryPolicy.withDelay(1, 10, TimeUnit.MILLISECONDS)
-
v1.0.5 Changes
January 10, 2018๐ Bug Fixes
- Issue #97 - Should not increment exponential backoff time on first attempt
- Issue #92 -
handleRetriesExceeded
called incorrectly.
-
v1.0.4 Changes
April 02, 2017API Changes
- ๐ Asynchronous execution attempts no longer throw
CircuitBreakerOpenException
if a configuredCircuitBreaker
is open when an execution is first attempted. Instead, the resultingFuture
is completed exceptionally withCircuitBreakerOpenException
. See issue #84.
๐ Improvements
- ๐ง Issue #81 - Added single argument failure configuration to avoid varargs related warnings.
- ๐ Asynchronous execution attempts no longer throw