Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
madorb opened this issue Jan 2, 2020 · 9 comments
Labels
enhancement New feature or request

Comments

@madorb
Copy link

madorb commented Jan 2, 2020

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Author

madorb commented Jan 29, 2020

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
Copy link

Richardmbs12 commented Mar 5, 2021

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
Copy link
Contributor

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
Copy link
Author

madorb commented Mar 8, 2021

@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)

@madorb madorb changed the title Support additional Resiliency Patterns Expose underlying Circuit Breaker implementation instance to allow for additional configuration Mar 8, 2021
@ryanjbaxter ryanjbaxter reopened this Mar 9, 2021
@ryanjbaxter
Copy link
Contributor

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

@spring-cloud-issues
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants