commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] Commented: (POOL-161) ContextClassLoader problems for the Evictor thread
Date Sat, 05 Jun 2010 14:16:09 GMT

    [ https://issues.apache.org/jira/browse/POOL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875907#action_12875907
] 

Phil Steitz commented on POOL-161:
----------------------------------

We seem to be talking about three different issues here:

1. The issue that Mark's commit fixed - potential for memory leak when the class loader for
the eviction thread is not the same loader that loaded the library.  IIUC, Mark's patch fully
fixes this issue and any other potential for classloader leaks associated with the evictor.
 Correct?

2. Feature request to support the use case in the issue description.  Looks to me like Mark's
patch actually does fully fix the issue as narrowly defined above.  I must be missing something
here.

3. Feature request for pool to work in arbitrary multi-classloader environments

I agree with Mark that it is not obvious that we should aim to support 2., and I think we
have some work do to in defining exactly what 3. means.  I am strongly +1 on doing everything
we can to avoid leaks. 

> 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.


Mime
View raw message