just a though - it is possible that socket buffers of the underlying
OS and TCP_NO_DELAY=off settings are getting in the way of reliably
detecting network disconnect.
/i
On Jan 4, 2010, at 10:50 AM, ichinco wrote:
>
> Hi!
>
> Back from break now!
>
>
> Oleksiy Stashok wrote:
>>
>> Agree. From what I know, if connection was closed read() operation
>> will return either -1 or throw IOException (depending on OS and JDK).
>> Unfortunately it's also true, that write operation may succeed on
>> connection, which was closed by peer.
>>
>> Also agree, that "Heart beat" mechanism could be a good solution.
>>
>
> I tried this as well, with no success. (read returns 0 and does not
> throw
> and exception, even when the network cable is pulled.)
>
> I can think of two things:
>
> First, we're using non-blocking I/O. Is it possible that there is an
> error,
> but that we aren't seeing it?
>
> Second, is it possible that it will only error after some timeout?
> If so,
> where do I set the timeout? (I've tried
> TCPSelectorHandler.socketTimeout,
> but can't seem to figure out under what circumstances it would
> actually
> timeout or what that would look like on the server side.)
>
> I'm not an expert on sockets by any means, but it seems like sockets
> that
> are "normally" closed send and EOF, get handled by the
> ConnectionClosedHandler, and return -1 if you try to read from them.
> In this
> case, we're not getting the EOF, and we're not getting any of the
> other
> stuff either. Without an EOF, then, we're screwed?
>
> Any ideas?
>
> --
> View this message in context: http://old.nabble.com/detect-network-disconnected--tp26891745p27017513.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>