>>>>>
>>>>>> 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.
Well, we state, that SelectionKeyHandler is responsible for handling
SelectionKey lifecycle, so IMHO extending it and overriding
cancel(SelectionKey) looks more or less straightforward.
But anyway, if there are ideas, how it could be improved - I'm always
+1 :))
Thanks.
WBR,
Alexey.
>
> -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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>