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 >
