Context cancelation does not propagate from the client to the server for streams

[russ-]

I have a stream defined that will send messages perpetually to the client, until the client is no longer interested. Since there is no "stream.Close" on the client side (only stream.CloseSend), I assume using context.WithCancel on the client side is the correct way to do this. However, it seems like cancelation is not being propagated to the server: The server continues calling Send (with no errors) long after the client stops caring, and eventually the Send blocks entirely and the server's goroutine hangs. I think the goroutines are unblocked and exit if the connection is closed, but I didn't test that thoroughly.

Unary RPCs seem to honor context cancelation.

Is there some other way for the client to indicate it is no longer interested in the stream?

[iamqizhao]

looking..

On Fri, May 8, 2015 at 7:45 AM, Russ Amos notifications@github.com wrote:

I have a stream defined that will send messages perpetually to the client,
until the client is no longer interested. Since there is no "stream.Close"
on the client side (only stream.CloseSend), I assume using
context.WithCancel on the client side is the correct way to do this.
However, it seems like cancelation is not being propagated to the server:
The server continues calling Send (with no errors) long after the client
stops caring, and eventually the Send blocks entirely and the server's
goroutine hangs. I think the goroutines are unblocked and exit if the
connection is closed, but I didn't test that thoroughly.

Unary RPCs seem to honor context cancelation.

Is there some other way for the client to indicate it is no longer
interested in the stream?

—
Reply to this email directly or view it on GitHub
#188.

[iamqizhao]

ok, the right pattern to cancel a stream in your use case is as follows:

for {
  reply, err := stream.Recv()
  if err != nil {
    ...
  }
  if A {
    // not caring from now
    ctx.Cancel()
-  // YOU NEED TO KEEP READING UNTIL YOU GET CANCELED ERROR.*
  for {
    // stream.Recv() will make sure to cancel server side context if
  necessary.
    if _, err := stream.Recv(); err != nil {
      break
    }
  }
  }
  }

This design is intended because other alternatives either increases a fair
amount of overhead (a lot of more goroutine spawned by grpc) or introduces
much long latency to detect a cancellation. I should add this into the
document anyways.

Let me know if your issue gets addressed by this. Thank you for reporting.

On Fri, May 8, 2015 at 10:07 AM, Qi Zhao toqizhao@gmail.com wrote:

looking..

On Fri, May 8, 2015 at 7:45 AM, Russ Amos notifications@github.com
wrote:

I have a stream defined that will send messages perpetually to the
client, until the client is no longer interested. Since there is no
"stream.Close" on the client side (only stream.CloseSend), I assume using
context.WithCancel on the client side is the correct way to do this.
However, it seems like cancelation is not being propagated to the server:
The server continues calling Send (with no errors) long after the client
stops caring, and eventually the Send blocks entirely and the server's
goroutine hangs. I think the goroutines are unblocked and exit if the
connection is closed, but I didn't test that thoroughly.

Unary RPCs seem to honor context cancelation.

Is there some other way for the client to indicate it is no longer
interested in the stream?

—
Reply to this email directly or view it on GitHub
#188.

[iamqizhao]

fixed by #189