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.getandFailsafeExecutor.runwill no longer wrapErrorinstances inFailsafeExceptionbefore throwing.
๐ Bug Fixes
- ๐ Fixed potential race between
Timeoutinterrupts and execution completion.
-
v2.2.0 Changes
August 12, 2019๐ Improvements
- โ Added a new
Timeoutpolicy that fails withTimeoutExceededException. - โ Added
ExecutionContext.isCancelled(). - โ Added
ExecutionContext.getElapsedAttemptTime(). - โฑ Made the internal delay scheduler more adaptive.
API Changes
- ๐ Deprecated
CircuitBreaker.withTimeoutin favor of using a separateTimeoutpolicy.
๐ 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.ofExceptionfor returning custom exceptions. - โ Added
ExecutionContext.getLastResultand.getLastFailureto support retries that depend on previous executions - โ Added
CircuitBreakerOpenException.getCircuitBreaker
API Changes
- ๐ฆ
RetryPolicy.DelayedFunctionwas moved to thenet.jodah.failsafe.functionpackage. - โ Removed
RetryPolicy.canApplyDelayFn
- โ Added support for
-
v2.1.0 Changes
July 20, 2019๐ Improvements
- โ Added support for
Failsafe.with(List<Policy<R>>). - ๐ Allow
nullFallbackvalues.
๐ 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.isCompletereflects this.
- โ Added support for
-
v2.0.1 Changes
February 03, 2019๐ Improvements
- โ Added support for using
ExecutorServiceviaFailsafeExecutor.with(ExecutorService). - โ Added interruptable cancellation for executions ran on
ForkJoinPoolviaCompletableFuture.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
ScheduledExecutorServiceorSchedulerbe configured. When no scheduler is configured, theForkJoinPool's common pool will be used by default. - ๐
Fallbacknow support async execution viaofAsync. - ๐
CircuitBreakersupports execution metrics (see below). - ๐ Strong typing based on result types is supported throughout the API.
Behavior Changes
- 0๏ธโฃ
RetryPolicynow has 3 max attempts by default. - 0๏ธโฃ
CircuitBreakernow 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
Policyimplementations, while adding some new features such asPolicycomposition.- Policies
- Policy implementations now take a type parameter
Rthat represents the expected result type. - Some of the time related policy configurations have been changed to use
Durationinstead oflong+TimeUnit.
- Policy implementations now take a type parameter
- ๐ง Policy configuration
- Multiple policies can no longer be configured by chaining multiple
Failsafe.withcalls. Instead they must be supplied in a singleFailsafe.withcall. 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, andretryWhenmethods have been replace withhandleOn, etc.
- The
- CircuitBreaker
- The
failOn,failIf, andfailWhenmethods have been replace withhandleOn, etc.
- The
- Fallbacks
- Fallbacks must be wrapped in a
Fallbackinstance viaFallback.of
- Fallbacks must be wrapped in a
- Failsafe APIs
Suppliers are now used instead ofCallables.java.util.function.Predicateis used instead of Failsafe's internal Predicate.withFallbackis 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
ExecutionEventobject, which includes references to the result, failure, and other information. - Event listeners that are specific to policies, such as
onRetryforRetryPolicy, must now be configured through the policy instance. The top levelFailsafeAPI only supportsonComplete,onSuccess, andonFailure. IndividualPolicyimplementations still supportonSuccessandonFailurein addition to policy specific events. - The top level
Failsafe.onSuccessevent listener will only be called if all configured policies consider an execution to be successful, otherwiseonFailurewill be called. - The
Listenersclass 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.Durationis used instead of Failsafe's ownDurationimpl.ChronoUnitis used instead ofTimeUnitin policies.
ExecutionContext.getExecutionsis nowgetAttemptCount.- โฑ
Schedulers.of(ScheduledExecutorService)was moved to theSchedulerinterface.
API Additions
CircuitBreakerpreExecuteis 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 -
handleRetriesExceededcalled incorrectly.
-
v1.0.4 Changes
April 02, 2017API Changes
- ๐ Asynchronous execution attempts no longer throw
CircuitBreakerOpenExceptionif a configuredCircuitBreakeris open when an execution is first attempted. Instead, the resultingFutureis 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