-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Feature Request: Customize Polly policies #264
Comments
@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 -
|
Cool sounds like a plan...I’ll make sure each reroute gets its own! |
…re this is correct api for users yet
Awesome; thanks! I'll check it out and let you know. Thanks for the quick turn-around! |
Is it compatible with core 2.x? |
Is it possible to get the context of the request in the delegating handler? |
Is not it too late? 😃 |
Feature Request
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?
The text was updated successfully, but these errors were encountered: