Salut,
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).
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
>