PoolingClientConnectionManager PoolStats and potential connection leak concern

Question

I'm using PoolingClientConnectionManager and I am suspecting that I'm leaking connections. I have a monitoring thread that prints out the PoolStats as below:

[leased: 126; pending: 0; available: 14; max: 140]
..
[leased: 140; pending: 20; available: 0; max: 140]
..
[leased: 140; pending: 10; available: 0; max: 140]

I spawn an equal number of threads to the number of pool connections (140), so I was never expecting leased + pending > max. Is this assumption valid ? Or is this a case of connections kept alive by the manager ? I'm not sure if this case the connections are attributed to "lease" or "available".

What I have noticed is that connection leaks might occur if the HttpClient connection is interrupted during DNS resolve. In this scenario, leased connections are not released back to the pool. Is there a suggested way of de-allocating proper resources so that connections are properly released back to the pool ?

Thanks in advance.

Answer 1

Yes, it does seem quite likely that there is a connection leak. It is unlikely that DNS lookup could be causing it though. HttpClient is supposed to release connection automatically in case of an i/o, protocol or runtime exception.

As far as resource deallocation is concerned the rule should be fairly simple: as long as there is an entity associated with the response, one must make sure its content gets fully consumed. HttpClient 4.2 and HttpClient 4.3 also provide additional safe-guards for resource deallocation in exceptional cases: HttpUriRequest#releaseConnection in 4.2 and CloseableHttpResponse#close in 4.3

You could also try running your application with connection management context logging turned on as described here and see if that could help you track down requests that never release the underlying connection.