This isn't urgent, but it would be great if we could somehow customize Polly policies used for some reroutes. As examples, I'd like to be able to add a retry policy or change the callback used when the circuit breaker opens.
It would be easy to add my own policies in a DelgateHandler but then they would apply to all reroutes (which is undesirable since one bad API would open the circuit breaker for all).
Perhaps there's a way we could inject Policy[] via DI to override the defaults?
@mjrousos Yeh this is a useful feature. I will have a look ASAP.
Maybe we want ReRoute specific delegating handlers, do you agree? I had this functionality requested before.
So we need some way of mapping ReRoutes to handlers, the easiest way to do this would be to have an array of delegating handlers on the ReRoute in configuration.json.
Maybe on the ReRoute we have
"Handlers": [
"Tracer",
"PollyOne"
]
then in Ocelot
services.AddOcelot()
.AddDelegatingHandler<PollyOne>()
.AddDelegatingHandler<Tracer>()
.AddDelegatingHandler<Foo>();
When the http client is built for the ReRoute we pick out the delegating handlers that matched the string in json.
Seems simple enough!
Yea, that would do the trick. In this model, I could put whatever custom Polly policies I want in a delegating handler and then use it with particular reroutes. A couple concerns, though -
"Handlers": [] but I won't want that circuit breaker opening for one of the reroutes to affect the other. So, it will be good if each reroute that uses a delegating handler could get its own instance (so that they can have separate instances of policies or other local state).Cool sounds like a plan...I鈥檒l make sure each reroute gets its own!
@mjrousos OK ive just pushed version 5.0.0 that has changes that should let you do all of the things we talked about (hopefully). Let me know if this isn't the case.
Updated docs here hopefully they make sense.
Awesome; thanks! I'll check it out and let you know. Thanks for the quick turn-around!