Hello all,
Typically, a technique that I've implemented was using the fact that,
when the remote peer is disconnected for any reason, the corresponding
SelectionKey on the server becomes readable().
It is possible to use this when you know for example that the connection
should be either idle or waiting for the server to send something. In
this case, you just need to add OP_READ to the operations the key is
interested in.
For instance, if an idle connection becomes suddenly readable - as in
SelectionKey.isReadable() - then it means it is disconnected.
For this to apply, you also need to keep some state attached to the
SelectionKey, so that you know that it is readable when it shouldn't.
This technique covers the cases when you are not actively performing I/O
on the channel. In the other cases, an IOException will be thrown as
soon as you try to read from or write to the channel, so that's easier
to handle.
Unfortunately, I do not know if there is a way to emulate this behavior
using Mina. Is it possible at all ?
Thanks,
-Laurent
On 12/01/2010 03:49, hakan eryargi wrote:
As far as I understand the way NIO works, when the clinet has brutally closed
the connection (ie, no FIN), the selector won't be informed about any
modification regarding this socket, so its SelectionKey will never be returned
on a select() operation.
just for curiosity, is this different from a blocking socket
connection ? i mean, is there something different for NIO that it cant
detect a disconnected client but a blocking server can ?
On Tue, Jan 12, 2010 at 4:17 AM, Emmanuel LŽcharny<elecha...@gmail.com> wrote:
Patrick Sansoucy a écrit :
Sorry to jump on the thread, but I'm a bit surprised by (and curious about) the
behavior exposed here and the fact that Mina does not detect it ...
Is the connections between your 2 boxes direct (ie no proxy or firewall)
because I witnessed a couple of years ago the exact same behavior with one of
our application and we found out that the issue was that a proxy was leaving
the socket hanging there making the client or server think it was still active.
From what I remember from our diverse implementation at work (I am not
familiar with Mina's inner working). I think the poll would indicate something
occurred and a read confirm the socket closing (cleanly or not).
As far as I understand the way NIO works, when the clinet has brutally closed
the connection (ie, no FIN), the selector won't be informed about any
modification regarding this socket, so its SelectionKey will never be returned
on a select() operation.
I any case, we don't poll.
Am I missing something ?
