Grpc Java Server Side Streaming server stream cancellation detection

[Isuru Samaraweera]

Hi All,

I am using grpc java with serverside streaming.In the grpc server side streaming service I am doing streaming such as below to detect stream cancellations due to network errors.

while(true) {

if(Context.current().isCancelled()) {

responseObserver.onNext(response)

} else break;

The issue is when I disconnect the client still onNext invokes around 100 times before network failure is detected by Context.current().isCancelled().

To prevent this I did as below.

while(true) {

Thread.sleep(500)

if(Context.current().isCancelled()) {

responseObserver.onNext(response)

} else break;

Now it seems isCancelled is detected before onNext is called when network between client and server is disrupted.This implies cancel=true is updated by a separate thread apart from main thread??

Is there any better way of doing this using GRPC Java?

Thanks

Isuru

[Carl Mastrangelo]

You can turn on keep alives on the channel / server builder, but that's about the best you can do.  The problem is that a broken connection just means silence.  You can't tell the difference between the packets taking a long time, and the the packets not arriving.  Keep-alives let you check the connection is still active, and close it after a time out (like 10s).  

[Isuru Samaraweera]

Hi Carl,

So when you enable keep alive with 5 mins and 10 second keepalivetimeout connection will be checked for activeness and if time out elapsed it will be closed. Thats clear..So whats happening when you say Context.current().isCancelled()??Does it do  ping internally ?How it is done?

Because when network cable is unplugged from server Context.current().isCancelled() takes sometime to detect cable detachment(like 1-2 seconds).When I delay main thread by Thread.sleep(500) I can reduce data stream loss which is fine in my case.My question is on how Context.current().isCancelled() is implemented??Is it doing a real time ping or listening to a flag set by another thread?

Thanks

Isuru

--
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+u...@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/4dc517ad-195c-420f-9f7a-4e73aa78b659%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Isuru Samaraweera

[Eric Anderson]

When the TCP connection is detected to be broken, all RPCs on that connection are cancelled. This calls context.cancel(). That immediately does two things: changes the boolean that isCancelled() returns and calls/schedules all cancellation listeners (registered via addListener()). So the isCancelled() method is passive.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAOtGh-rYyqWaKPLxyEyS9xXQOhyP0P8FS1MwyibO8Ke-VbXDiQ%40mail.gmail.com.

[Isuru Samaraweera]

So it seems breaking of  TCP connection is detected by a separate thread than the main thread right?

--

Isuru Samaraweera

[Eric Anderson]

Yes. Java does I/O on a separate thread, and that thread notices the broken TCP connection.

[Isuru Samaraweera]

Ok, thanks for the clarification. 

--

Isuru Samaraweera