Ok, thanks for the clarification.

On Mon, May 6, 2019 at 8:48 PM Eric Anderson <[email protected]> wrote:

> 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
>>
>

-- 
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-o_tATjYorp3UnPtWSnNcLueParTKycobc8M88aJ9Rabw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to