search

spring-cloud / spring-cloud-circuitbreaker

Spring Cloud Circuit Breaker API and Implementations
Apache License 2.0
332 stars 111 forks source link

Expose underlying Circuit Breaker implementation instance to allow for additional configuration #59

Open madorb opened 4 years ago

madorb commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

madorb commented 3 years ago

@ryanjbaxter i totally agree about that approach for supporting differing reliability patterns... that doesn't solve my initial request though - to make the underlying CB provider available to be further configured... (though i think i chose a poor title for the topic initially, as it wasn't about asking SCCB to provide additional abstractions)

ryanjbaxter commented 3 years ago

@madorb. can you provide an example in code of how you would envision this feature working?

spring-cloud-issues commented 3 years ago

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.

spring-cloud-issues commented 3 years ago

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.