Re: Differentiating Connection Timeouts and Closes

[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

[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