Visit Azul.com Support

Eclipse Microprofile Fault Tolerance API

Azul Payara 7.2026.8 provides MicroProfile Fault Tolerance 4.1

Background

The Fault Tolerance API was created to help separate execution logic from execution. The execution can be configured with a number of fault tolerance policies.

The complete specification can be found on the Eclipse MicroProfile website.

Breaking changes introduced in MicroProfile Fault Tolerance 4.1 are listed in the official specification under Incompatible Changes

Additions to the Fault Tolerance Spec

In addition to the functionality detailed in the specification document, Azul Payara has implemented additional features like:

Configurable Executor Services

On Payara Server, the managed and scheduled managed executor pool used to generate threads for the service can be configured via the set-fault-tolerance-configuration Asadmin command.

The executor service is used to execute methods annotated with @Asynchronous, whereas the scheduled executor service is used by the CircuitBreaker and Timeout interceptors for their timeout operations (scheduling the circuit breaker to be set to half open, and just timing out respectively).

Alternative @Asynchronous Annotations

The Azul Payara configuration property MP_Fault_Tolerance_Alternative_Asynchronous_Annotations can be used to specify a comma separated list of fully qualified class names of those annotations that should have the same effect as the @Asynchronous defined in the Fault Tolerance specification.

These annotations do not have to be interceptor bindings.

For example:

 
MP_Fault_Tolerance_Alternative_Asynchronous_Annotations=jakarta.ejb.Asynchronous

Annotation Priority

As per the Fault Tolerance specification, interactions between annotations are handled effectively nesting computation in the following way (skipping handling for annotations not present):

  1. Asynchronous

  2. Fallback

  3. Retry

  4. CircuitBreaker

  5. Timeout

  6. Bulkhead

  7. (calling annotated method; might be wrapped by other interceptors)

As specified the interceptor priority can be changed using the property mp.fault.tolerance.interceptor.priority affecting all annotations including alternative ones.

Fault Tolerance Configuration

On Payara Server the Fault Tolerance service can be configured by using the Admin Console or Asadmin CLI commands.

Using the Admin Console

To configure the Fault Tolerance in the Admin Console, go to Configuration → [instance-configuration (like server-config)] → MicroProfile → Fault Tolerance:

Using Asadmin Commands

Use the following commands to modify the configuration settings of the MicroProfile Fault Tolerance service:

What’s New in MicroProfile Fault Tolerance 4.1

MicroProfile Fault Tolerance 4.1 (shipped with MicroProfile 7.0 and 7.1) is a minor, non-breaking release over 4.0. There are no incompatible changes — existing code and configuration continues to work without modification.

Note
Users upgrading from versions prior to Azul Payara Community 7.2026.8 (which provided MicroProfile 6.1 support) are jumping across both 7.0 and 7.1, and all changes below apply to them.

MicroProfile Telemetry Metrics Integration

Fault Tolerance 4.1 adds support for exporting fault tolerance metrics through the MicroProfile Telemetry Metrics API (OpenTelemetry), in addition to the existing MicroProfile Metrics export path.

The following fault tolerance metrics are exported to Telemetry when MicroProfile Telemetry is active:

  • Retry call counts (total, retried, retry max retries exceeded)

  • Timeout durations and call counts (timed out vs not timed out)

  • Circuit breaker call counts by state (open, half-open, closed) and outcome

  • Bulkhead accepted and rejected call counts, and queue wait time

  • Fallback call counts

To enable this, ensure MicroProfile Telemetry is active (otel.sdk.disabled=false) and no additional configuration is required. Refer to MicroProfile Telemetry documentation for setup details.