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 <ol...@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 <ol...@apache.org>: > > > > > > > On January 29, 2014 5:38:13 PM CET, Thomas Boniface < > > tho...@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-unsubscr...@hc.apache.org > > > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
