Eclipse MicroProfile Fault Tolerance 2.0

On the surface, the changes between Fault Tolerance 1.1 and 2.0 are straightforward. The main new feature is allowing use of the @Asynchronous annotation on methods returning CompletionStage which allows for more elegant composition of asynchronous computation.

Besides this feature, the Fault Tolerance 2.0 release mostly clarifies the semantics when using multiple Fault Tolerance annotations. The major increase in version arises from the use of Eclipse MicroProfile 2.0 dependencies.

Annotation Precedence and Property Overrides

Annotations on methods take precedence over the same annotation on class level that applies to all suitable methods of that class. Overrides done using properties only apply if the annotation they target is present. A method level override requires a method level annotation, a class level override a class level annotation. Again, method level overrides take precedence over class level overrides. Global overrides for an annotation type have the lowest priority among overrides.

Overrides can change during runtime.  Because of the caching in Payara Platform it can take up to a minute before changes to a fault tolerance property file has an effect.

Both annotations and property overrides allow to define values outside of the boundaries of a specific property as specified by the specification. Because only valid policies should be applied, the validation is performed on the annotations when an application is deployed and on the resulting configuration of annotations and overrides combined on method invocation. For the Payara Platform, the last valid configuration for a particular target method is used.

You can try Payara Micro with MicroProfile using the MicroProfile Starter (Beta).

The MicroProfile Starter generates a MicroProfile Maven Project with Examples.

Invocation Sequence of Fault Tolerance Policies

Fault tolerance annotations can be combined without limitations. A method could effectively apply any single policy, all of them or any imaginable combination. To keep combinations manageable for both users and implementations a fixed sequence of policy execution (nesting) is defined where those policies not present are ignored or skipped. This sequence is:

1. @Asynchronous*
2. @Fallback
3. @Retry
4. @CircuitBreaker
5. @Timeout
6. @Bulkhead

The best explanation are a few examples:

• For an Asynchronous method all other present policies are applied within the asynchronous computation.
• Each Retry will have its own evaluation of the CircuitBreaker, Timeout and Bulkhead.
• A Fallback is only applied after all retries have failed.
• Waiting in a Bulkhead queue can be cancelled due to Timeout.

* Asynchronous also acts a little bit like a modifier on nested policies. As a consequence each Retry within an asynchronous computation is in itself asynchronous. Should an asynchronous Retry time out, the next attempt is initiated after the Timeout period - not when the first attempt actually returns execution to the retry stage which might be later or never in the case of non-cooperative method implementations that gobbles the attempt to interrupt execution.

Interceptor Priority

The Fault Tolerance annotations are made effective by intercepting calls to the annotated methods and wrapping the execution with the Fault Tolerance semantics specified. This can be done using one interceptor for each annotation or one interceptor handling all annotations in one go. The priority of these interceptors might become important in relation to other interceptors used to lead to correct nesting of the overall execution. Therefore, FT specification defines a default range for the FT interceptors stating at Interceptor.Priority.PLATFORM_AFTER + 10. In cases where this collides with other interceptors the mp.fault.tolerance.interceptor.priority property can be set to move the base priority (lowest used priority) of the FT interceptors. Such a configuration is only evaluated once during initialisation. Later changes during runtime have no effect and require a server restart to work.

Small Changes with Significant Implications

While the step to Fault Tolerance 2.0 seems small on the surface, the implications for the implementation were significant. We took the opportunity to improve our internal design and add extra features as mentioned in our MicroProfile 2.2 update post. Looking forward in the MicroProfile universe, MicroProfile 3.0 has been released. Payara plans to implement support or MicroProfile 3.0 in the upcoming months.

Learn More About Using the Payara Platform

Or, Download the Latest Payara Platform Release Here