Hi Oleg
Timeout event fired by an I/O reactor simply signals the fact that there
has been no activity on that I/O session for the given timeout period.
The I/O session itself remains in a perfectly valid state. It is up to
individual protocol handlers to decide what is to be done with that
session. The default implementations simply close the timed out session
but it does not have to be that way.
As far as closed I/O sessions are concerned, if closed by the opposite
end, the I/O session can still be read from as long as there is pending
data. Once all input has been received read operations on that session
will start returning -1 indicating the connection is being in a
half-closed state. It is still up to individual protocol handlers to
decide what is to be done with the session. Closing it on the local end
is the most natural choice.
Both cases are quite easy to distinguish. Hope this answers your
question.
Thanks for the detailed reply.. So from an EventListener implementation,
checking "conn.getMetrics().getReceivedBytesCount()" etc should tell me
if this connection has any bytes we've already read/received. My plan is
to reset the connection metrics after each request, and thus use the
above to detect any partial read on a timed out/closed connection.
regards
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
