users@grizzly.java.net

Re: Detecting Connection closed when using ProtocolParser

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Fri, 23 May 2008 17:57:26 +0200

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

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
>