hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Cancel and socket state
Date Thu, 30 Jan 2014 12:01:14 GMT
On Thu, 2014-01-30 at 10:47 +0100, Thomas Boniface wrote:
> Oleg,
> 
> Concerning the unsafe underlying connections you mention. Do I have to
> explicitly discard them myself or does the http async client handles this
> by itslef ?

HC will take care of that automatically. 

>  Also if the client does the job, when does it triggers the
> cleaning (on regular basis, on low load) ?
> 

Upon connection release. No connections with an inconsistent state
should ever end up in the pool.

I found and fixed the bug which caused the problem with connection
re-use in case of response future cancellation.

http://svn.apache.org/viewvc/httpcomponents/httpasyncclient/trunk/httpasyncclient/src/main/java/org/apache/http/impl/nio/client/DefaultClientExchangeHandlerImpl.java?r1=1562788&r2=1562787&pathrev=1562788

Please pull the latest source or get the latest snapshot from the
snapshot repository.

Oleg


> Thanks
> 
> 2014-01-30 Oleg Kalnichevski <olegk@apache.org>:
> 
> > On Thu, 2014-01-30 at 09:49 +0100, Thomas Boniface wrote:
> > > In case I don't do the cancel the connection is released and only
> > > disconnected once the keep alive timeout is reached.
> > >
> >
> > This is a very important bit of information. I'll see if I can reproduce
> > the same behavior locally.
> >
> > > I experience a file descriptor leak in my tomcat process and I was
> > > suspecting the request cancellation may be the source cause but it
> > appears
> > > it does not as not canceling the request do not solve the issue. Though I
> > > was expecting that canceling the request would get the connection back in
> > > the pool sooner that letting the request I don't need anymore finish.
> > >
> >
> > Please note that if an HTTP exchange cannot be fully completed the
> > underlying connection is simply unsafe to re-use and needs to be
> > discarded.
> >
> > Oleg
> >
> > > I will try to reproduce my leak issue in a simpler context.
> > >
> > > Thomas
> > >
> > >
> > > 2014-01-29 Oleg Kalnichevski <olegk@apache.org>:
> > >
> > > > On January 29, 2014 5:38:13 PM CET, Thomas Boniface <
> > thomas@stickyads.tv>
> > > > wrote:
> > > > >Thanks for your help regarding the snapshot. Here is an updated log
> > > > >using
> > > > >the 4.0.1-SNAPSHOT.
> > > > >
> > > > >Regarding request cancel, it is done as follow:
> > > > >
> > > > >if (futureHttpResponse != null && !futureHttpResponse.isCancelled())
{
> > > > >            futureHttpResponse.cancel(true);
> > > > >}
> > > > >
> > > > >where futureHttpResponse  what the object return by the execute call.
> > > > >
> > > > >Thomas
> > > >
> > > > Thomas,
> > > > I am sorry I cannot reduce the cause of the problem just by looking at
> > the
> > > > log.
> > > >
> > > > What happens if you do not cancel the request? Does the connection get
> > > > returned to the pool?
> > > >
> > > > Oleg
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > > >
> > > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


Mime
View raw message