Yes. Java does I/O on a separate thread, and that thread notices the broken TCP connection.
On Mon, May 6, 2019 at 8:13 AM Isuru Samaraweera <[email protected]> wrote: > So it seems breaking of TCP connection is detected by a separate thread > than the main thread right? > > > On Mon, May 6, 2019 at 8:39 PM Eric Anderson <[email protected]> wrote: > >> When the TCP connection is detected to be broken, all RPCs on that >> connection are cancelled. This calls context.cancel() >> <https://grpc.github.io/grpc-java/javadoc/io/grpc/Context.CancellableContext.html#cancel-java.lang.Throwable->. >> That immediately does two things: changes the boolean that isCancelled() >> returns and calls/schedules all cancellation listeners (registered via >> addListener() >> <https://grpc.github.io/grpc-java/javadoc/io/grpc/Context.html#addListener-io.grpc.Context.CancellationListener-java.util.concurrent.Executor->). >> So the isCancelled() method is passive. >> >> On Sat, May 4, 2019 at 3:39 AM Isuru Samaraweera <[email protected]> >> wrote: >> >>> 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 >>> >>> On Thu, May 2, 2019 at 10:44 PM 'Carl Mastrangelo' via grpc.io < >>> [email protected]> wrote: >>> >>>> 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). >>>> >>>> On Tuesday, April 30, 2019 at 9:10:22 AM UTC-7, Isuru Samaraweera wrote: >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> 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 >>>> <https://groups.google.com/d/msgid/grpc-io/4dc517ad-195c-420f-9f7a-4e73aa78b659%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> -- >>> Isuru Samaraweera >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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/CAOtGh-rYyqWaKPLxyEyS9xXQOhyP0P8FS1MwyibO8Ke-VbXDiQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/grpc-io/CAOtGh-rYyqWaKPLxyEyS9xXQOhyP0P8FS1MwyibO8Ke-VbXDiQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> > > -- > Isuru Samaraweera > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CA%2B4M1oNs6JJEn%2BQgVccP5PetFy_5fYu7Xjq-xLSQYN1SbOag7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
