Fault Tolerance 2.0 behavior changes
The Fault Tolerance 2.0 implementation contains behavior changes, which might cause an application that is written for an earlier implementation to behave differently or to fail when using the Fault Tolerance 2.0 feature. These changes were needed due to additional requirements in the Fault Tolerance 2.0 specification.
Interactions between Fault Tolerance annotations
The Fault Tolerance 2.0 specification defines how fault tolerance annotations interact when used
together on the same method or class. In particular:
- When using
@Asynchronous
, a method call doesn't throw an exception. Any exception that occurs instead is propagated through the returnedFuture
orCompletionStage
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 particular, this meant that aBulkheadException
would always be thrown directly from the method call.
- Fault Tolerance 1.0 and 1.1 throw an exception from an
- When using
@Asynchronous
,@Bulkhead
and@Retry
together, each retry attempt checks whether space exists in the Bulkhead to execute before running and releases its space when it finishes. This means that it's possible for any Retry attempt to fail with aBulkheadException
.- 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.
Priority of the Fault Tolerance interceptor
In Fault Tolerance 2.0, Fault Tolerance is implemented 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 1000.
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
using Microprofile Config.