Fault Tolerance 5.1

Today, we announce the release of SmallRye Fault Tolerance 5.1.0. This release includes some important bug fixes and one new feature. It is a safe upgrade for everyone using SmallRye Fault Tolerance 5.0.0.

Java 16 support

SmallRye Fault Tolerance includes a small utility class that helps calling default methods when they are declared as fallback methods with @Fallback. This class uses reflection to crack open some internal JDK classes on Java 8. Naturally, since Java 9, the JDK started complaining, and since Java 16, this became an error.

For that reason, we have a variant of that utility class that uses Java 9 public API, and the main SmallRye Fault Tolerance JAR has, for a long time, been a multi-release JAR. Unfortunately, we introduced a bug in SmallRye Fault Tolerance 4.3.1. This bug causes the main SmallRye Fault Tolerance JAR to omit the META-INF/versions/9 directory, and so the Java 8 variant of the class is the only one present.

In the 5.1.0 release, we fixed that bug and made sure the SmallRye Fault Tolerance release process is executed with Java 11. Hence, SmallRye Fault Tolerance should once again work as intended on all Java versions, particularly on Java 16.

Note that even though we run the release process with Java 11, we still produce Java 8 bytecode. Java 8 is still supported with SmallRye Fault Tolerance 5.1.0, even though we may drop this support in future versions.

Vert.x integration

In certain situations, SmallRye Fault Tolerance runs @NonBlocking methods on a different thread than the original call was made on. This includes:

  • @Retry methods, where a non-zero retry delay is configured (the delay must not block);

  • @Bulkhead methods, where a non-zero bulkhead queue is configured (if the invocation is queued).

By default, we run such guarded methods on a thread pool provided by the integrator. In this release, we provide an integration API for event loops, as well as an implementation of this API for Vert.x.

With this integration enabled, invocations of @NonBlocking methods made on an event loop thread are always executed on the same event loop thread.

For more information, see user documentation and integration documentation.

Others

We have also significantly expanded our CI coverage. We now run tests with:

  • all Java LTS releases we care about (at this moment, Java 8 and 11);

  • the latest Java release (at this moment, Java 16);

  • the upcoming Java release (at this moment, Java 17-ea).

All of this on Linux, Windows and macOS, thanks to GitHub Actions.

(In fact, we currently don’t run tests with Java 17-ea, because of a bug in JBoss Class File Writer. That should be resolved shortly, and we are not aware of any other issue with Java 17-ea.)

With this CI coverage expansion, we found and fixed a particularly nasty concurrency issue in handling @Timeouts on Future-returning methods when @Retry is present. @Bulkheads on Future-returning methods, in presence of @Retry, were fixed as well.

Upgrade to 5.1.0 is therefore very much recommended!