Closed markvincze closed 7 years ago
Adding this is pretty sensible for now. In the long run we're likely to fully externalize this cross-cutting concern using Istio or another service mesh though. The circuit breakers and retries will then fully live and be configured in the service mesh. Your application will then only have to provide fallback behaviour in case of a 502 service unavailable response code, but don't do retries or circuit breakers at all. This makes it language agnostic.
Super simple retry mechanism.
The only thing we can control is the
RetryCount
(which is 0 by default), nothing else. So no waiting between retries, no incremental wait times, etc. Those can come later as non-breaking improvements, but for the problem I'm having now, this simple retry is enough.For additional features, Polly can be an inspiration: https://github.com/App-vNext/Polly#step-2--specify-how-the-policy-should-handle-those-faults
In Hystrix.Dotnet.Samples.AspNet I did an automatic package update, that caused some changes in the csproj and web.config.
I also did some C# 6-7 improvements in the code based on ReSharper suggestions.
If you only wanna see the actual feature implemented, it's mainly in
HystrixRetryWrapper
andHystrixCommand
.