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 > > > 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 <[email protected]> > 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 <[email protected] > > > > > 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: [email protected] For additional commands, e-mail: [email protected]
