-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
envoy HTTP2 racing / DownStreamProtocolError / codec_error:The_user_callback_function_failed #30882
Comments
affected branches are the only close behavior change documented in releases notes which could affect the is the
|
by digging deeper the problem with particular behavior introduced in |
@yanavlasov thoughts? |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
@htuch, is it possible to reopen? this issue came back as part of 1.29.2(envoy.reloadable_features.http2_use_oghttp2==false) while 1.29.1 or/and 1.29.2(envoy.reloadable_features.http2_use_oghttp2==true) is working fine |
We're seeing this behavior with some clients, and like the reporter couldn't alter the behavior by setting I see in the same envoy releases that we pulled in new versions of nghttp2, and they added similar So, my naive questions - totally realize I could be barking up the wrong tree: Does envoy now have two different Do we have any options for configuring nghttp2 from envoy, e.g. specifically the new Edit: just now processing what @pgeler said above...
So if |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions. |
@htuch since oghttp2 implementation still having problems and envoy switching back to default nghttp2 as of 1.31.2 due to stability concerns, is it possible to re-open this issue as default nghttp2 implementation continue to have this unaddressed behavior? |
Description:
Overall it seem like racing condition on HTTP2, most of the time I was able it to reproduce with GRPC service., There is seem to be correlation on larger number of clients, however I have examples where similar issue happening with envoy to envoy HTTP path-through connectivity.
This particular example was created after ~5min, 1000k RPS, execution on 50+ simultaneous clients, grpc is a ext_proc stream-based service, but I can confirm that the issue isolated to newer envoy not to the ext_proc filter as b-sidecar(by rollback to envoy-1.27):
client -> envoy(a router - ext_proc) -> envoy(b-sidecar) -> grpc service:
http2 specific clusters configuration:
after period of time and high frequency requests:
requests starts failing with DPE(b-sidecar):
all requests isolated to single connection and it seem that is happening on connection per-connection basis:
tracelog last couple of seconds for the connection 233 (end of the life(b-sidecar) where issue occured):The text was updated successfully, but these errors were encountered: