hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Differentiating Connection Timeouts and Closes
Date Mon, 16 Jan 2012 18:47:52 GMT
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message