Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1333121196.13912.7.camel@ubuntu>
Subject: Re: Differentiating Connection Timeouts and Closes
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Date: Fri, 30 Mar 2012 17:26:36 +0200
In-Reply-To: 
 <CAGeidJ6UAF1EJ8mN_B-QR-1W1fC948SNkboGYsVrS=k0r=6FXA@mail.gmail.com>
References: <4F132E45.7080705@apache.org> <1326661874.19014.25.camel@ubuntu>
	 <CAGeidJ6UAF1EJ8mN_B-QR-1W1fC948SNkboGYsVrS=k0r=6FXA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0

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 <olegk@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