-
Notifications
You must be signed in to change notification settings - Fork 5.1k
ext_proc: closing the gRPC stream ASAP once no more external processing needed #41425
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
base: main
Are you sure you want to change the base?
ext_proc: closing the gRPC stream ASAP once no more external processing needed #41425
Conversation
needed Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
|
/retest |
|
/assign @yanavlasov @tyxia @stevenzzzz |
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/wait
Signed-off-by: Yanjun Xiang <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hooah. You are fighting a beast here. :)
high level, since this is a behavior change that impacts prod traffic, could you guard this change with a feature flag?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left some comments, pls consider some common cases like(there for sure are more):
- CONTINUE_AND_REPLACE finishes one direction's all events.
- EOS from trailers implicitly terminates body.
- only check if-last-reponse after response is "processed", on error cases, stream will already be closed.
On a high level, if we have gone this far already, let's also consider to wait-for-trailers after the half close been sent. but that could be in another PR I assume.
| } | ||
| break; | ||
| case ProcessingResponse::ResponseCase::kRequestBody: | ||
| if (isLastBodyResponse(decoding_state_, *response) && encoding_state_.noExternalProcess()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if trailers are configured?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we detect EoS is received with body, so no trailers in this request. Thus even filter is configured to send trailers, the external processing in this direction is completed.
Signed-off-by: Yanjun Xiang <[email protected]>
|
Waiting for addressing comments. /wait |
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
+1 on runtime guard to protect this change,. The processing mode/ext_proc is getting more and more complicated )
Signed-off-by: Yanjun Xiang <[email protected]>
|
The initial optimization does not apply for a few scenarios listed below, which is TBD in the future:
|
|
Kind Ping! |
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
|
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
test/extensions/filters/http/ext_proc/ext_proc_full_duplex_integration_test.cc
Show resolved
Hide resolved
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
Signed-off-by: Yanjun Xiang <[email protected]>
|
/retest |
1 similar comment
|
/retest |
…_stream_asap Signed-off-by: Yanjun Xiang <[email protected]>
|
/retest |
|
@yanjunxiang-google Could you please resolve any conversations that you think is already resolved? It will help review. Thanks! |
Done, thanks! |
…_stream_asap Signed-off-by: Yanjun Xiang <[email protected]>
|
/retest |
2 similar comments
|
/retest |
|
/retest |
…_stream_asap Signed-off-by: Yanjun Xiang <[email protected]>
|
LGTM from me. Will wait for @tyxia and @stevenzzzz reviews. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, Thanks
I think this PR is a best-effort attempt to close the gRPC stream ASAP, with trade-off of corner case complexity. It will be good to also run it with some load test etc.
|
/retest |
This is to address the issue: #41764, i.e, close the gRPC stream once no further external processing needed. It is also partially discussed in #37088.
Currently the ext_proc gRPC stream is opened when the 1st ProcessingRequest is sent to the ext_proc server. And it is closed during ext_proc filter destruction. This is wasting resource on both Envoy and ext_proc server side. For example, if envoy is configured to only send request headers, the gRPC stream is left open until all the way to the response is processed.
This PR is trying to close the ext_proc gRPC stream once Envoy detects no more external processing needed.