-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Consul connect provide a way to configure envoy route timeout #6382
Comments
Hey there, Feel free to check out the community forum as well! |
Hi, we set this timeout using a service router:
which can then be seeing in the envoy configuration:
However, envoy sets this header: We couldn't find a way to increase the value of this header ( or disable it ) via consul which would leave us with the configured timeout in the service router. At this point we are not sure if there is way to manage that header and we missed it or if there is still no way to manage it, in which case it would be a very helpful feature. We are using consul 1.6.1 with envoy 1.11.1 If you could shed some light on this that would help us a lot |
I have the same issue and i think this is because envoy proxy on the local app dont set a specific timeout. |
Hi @rrondeau , |
i faced the same issue. I end up to build consul from source code with my fix. hope you found it useful
|
@msuarezd, I believe the issue you're describing is related to envoyproxy/envoy#7358 which was fixed in Envoy version 1.12.0 with envoyproxy/envoy#8051. If that's correct, the correct fix would be for Consul to also allow configuring respect_expected_rq_timeout in the |
Has there been any progress on this issue? Is setting RequestTimeout in a Service Resolver configuration the expected way to configure this? And it just doesn't work because of the respect_expected_rq_timeout issue mentioned above? I'm not super familiar with Envoy itself and the documentation around the Envoy escape hatch configuration is hard to follow. |
Wew, this has been a bit of a rabbit hole but for anyone else who runs into this issue... The quickest fix is to change the destination service protocol to Setting a This had no effect for me, couldn't find a timeout parameter in the config dump on either envoy instance. I had a look at enabling |
Hi, I suppose that you override the 'listener_filters_timeout' value ? Yours faithfully, |
Today I struggled into this issue and these are my conclusions at this moment with Consul 1.9.1 and Envoy 1.16.0:
So I recompiled Consul with:
so all envoy.router entries now have the
but changed to work with latest consul changes:
the problem is that it hardcodes a value for all the services, imposible to configure for each upstream service... I suspect the way to go would be using the |
Hey folks - we ran into this today too. I spent some time on it this afternoon. As y'all have discovered, there's two places the Envoy route local_app Request TimeoutsLocally, I have the changes which add Update: PR is here - #9554 Upstream Request TimeoutsAfter addressing that, I sat down to see what we could do about the timeout on the other end, which is configurable today only via a
I'm not sure of HashiCorp's motivation behind that move or change is, but my assumption is that it's probably to centralise the configuration of connection timeouts, and elevate them "above" service upstream definitions, which left me wondering what to do about an upstream Do nothing, rely on
|
For those that are interested, the pull request which adds support for If you're after a complete change set that also disables the request timeout on the egress Envoy instances/upstream routes completely (but still allows overrides via service-router entries) because you want to control timeouts at the I'd very much love feedback on my earlier comment for how we can get this functionality into Consul Connect, as I'd consider it critical for a lot of production deployments. |
Hi @chrisboulton I think this could fit in per-upstream configuration, and the new UpstreamConfig in service-defaults: Regarding the note about connect timeout, there are two points there. First is that yes we generally want to move away from per-instance configuration. However, if the discovery chain isn't being configured, I can see the benefit of allowing this flag to be set elsewhere. Now that we have centralized upstream config in service-defaults it wouldn't be exclusively in individual proxy registrations. An issue that concerns me is the proliferation of places where one setting can be configured, and then it becoming unclear which one takes precedence. |
@chrisboulton I tried this solution but that doesn't work with Transparent proxy mode enabled. Is there a workaround while using Transparent proxy mode? |
Feature Description
Provide a way to configure upstream listener to configure timeout.
Use Case(s)
https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route.proto#route-routeaction
The envoy default value is 15s second which is too high or too low depends on the use case.
The text was updated successfully, but these errors were encountered: