-
Notifications
You must be signed in to change notification settings - Fork 214
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
Retry wrapped around hystrix call? #75
Comments
@ybbus This library was built with the above-mentioned decision. Let me research on this topic more. If you have some examples of some other resilience libraries doing it otherwise can you help point me to those? |
Based on the MSFT docs on the circuit breaker pattern, it still makes sense to combine retries with CB as long as errors are transient.
https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker |
Hi.
Does it really make sense, that the http retry mechanism is outside the CB call?
For me this seems very unintuitive:
When the CB is open, there will still be retries and also time.Sleep() backoffs. Isn't the intent of an opened CB also for the calling system to get a fast feedback and don't waste time?
Even on a completely new request there is no check if the cb is currently open. Why would one do retries and spend time waiting on an open CB?
For me it would make more sense to do the retries inside the cb. So you define the following behavior:
Or maybe I do get the idea wrong.
Please help clarify.
The text was updated successfully, but these errors were encountered: