Differences between MicroProfile Fault Tolerance versions
MicroProfile Fault Tolerance 2.0 contains changes that can cause an application that is written for an earlier version to fail when it uses the 2.0 feature. These changes were needed due to new requirements in the Fault Tolerance 2.0 specification.
The Fault Tolerance 2.0 specification defines how fault tolerance annotations interact when used together on the same method or class. In particular:
@Asynchronousis used, a method call doesn’t throw an exception. Any exception that occurs is instead propagated through the returned 'Future' or 'CompletionStage' object.
Fault Tolerance 1.0 and 1.1 throw an exception from an @Asynchronous method call if the exception occurs before the asynchronous task is started. In this configuration, a
BulkheadExceptionerror is always thrown directly from the method call.
When @Asynchronous, @Bulkhead and @Retry are used together, each retry attempt checks whether there is space in the Bulkhead to execute before it runs and releases its space when it finishes. Any Retry attempt fails with a
In Fault Tolerance 1.0 and 1.1, when an execution acquires a space on the Bulkhead, it does not release it until all retry attempts finish running.
In Fault Tolerance 2.0, Fault Tolerance is implemented by using an interceptor with a priority of
4010, as required by the specification. Fault Tolerance 1.0 and 1.1 use an interceptor with a priority of
If you want to revert to the previous behavior, Fault Tolerance 2.0 allows the priority of the interceptor to be configured by setting the
mp.fault.tolerance.interceptor.priority property to
1000 by using Microprofile Config.
For more information, see Fault Tolerance Interceptors.
Some metric names and types changed between MicroProfile Fault Tolerance 2.1 and MicroProfile Fault Tolerance 3.0. Some Prometheus metric names also changed between these versions. For more information, see Differences between MicroProfile Fault Tolerance 2.1 and 3.0.