You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2011/06/22 20:51:47 UTC
[jira] [Updated] (HTTPCLIENT-1104) Add way to check for release of
connections back into pool
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCLIENT-1104:
------------------------------------------
Fix Version/s: 4.2 Final
Issue Type: Improvement (was: Wish)
> Add way to check for release of connections back into pool
> ----------------------------------------------------------
>
> Key: HTTPCLIENT-1104
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1104
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Reporter: John Karp
> Priority: Minor
> Fix For: 4.2 Final
>
>
> As the documentation emphasizes, its important to clean up HttpEntities after use, so they don't tie up the default very small number of connections in the pool.
> However, nothing is provided to HttpClient users with the default classes that allows them to unit test their code to help verify that they are in fact properly releasing the connections under all circumstances. One way this could be done is for the API to expose the number of current leased (taken) connections in the pool, which would be connManager.pool.leasedConnections.size() if not for the necessary fields being protected. If this statistic were published through the API, user unit tests could check that it is zero when they finish.
> A workaround is for the user to subclass both the connection manager and ConnPoolByRoute and add getter methods. But its kind of a clunky solution, and I think the API should be written to encourage its users to perform this check.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org