C# Cleanly cancelling streaming call

[neilg...@gmail.com]

How are people cancelling streaming calls from the client without exception on client or server? See my GitHub issue for details
https://github.com/grpc/grpc/issues/8277

I can see how you might do this with bidirectional streaming and start message followed by a stop or something similar but it feels like this kind of thing should just work out the box.

[Jan Tattermusch]

On Mon, Oct 17, 2016 at 9:00 PM, <neilg...@gmail.com> wrote:

How are people cancelling streaming calls from the client without exception on client or server?

There's no such thing as cancelling a call without a non-OK status (and therefore an exception).

 

ee my GitHub issue for details
https://github.com/grpc/grpc/issues/8277

I can see how you might do this with bidirectional streaming and start message followed by a stop or something similar but it feels like this kind of thing should just work out the box.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/439a51a5-bad8-45c3-ad9f-bf5c6d6c8d29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[neilg...@gmail.com]

I'm using the term cancel but equally I could say complete. The point is the client needs a way to tell the server it's done and doesn't care about any future responses. Both client and server then need to clean up any resources and not log any exceptions.

[Jan Tattermusch]

I believe the approach suggested by me in https://github.com/grpc/grpc/issues/8277 meets your needs. 

On Tue, Oct 18, 2016 at 10:39 AM, <neilg...@gmail.com> wrote:

I'm using the term cancel but equally I could say complete. The point is the client needs a way to tell the server it's done and doesn't care about any future responses. Both client and server then need to clean up any resources and not log any exceptions.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c56fc7ae-dae5-4376-9e05-30cd3df28b5d%40googlegroups.com.

[Nathaniel Manista]

On Tue, Oct 18, 2016 at 1:39 AM, <neilg...@gmail.com> wrote:

The point is the client needs a way to tell the server it's done and doesn't care about any future responses. Both client and server then need to clean up any resources and not log any exceptions.

It seems like what you're describing (at least on the client side) is "fire-and-forget" semantics, which we considered and decided not to make a part of gRPC.

-Nathaniel

[neilg...@gmail.com]

Sort of but not entirely. The client is definitely interested in getting messages back, hence the use of the streaming api. However it will be part of the normal lifecycle for the client to want to close down, complete, cancel whatever we want to call it. When this happens the server needs to know of the clients intention to stop receiving messages and tear everything down. I can do this with the cancellation api but not without exceptions on the client and the server. Jan suggested using the bidirectional streaming so the client can call CompleteAsync. This works when the server sends back a response and then waits for the next request. My use case is a little different as the server will keep that stream open by never returning a completed task from the initial request, it just writes to the response stream. Perhaps it's just not supported out the box.