Proposal to Integrate Fault Tolerance Patterns into SmallRye Mutiny

[magicprinc]

Dear Mutiny Team,

I'm writing to propose the integration of additional Fault Tolerance (Resilience) patterns similar to those found in Failsafe, SmallRye Fault Tolerance, and Resilience4j directly into SmallRye Mutiny.

While Mutiny already features Retry and Fallback, the inclusion of additional patterns like Circuit Breaker, Rate Limiter, Timeout, and Bulkhead could significantly enhance its robustness and reliability. These patterns are crucial in high-load systems, like the ones I frequently work with in the telecom industry, as they help to prevent system failures and ensure stable performance.

The introduction of Virtual Threads in Java has definitely made Reactive Programming less attractive. However, by integrating these additional resilience patterns, Mutiny could gain a competitive edge, becoming a more comprehensive solution for developers who prioritize fault tolerance in their systems.

I believe that the integration of these patterns into Mutiny would greatly benefit the Java community, particularly those of us working on high-load systems. We would appreciate your consideration of this proposal.

Thank you in advance!

Best Regards, Andrej

[Ladicek]

If I understand correctly, Mutiny already includes timeout.

Circuit breaker, rate limiter or concurrency limiter (bulkhead) are a little more complex because they are stateful. So you need something extra outside of the "reactive pipeline" to store that state. Further, defining the semantics of these strategies is straightforward for Uni, but not so much for Multi.

As a SmallRye Fault Tolerance maintainer, I invite you to try the programmatic API, which is a lot closer to Failsafe or Resilience4j than the annotation-based API specified by MicroProfile Fault Tolerance. It has direct support for Mutiny (MutinyFaultTolerance)

[magicprinc]

@Ladicek

It would be great then, to have it as a lean module of Mutiny without MicroProfile annotation-based API and JBoss Logging: as compact as possible.

[Ladicek]

So if you're interested in using SmallRye Fault Tolerance outside of a container such as Quarkus or WildFly, you can use io.smallrye:smallrye-fault-tolerance-standalone. Here's a dependency tree of an empty project that only depends on that:

test:test:jar:1.0.0-SNAPSHOT                                                                                                                                  
\- io.smallrye:smallrye-fault-tolerance-standalone:jar:6.2.6:compile                                                                                          
   +- io.smallrye:smallrye-fault-tolerance-api:jar:6.2.6:compile                                                                                              
   |  \- io.smallrye.common:smallrye-common-annotation:jar:2.1.0:compile                                                                                      
   \- io.smallrye:smallrye-fault-tolerance-core:jar:6.2.6:compile
      +- org.eclipse.microprofile.fault-tolerance:microprofile-fault-tolerance-api:jar:4.0.2:compile
      \- org.jboss.logging:jboss-logging:jar:3.5.3.Final:compile

As you see, there's actually very few external dependencies, and they are all super tiny. There's nothing about it that isn't lean or compact. I take it you don't like the presence of MicroProfile Fault Tolerance API or JBoss Logging, but they are both required. In addition to the annotations you are not interested in, MicroProfile Fault Tolerance also defines exceptions that you still need (there's zero reason to create, for example, another CircuitBreakerOpenException). JBoss Logging is a logging facade that integrates well with all the popular logging backends out there, which just makes most sense in our case -- no matter if you use Logback or Log4j 2, SmallRye Fault Tolerance will log into your logging backend.

SmallRye Fault Tolerance will certainly never become a module of Mutiny, because there are plenty of use cases for it outside of Mutiny. Whether Mutiny should have its own implementations of circuit breaker, concurrency limiter or rate limiter, I'll leave to Mutiny maintainers :-)

[jponge]

I don't think Mutiny (a reactive programming library) should also deal with fault tolerance as it's an orthogonal concern that's well addressed in smallrye-fault-tolerance.

A reactive programming library offers error recovery (hence onFailure(), retry policies, etc), and if there's any obvious missing operator then we can discuss it. But again fault tolerance is a concern that shall be addressed at a different layer of a software stack.