On Mon, 2012-01-16 at 16:07 +0530, Asankha C. Perera wrote: > 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. >
Sounds reasonable. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
