[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
