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 ? Also if the client does the job, when does it triggers the
cleaning (on regular basis, on low load) ?

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

Reply via email to