Expose underlying Circuit Breaker implementation instance to allow for additional configuration

[madorb]

Is your feature request related to a problem? Please describe.
While it certainly is a perfectly defensible position that SCCB (as per its name) should only support the "CircuitBreaker" pattern - it may be more robust to allow for configuration of additional library-specific resilience patterns. For instance Resilience4j enables 7 different resilience patterns of which only CircuitBreaker and TimeLimiter are supported

Describe the solution you'd like
Would love to have a mechanism to more fully configure the underlying circuit breaker's implementation, for instance to also enable Retry.

[ryanjbaxter]

I think retry can be implemented pretty easily outside of Spring Cloud CircuitBreaker, do you have a good reason as to why it should be part of the API?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[madorb]

Sorry for the delayed response, yes Retry can be implemented relatively easily outside of SCCB, but lets say I want to use Resilience4j for retry as well. That means I have two separate beans using two separate spring abstractions (retry and circuitbreaker) around a single http call.

What about if i DON'T want to use retry but want to use, say, RateLimiter, or Bulkhead resilience patterns? Spring has no abstraction for these, but Resilience4j supports them. This means that if I want to use CircuitBreaker/TimeLimiter AND any other resilience patterns, there's no value to me in using SCCB at all, as I still have to configure my own R4j instance and use it manually to configure the other resilience patterns.

Alternately, SCCB could provide a mechanism to natively configure the underlying CircuitBreaker provider - I think keeping the abstraction at the level of CircuitBreaker makes sense, and it can be unaware of the details of the other resiliency patterns I might want to use, but it might be useful to at least allow me to configure them.

Just a thought, obviously there are other potential solutions for this (i.e. avoiding the Spring Cloud abstraction completely, and just use the native boot support of resilience4j, though i think this may limit the usefulness of having the abstraction in the first place)

Thanks for considering!!

[Richardmbs12]

I also think this would make a lot of sense as a feature.

The reason I am using SCCB is because of the abstraction. If I anyway need to make use of resilience4j retry mechanism for example, which is not part of the SCCB abstraction, then I could have just gone with plain resilience4j and not care about the abstraction SCBB provides, as I am already coupling myself to resilience4j's api/annotations if I want the retry feature.

Retrying also makes sense in the circuit breaker context, especially when we want to be able to tune our circuit breakers, not to increase the fail rate before retrying first

[ryanjbaxter]

The one concern I have with supporting other resiliency patterns is supporting them across all implementations. Yes R4J supports many different patterns but what about the other libraries?

What about Sentinal and Spring Retry?

We need to support those implementations as well.

So lets open specific issues for each pattern we want to support and then we can come up with ways of implementing it across all implementations.