You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Roland Weber (JIRA)" <ji...@apache.org> on 2008/02/03 18:14:09 UTC
[jira] Resolved: (HTTPCLIENT-740) AbstractConnPool constructor
calls thread.Start()
[ https://issues.apache.org/jira/browse/HTTPCLIENT-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber resolved HTTPCLIENT-740.
-------------------------------------
Resolution: Fixed
Fix Version/s: 4.0 Alpha 3
Assignee: Roland Weber
Hi Sebastian,
the started thread implements a callback when connections or the connection manager are garbage collected. There are no connections that can be GCed before the constructor returns, and the connection manager is hard referenced from the call stack. Hence, the callback cannot be triggered unless somebody puts maliciously stupid code into derived class constructors.
The reason why I start the thread immediately after creating the reference queue is to make sure that the reference queue is being handled. If I split this in two methods, somebody will create the reference queue without starting the thread, thereby creating a memory leak.
Anyway, I moved the code for creating both reference queue and callback thread to an extra method that has to be called after creating the connection pool. I hope this addresses your requirements as well as mine. The price to pay is that derived classes can no longer populate the pool in the constructor if they want to support connection GC, since the reference queue must be known when creating a pool entry.
Please review the change (revision 618019).
cheers,
Roland
> AbstractConnPool constructor calls thread.Start()
> -------------------------------------------------
>
> Key: HTTPCLIENT-740
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-740
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpClient
> Reporter: Sebb
> Assignee: Roland Weber
> Priority: Trivial
> Fix For: 4.0 Alpha 3
>
>
> AbstractConnPool constructor calls thread.Start()
> Findbugs says:
> Constructor invokes Thread.start()
> The constructor starts a thread. This is likely to be wrong if the class is ever extended/subclassed, since the thread will be started before the subclass constructor is started.
> The class is not final (and the constructor is protected) which suggests that the class is intended to be extended...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org