Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Allow multiplexed upstream servers to half close the stream before the downstream #34461
Allow multiplexed upstream servers to half close the stream before the downstream #34461
Changes from 1 commit
7263c53
fd17760
723ed65
1d8172c
3ba7cc4
6133efc
fcf2a76
f24bc34
0e881dc
b7b746f
af60f0b
01ae68b
1f269a4
1b961df
8ae88a0
d8aabba
2166fcb
e2deca2
9e9428f
71ce1f0
68c807e
9c308ba
2d8cb15
e1c00d0
018a3e4
9a692f3
bd30f81
b9948ab
e224738
e4ae6b4
d5320da
b804cb5
4b305d9
9155e49
49b6162
c02ac47
d965ff6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
suggestion: remove flag name so we don't have to remember to update the comment when we remove the 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.
Done
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.
return filter_manager_.allowUpstreamHalfClose()?
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.
Done
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.
add to dumpstate instead?
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.
I don't have a good understanding of dumpstate but just quickly read #7300. if the dumpstate need to be invoked by human or at crash automatically, I hope we keep this log for stream level debugging (while agreed that this information should be added on the other place too, if needed). It will be super helpful to users who debug streams with trace log, why their stream got reset or why not.
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.
Why not both? Added to both places.
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.
how is this different from remote_decode_complete? it's set when we see end stream. I think it's just badly named.
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.
can we explicitly comment how this differs from local_complete as well?
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.
It is a bit messy. I have added more comments to
local_complete
andencoder_end_stream
and left a TODO to always useencoder_end_stream
for tracking end_stream state in encoder filer iteration.I will do this refactor when the runtime flag is removed.
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.
I feel like we should be able to share code between these two
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.
My goal here was to make it clear that the old behavior is fully preserved when
allow_upstream_half_close_ == false
. Refactor can save a couple of lines of code but will make it harder to see whether behavior has changed or not.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.
I'm concerned that we have allow_upstream_half_close and isHalfCloseEnabled.
if filter_manager_callbacks_.isHalfCloseEnabled isn't working as intended can we just fix?
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.
I have changed FM to always use filter_manager_callbacks_.isHalfCloseEnabled
I will refactor FM to just always support independent half closes when runtime flag is removed.
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.
instead of setting a boolean here (which adds to the booleans we need to keep track of in all places, WDYT of adding a stopSending function which we call both on local reply and on receipt of error response, which stops downstream processing?
I think that'd then be reuseable for the "stream reset preceding data" bug as we could convert no_error stream resets into stop sending calls.
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.
Makes sense. I have reworked this a bit and added the stopDecoding method.
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.
this seems like a really weird place to put this. why not on all local resets and or local replies?
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.
I could be overthinking here. My thought was to allow independent half close only when server response is 2xx. If it is error (ore redirect) response Envoy fully closes the stream. This bit of code treats upstream error response as a
sendLocalReply
.I was thinking about case where upstream response with error to a POST with large body. Presently Envoy 'helps' gracefully stop body upload. With independent half closes the upstream will have to follow up an error response with a reset, otherwise upload will continue.
I'm not sure if Envoy needs to do this. We could get rid of this case and make it so independent half close is supported regardless of the upstream response status. And the perhaps add a flag if Envoy needs to support this corner case. Let me know what you think.
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.
should this be half close? closeUpstream?
should this logic all be in maybeClose?
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.
It closes downstream and upstream streams. I have renamed it
checkAndCloseStreamIfFullyClosed
to hopefully make it clearer.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.
I think we may need a rename / comment PR before we land this because I think this would be more clear if local_complete were more clear in the first place.
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.
or after? (when we consider the urgency of this issue)
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.
I have updated comments for local_complete_ and encoder_end_stream_ flags
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.
can this be cone in maybeendDecode so we don't have to do it in all headers/body/data cases? if maybeEndStream did checks on allow_upstream_half_close_ I think it'd simplify things?
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.
Moved the flag check to
checkAndCloseStreamIfFullyClosed
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.
why not just use a helper function which checks both booleans?
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.
should we stick with half close naming for consistency? support_half_close?
if not consider renaming to something like should_force_close
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.
Renamed to
should_force_close_stream_
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.
While we shouldn't be resetting the upstream, we do also skip over doing these various timing, outlier detection, etc. When will we end up updating them in this case when
allow_multiplied_upstream_half_close
is true?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.
Never. This code updates the
response_time
which isresponse_complete_time - request_complete_time
. It is negative for the case where response completes before request and budget percentage computations will be off. Histograms record uint64_t so these will end up being some large values.Since the
response_time
becomes nonsensical in this case, I decided to skip recording the stats.