You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Asankha C. Perera" <as...@apache.org> on 2012/01/15 20:51:33 UTC
Differentiating Connection Timeouts and Closes
Hi All
When a connection times out or is closed with NIO, I'd like to know if
this connection has any content read already or pending - i.e. is the
connection timeout or close happening to a partially read connection or
to an idle keep-alive connection (I'd like to know even if some headers
have been read.. not just entity content..)
I was not able to find any safe way to achieve this yet.. Have I missed
anything obvious?
thanks
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Differentiating Connection Timeouts and Closes
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
Re: Differentiating Connection Timeouts and Closes
Posted by "Asankha C. Perera" <as...@apache.org>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Differentiating Connection Timeouts and Closes
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2012-03-29 at 10:25 +0530, Hiranya Jayathilaka wrote:
> Hi Oleg,
>
> On Mon, Jan 16, 2012 at 2:41 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Mon, 2012-01-16 at 01:21 +0530, Asankha C. Perera wrote:
> > > Hi All
> > >
> > > When a connection times out or is closed with NIO, I'd like to know if
> > > this connection has any content read already or pending - i.e. is the
> > > connection timeout or close happening to a partially read connection or
> > > to an idle keep-alive connection (I'd like to know even if some headers
> > > have been read.. not just entity content..)
> > >
> > > I was not able to find any safe way to achieve this yet.. Have I missed
> > > anything obvious?
> > >
> > > thanks
> > > asankha
> > >
> >
> > Hi Asankha
> >
> > 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.
> >
>
> This is very interesting. Does this mean that whenever the closed event is
> fired on a client handler, there is a chance that the connection many have
> some pending data? For an example if we are in the middle of a
> request-response interaction, and the closed event is fired even before the
> responseReceived event, is there a possibility that the response may be
> received if we keep the connection open?
>
Hiranya
The closed event fires only if the connection has been _explicitly_
closed on the local end. So, to answer your question there can still be
some data stuck in the session buffer, but this can only happen if the
protocol hander closed the connection without consuming all data
available.
Hope this answers your question.
Oleg
> Thanks,
> Hiranya
>
>
> >
> > Both cases are quite easy to distinguish. Hope this answers your
> > question.
> >
> > Cheers
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Differentiating Connection Timeouts and Closes
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Oleg,
On Mon, Jan 16, 2012 at 2:41 AM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2012-01-16 at 01:21 +0530, Asankha C. Perera wrote:
> > Hi All
> >
> > When a connection times out or is closed with NIO, I'd like to know if
> > this connection has any content read already or pending - i.e. is the
> > connection timeout or close happening to a partially read connection or
> > to an idle keep-alive connection (I'd like to know even if some headers
> > have been read.. not just entity content..)
> >
> > I was not able to find any safe way to achieve this yet.. Have I missed
> > anything obvious?
> >
> > thanks
> > asankha
> >
>
> Hi Asankha
>
> 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.
>
This is very interesting. Does this mean that whenever the closed event is
fired on a client handler, there is a chance that the connection many have
some pending data? For an example if we are in the middle of a
request-response interaction, and the closed event is fired even before the
responseReceived event, is there a possibility that the response may be
received if we keep the connection open?
Thanks,
Hiranya
>
> Both cases are quite easy to distinguish. Hope this answers your
> question.
>
> Cheers
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
--
Hiranya Jayathilaka
Associate Technical Lead;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: Differentiating Connection Timeouts and Closes
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2012-01-16 at 01:21 +0530, Asankha C. Perera wrote:
> Hi All
>
> When a connection times out or is closed with NIO, I'd like to know if
> this connection has any content read already or pending - i.e. is the
> connection timeout or close happening to a partially read connection or
> to an idle keep-alive connection (I'd like to know even if some headers
> have been read.. not just entity content..)
>
> I was not able to find any safe way to achieve this yet.. Have I missed
> anything obvious?
>
> thanks
> asankha
>
Hi Asankha
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.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org