Open Ladicek opened 2 years ago
Your current order is quite standard in industry. The Resilience4j Aspects order is the following: Retry ( CircuitBreaker ( RateLimiter ( TimeLimiter ( Bulkhead ( Function ) ) ) ) )
Could I propose a simpler enhancement first: allow user to add additional Fault Tolerance Strategy at the beginning and at the end of chain (direct around Callable/before Bulkhead and after Fallback / before returning result to user)
I certainly don't intend to make FaultToleranceStrategy
a public API. But specifically for adding something at the beginning or at the end, that should already be pretty simple, you just wrap the Callable
s yourself.
for adding something at the beginning or at the end, that should already be pretty simple, you just wrap the
Callable
s yourself.
This is an obvious solution, no surprise :-) But Callable doesn't have InvocationContext. In the absence of which, you have to build your own session context infrastructure.
Here is a draft of a simple idea, how to improve the situation https://github.com/smallrye/smallrye-fault-tolerance/pull/924
BTW One of thing I miss from failsafe is https://failsafe.dev/execution-context/
The MicroProfile Fault Tolerance specification prescribes order in which fault tolerance strategies must apply. That's fine (and there's no other way) for the declarative API, but the programmatic API should offer a way to customize the order. In such case, certain fault tolerance strategies can even apply multiple times (fallback most importantly, because in the middle of the fault tolerance strategies chain, there's no other way how to handle exceptions). I'm thinking something like
FaultTolerance.create().customOrder()...
:customOrder()
must be called before any fault tolerance strategy is added