Skip to content
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.

Sign up for GitHub

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
wants to merge 11 commits into
base: main
Choose a base branch
from
+165 −17
Open

fix(storage): fix stream termination in MRD. #11432

Changes from 1 commit
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 Jan 10, 2025
8787ab8
Merge branch 'main' into test-mrd-race
shubham-diwakar Jan 27, 2025
b8394eb
drain inbound streams
shubham-diwakar Jan 27, 2025
81a82fa
drain response in case we know there are requests still to be processed
shubham-diwakar Jan 27, 2025
ecc12b5
Merge branch 'main' into test-mrd-race
shubham-diwakar Jan 28, 2025
ce27fb3
Merge branch 'main' into test-mrd-race
shubham-diwakar Jan 30, 2025
d3e6831
use drainInboundReadStream in receiver go-routine
shubham-diwakar Jan 30, 2025
819fc69
use CloseSend in manager go-routine
shubham-diwakar Jan 30, 2025
9f16cb3
add comments about behaviour
shubham-diwakar Jan 30, 2025
5a79b94
Merge branch 'main' into test-mrd-race
shubham-diwakar Feb 13, 2025
da8a04a
add integration tests for sudden close and context cancellation
shubham-diwakar Feb 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions storage/grpc_client.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1251,7 +1251,9 @@ func (c *grpcStorageClient) NewMultiRangeDownloader(ctx context.Context, params
for {
select {
case <-rr.ctx.Done():
rr.mu.Lock()
rr.done = true
rr.mu.Unlock()
return
case <-rr.receiverRetry:
return
Expand Down Expand Up @@ -1373,8 +1375,6 @@ func (c *grpcStorageClient) NewMultiRangeDownloader(ctx context.Context, params
}

func getActiveRange(r *gRPCBidiReader) []rangeSpec {
r.mu.Lock()
defer r.mu.Unlock()
var activeRange []rangeSpec
shubham-diwakar marked this conversation as resolved.
Show resolved Hide resolved
for k, v := range r.mp {
activeRange = append(activeRange, rangeSpec{
Expand Down Expand Up @@ -1468,6 +1468,10 @@ func (mr *gRPCBidiReader) wait() {

// Close will notify stream manager goroutine that the reader has been closed, if it's still running.
func (mr *gRPCBidiReader) close() error {
// Before release of resource we close the client->server connection.
if err := mr.stream.CloseSend(); err != nil {
return err
}
Copy link
Contributor

@BrennaEpp BrennaEpp Jan 11, 2025 •
edited
Loading

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@365770f

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

if mr.cancel != nil {
mr.cancel()
}
Expand Down
Loading