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 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 particular, this meant that a BulkheadException would always be thrown directly from the method call.
  • 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 a BulkheadException.
    • 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.