[
https://issues.apache.org/jira/browse/POOL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876046#action_12876046
]
Phil Steitz commented on POOL-161:
----------------------------------
Thanks, Sylvain. My mistake on 2.
I am on the fence as to whether to apply Sylvain's patch for 1.5.x or wait
until 2.0 to fully fix the issue. Does anyone see any risk in applying the
patch in 1.5.5? If we don't apply it, we should at least update the docs to
make it clear that the evictor is nailed to the loader used to load the library.
> ContextClassLoader problems for the Evictor thread
> --------------------------------------------------
>
> Key: POOL-161
> URL: https://issues.apache.org/jira/browse/POOL-161
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.5.4
> Reporter: Sylvain Laurent
> Fix For: 2.0
>
> Attachments: patch_Evictor_CCL.txt,
> TestGenericObjectPoolClassLoader.patch.txt
>
>
> Since a single Timer is used for several GenericObjectPool instances, this
> may create classloader issues and a memory leak of one classloader :
> Let's imagine the following scenario :
> - commons-pool.jar is in the classpath of a webapp container (e.g. tomcat).
> - 2 webapps A and B are deployed, each creating an instance of
> GenericObjectPool for its own usage.
> - each webapp makes use of the idle object evictor and sets a positive number
> for minIdle
> - first, webapp A instantiates its GenericObjectPool. Since this is the first
> TimerTask to be created, the Timer instance is created, thus creating a
> Thread whose ContextClassLoader is the current one, that is webapp A's
> ContextClassLoader.
> The TimerTask properly creates instances of idle objects in the pool, making
> use of the ObjectFactory provided by A.
> - then B instantiates its GenericObjectPool. A new TimerTask is created, and
> it tries to invoke the ObjectFactory provided by B. But when it needs a class
> that only exists in B webapp, it cannot find it because the
> ContextClassLoader of the Timer Thread is A's classloader.
> Other side effect : if webapp A is undeployed, but B is still running, then
> A's webappClassLoader cannot be GCed because the Timer Thread keeps a strong
> reference to A's classloader (as its context classloader).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
