-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
fix(storage): fix stream termination in MRD. #11432
Open
shubham-diwakar
wants to merge
11
commits into
googleapis:main
Choose a base branch
from
shubham-diwakar:test-mrd-race
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+165
−17
Open
Changes from 4 commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
06b2b50
feat(storage): fix mutex use and CloseSend before close
shubham-diwakar 8787ab8
Merge branch 'main' into test-mrd-race
shubham-diwakar b8394eb
drain inbound streams
shubham-diwakar 81a82fa
drain response in case we know there are requests still to be processed
shubham-diwakar ecc12b5
Merge branch 'main' into test-mrd-race
shubham-diwakar ce27fb3
Merge branch 'main' into test-mrd-race
shubham-diwakar d3e6831
use drainInboundReadStream in receiver go-routine
shubham-diwakar 819fc69
use CloseSend in manager go-routine
shubham-diwakar 9f16cb3
add comments about behaviour
shubham-diwakar 5a79b94
Merge branch 'main' into test-mrd-race
shubham-diwakar da8a04a
add integration tests for sudden close and context cancellation
shubham-diwakar File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
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 also drain the stream after the CloseSend (as we do in
drainInboundStream()
, receiving from stream until we get a non-nil error) to make sure its resources are released? See grpc/grpc-go@365770fThere 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 the best practice, applied this.
Using stream.recv just for determination of error.
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.
Actually i am not sure that will be get any outputs here if we call stream.Recv post CloseSend(). What if all the responses where consumed by streamReceiver go routine?
Although there are some cases when we close the stream even with requests added i have drained responses there.
LMK your thoughts.
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 Recv() continually returns the err (io.EOF or something else) once the stream is done? This should be easy to check with a toy program.
However, multiple concurrent calls to Recv() are not allowed, so if streamReceiver goroutine may be calling Recv(), you have to be careful not to call Recv() elsewhere until streamReceiver is done. I think it's probably easiest for all Recv() calls to live on that one goroutine.
It's maybe easiest to call CloseSend() on the same goroutine which calls Send()? Then you have one goroutine for Send/CloseSend, and another for Recv, and user code can cancel the context then call Close() to trigger a cancellation.
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 Chris for the suggestion.
That kind of simplifies structure too.
Now one go routine has all Recv() calls and other has all Send()/CloseSend() calls.