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 <[email protected]>: > > > On January 29, 2014 5:38:13 PM CET, Thomas Boniface <[email protected]> > > 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
