Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Fault Tolerance 3.0
This release is a major release of Fault Tolerance which includes backward incompatible changes.
A full list of changes can be found on the MicroProfile Fault Tolerance 3.0 Milestone
17.1. Backward incompatible changes
17.1.1. Metric names and scopes changed
The metrics added automatically by MicroProfile Fault Tolerance have been updated to take advantage of support for metric tags which was added to MicroProfile Metrics in version 2.0. As a result, some information which was previously contained in the metric name is now instead included in tags.
In addition, metrics have moved from the application: scope to the base: scope for consistency with other MicroProfile specifications. Note that this means:
-
Metrics are now exported under /metrics and /metrics/base, instead of /metrics and /metrics/application as in previous versions.
-
In the JSON format, when metrics are retrieved from /metrics they appear in the base object rather than the application object.
-
In the OpenMetrics format, the names are prefixed with base_ instead of application_.
Old metric
application:ft.<name>.timeout.callsTimedOut.total
New metric
base:ft.timeout.calls.total{method="<name>", timedOut="true"}
These changes mean that existing dashboards and queries which use metrics provided by MicroProfile Fault Tolerance will need to be updated to use the new metrics listed in Integration with MicroProfile Metrics.
17.1.2. Lifecycle of circuit breakers and bulkheads is now specified
In previous versions of MicroProfile Fault Tolerance, the lifecycle of circuit breakers and bulkheads was not specified. These fault tolerance strategies hold state between invocations, so their lifecycle is important for correct functioning.
The specification now requires that circuit breakers and bulkheads are singletons, identified by the bean class and the guarded method. For example, if a @RequestScoped bean has a @CircuitBreaker method, all invocations of that method will share the same circuit breaker state, even though each request has a different instance of the bean.