Pooling managers: offload connection disposal from the pool lock.

[arturobernalg]

Close sockets off the pool lock via an async disposer. Improves lease latency under eviction/state mismatch with slow close.Includes classic/async tests and default-disposer baseline.

[ok2c]

@arturobernalg This functionality is necessary for the classic connection management only where connections can get blocked in the #close method. The async connection management is unaffected as #close method there merely enqueues a command to be executed by the i/o reactor asynchronously.

Please reduce the scope to PoolingHttpClientConnectionManager only

[arturobernalg]

@arturobernalg This functionality is necessary for the classic connection management only where connections can get blocked in the #close method. The async connection management is unaffected as #close method there merely enqueues a command to be executed by the i/o reactor asynchronously.

Please reduce the scope to PoolingHttpClientConnectionManager only

Done

[arturobernalg]

removed.

[ok2c]

@arturobernalg This is a lease lock., not a global pool lock. It is perfectly OK to call #drainDisposals inside the method, for instance, at line 395 (prior to final ManagedHttpClientConnection conn = poolEntry.getConnection();)

[arturobernalg]

@arturobernalg This is a lease lock., not a global pool lock. It is perfectly OK to call #drainDisposals inside the method, for instance, at line 395 (prior to final ManagedHttpClientConnection conn = poolEntry.getConnection();)

@ok2c drainDisposals() now runs inside LeaseRequest#get right before poolEntry.getConnection() (lease lock only), with the final safety drain retained; tests updated accordingly.

[ok2c]

@arturobernalg The chances of anything going wrong in the remaining code is super-slim. And if it did happen the queue would get drained by another call / thread. But I think one #drainDisposals call should be enough here. Pick one you prefer. I leave it up to you.

[ok2c]

@arturobernalg Now the big question is whether this approach is stable enough to be activated by default or shall we mark it experimental and make optional in 5.6 release series?

[arturobernalg]

Now the big question is whether this approach is stable enough to be activated by default or shall we mark it experimental and make optional in 5.6 release series?

@ok2c
opt-in experimental for 5.6, gather data, then flip on by default in 5.7 if no regressions... Please take another look.

[ok2c]

@arturobernalg Looks good to me.