You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2021/03/31 14:30:14 UTC
Proposed fix; Re: connection leak reproducer;
On Wed, 2021-03-31 at 15:31 +0200, Oleg Kalnichevski wrote:
> On Wed, 2021-03-31 at 13:42 +0200, Oleg Kalnichevski wrote:
> > On Tue, 2021-03-30 at 15:54 -0700, Ryan Schmitt wrote:
> > > Reproducer just dropped:
> > >
> > > https://github.com/rschmitt/httpclient-benchmark
> > >
> > > Just run the `benchmark` target as usual, using JDK11. I've
> > > tested
> > > it
> > > on
> > > Linux and macOS; Windows *will not work*. The output should look
> > > something
> > > like this:
> > >
> >
> > I can reproduce the issue and am trying to find its cause.
> >
> > Oleg
> >
>
> Hi Ryan
>
> I believe I have found the root cause of the leak. It is a classic
> race
> condition when a connection request completes and its requester gives
> up on it (request times out) at the about same time.
>
> I am working on a fix.
>
Hi Ryan
Here's the change-set that fixes the leak for me. It is probably not
the best solution but something that looked the simplest and the most
straight-forward to me. I will be trying to come up with something
better.
https://github.com/ok2c/httpcomponents-core/commit/68174a4faea82e3c9559da63438e4bfa9721a688
Oleg
> Did you have any luck reproducing the other defect?
>
> Oleg
>
>
> > > > > Task :benchmark
> > > > =================================
> > > > HTTP agent: Apache HttpClient (ver: 5.0)
> > > > =================================
> > > > 12800 GET requests
> > > > ---------------------------------
> > > > No connection leak detected...
> > > > Connection leak detected!
> > > > Connection leak detected
> > > > [leased: 3; pending: 0; available: 0; max: 8]
> > > > Document URI: http://localhost:8888/rnd?c=2000
> > > > Document Length: 0 bytes
> > > >
> > > > Concurrency level: 64
> > > > Time taken for tests: 0.349 seconds
> > > > Complete requests: 0
> > > > Failed requests: 128
> > > > Content transferred: 0 bytes
> > > > Requests per second: 0.0 [#/sec] (mean)
> > > >
> > > > BUILD SUCCESSFUL in 4s
> > > > 3 actionable tasks: 2 executed, 1 up-to-date
> > >
> > > On Tue, Mar 30, 2021 at 3:08 PM Ryan Schmitt <rs...@pobox.com>
> > > wrote:
> > >
> > > > No need to exchange messages. It turns out that you can
> > > > reproduce
> > > > this
> > > > issue purely with connection timeouts, or TLS handshake
> > > > timeouts.
> > > > It
> > > > appears that both the strict and the lax connection pools can
> > > > leak
> > > > connections, but it appears easier to reproduce with the strict
> > > > one.
> > > >
> > > > On Tue, Mar 30, 2021 at 1:52 PM Oleg Kalnichevski <
> > > > olegk@apache.org
> > > > wrote:
> > > >
> > > > > On Tue, 2021-03-30 at 13:35 -0700, Ryan Schmitt wrote:
> > > > > > Good news, actually: I think I *just* reproduced it now. I
> > > > > > ran
> > > > > > a
> > > > > > hacked up
> > > > > > benchmark that sends 100,000 HTTPS requests across 50
> > > > > > threads
> > > > > > with
> > > > > > various
> > > > > > randomized timeouts and delays, and after everything was
> > > > > > done
> > > > > > there
> > > > > > were
> > > > > > still two "leased" connections in the thread pool. This is
> > > > > > exactly
> > > > > > what I
> > > > > > was looking for. A turnkey repro and a fix might not be far
> > > > > > off
> > > > > > now.
> > > > > >
> > > > >
> > > > > All connections have a unique ID assigned to them at
> > > > > construction
> > > > > time
> > > > > which is also used in the context logs as a correlation id.
> > > > >
> > > > > If you could dump the ids of the connections still leased
> > > > > from
> > > > > the pool
> > > > > at the end of a benchmark run, you could look for
> > > > > abnormalities
> > > > > in
> > > > > message exchanges over those connections.
> > > > >
> > > > > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org