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