users@grizzly.java.net

Re: Detecting Connection closed when using ProtocolParser

From: Harsha Godugu <Harsha.Godugu_at_Sun.COM>
Date: Fri, 23 May 2008 09:08:32 -0700

Oleksiy Stashok wrote:

>> Oleksiy Stashok wrote:
>>
>>>> we also have an issue on that:
>>>>
>>>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=85
>>>>
>>>> whrere Alexey commented the situation.
>>>>
>>>> Oleksiy Stashok wrote:
>>>>
>>>>> Hello John,
>>>>> try to extends Default or Base SelectionKeyHandler (depends which
>>>>> one you're using) and override method cancel(SelectionKey) - IMHO
>>>>> it will be the right place to be notified about closed connections.
>>>>
>>>>
>>>>
>>>> I'm not 100% sure. How will you know the key has been canceled by
>>>> the user of because of a -1 (BTW win32 will thrown an IOException,
>>>> and never return -1).
>>>
>>> Right, so as I said, IMHO it's better to override
>>> SelectionKeyHandler.cancel(SelectionKey), which should be common
>>> solution :)
>>
>>
>> But how will you detect the connection as been closed? By invoking
>> again key.channel.read()? That doesn't sound correct :-) Code sniped
>> required :-)
>
> My assumption (may be wrong) was that, once connection is getting
> closed - NIO initiates OP_READ event on its SelectionKey, where
> key.channel.read() will return -1 or EOFException.
> So once Java NIO implementation will recognize connection as closed -
> we will know about that.

I'm already using this (the above logic) in my implementation to detect
connection closure (end --of-stream) from/by peer.
You are right Alexey :-).
We only need to hide (make it easy) these details for the user.
-hg

>
> May be I'm wrong :)
>
> Thanks.
>
> WBR,
> Alexey.
>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>>> Thanks.
>>> WBR,
>>> Alexey.
>>>
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> -- Jeanfrancois
>>>>
>>>>
>>>>> WBR,
>>>>> Alexey.
>>>>> On May 23, 2008, at 14:30 , John ROM wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm testing in my code all kinds of Connection-broken situations.
>>>>>>
>>>>>> I have an ProtocolParser on the Client.
>>>>>>
>>>>>> During a lengthy read operation I just testwise kill the server.
>>>>>>
>>>>>> The ReadFilter then correcty reads -1 which I think
>>>>>> is the NIO Way of reporting a closed Connection.
>>>>>>
>>>>>> Now the current selectionKey gets correctly canceled by Grizzly.
>>>>>>
>>>>>> Now I would somehow like to get a notice of that -1 Event but don't
>>>>>> know where to hook myself in?
>>>>>>
>>>>>> Right now I am considering of using a second thread and
>>>>>> to keep sending short messages to the server and by this detecting
>>>>>> the closed connection on a write. Would that me the most elegant
>>>>>> way?
>>>>>>
>>>>>> many Greetings
>>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Psssst! Schon vom neuen GMX MultiMessenger gehört?
>>>>>> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>