resilience4j: [QUESTION] Using circuit breaker and retry together
Resilience4j version: v1.4.0
Java version: 11
Hey team, I had a few questions regarding the use of CB and retry together:
- Is there any documentation out there for how to get that set up? I’m confused as to how the retry fallbacks and circuit breaker fallbacks and state transitions work together.
- My use case is to send some data to a Kafka cluster through a decorated
Consumerand I’m using thedecorateConsumermethod from aCircuitBreakerbut to execute it I don’t see any methods. Currently I’m just calling theacceptmethod from aConsumerinterface, is there any other way to run a decoratedConsumer? - If I want to decorate a
Consumerwith bothCircuitBreakerandRetryis there any way to do so without using thedecoratorsdependency? I’m thinking of having just ther4j-circuitbreakerandr4j-retrydependencies and decorate theConsumerwith one and save it in a variable and then decorate the new saved variable with the other. Thoughts on this?
EDIT:
- For custom configuration for either decorators, if I use a custom config and only set a few of the options available, what happens for the other ones. For example if I use
CircuitBreakerConfigobject and build a custom config that only defines a failure threshold in half open state and closed state, what happens to all the other configuration properties that can be set such as number of calls permitted in half-open state, etc. Does it still use the default values for all the other properties and only overrides the ones I’ve set in the custom config object that is passed to theCircuitBreakerRegistryorCircuitBreakerdirectly? - Is there any retry functionality built into
CircuitBreakerwhere if an error occurs then it stores the data that was supposed to be sent and then re-sent it. And ifRetryis supposed to be used for that purpose, doesRetryhave a buffer where it stores the data that should’ve been sent and that it needs to retry sending? Or does theRetryfunctionality work on each call of aConsumer/Supplier/etc. at a time so it doesn’t care if 100 calls fail in a second because it’ll retry it with whatever logic is set up for each of those 100 calls separately in the same or new thread(s)?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 19 (9 by maintainers)
Will do, thanks!
EDIT: Submitted.
You can suggest edits.
The Azure Event Hub SDK also retry options. You should carefully check, if you are really allowed to do your own retry on top of it.
1.) The only documentation is here . Since the user can decide in which order Retry and CircuitBreaker are stacked, there is no single pattern how everything works together. It’s really dependent on how you are using it.
I usually stack it like this:
Retry ( CircuitBreaker ( Function ) ) )Then add
CallNotPermittedExceptionto the list of ignored exception in your RetryConfig so that no retries are done when the CircuitBreaker is open. If a call fails because of a different exception, the call will be retried. But if it still fails it will of course open the CircuitBreaker faster. If you don’t like that you can change the order to.` CircuitBreaker ( Retry ( Function ) ) ) ``