commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POOL-161) ContextClassLoader problems for the Evictor thread
Date Mon, 13 Feb 2012 23:22:59 GMT

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

Mark Thomas commented on POOL-161:
----------------------------------

Craig: Per context use of commons pool does avoid this bug and does not trigger a memory leak.
The problem you are describing is not a pool bug but the application's (or possibly the container's
depending on exact usage) failure to correctly shutdown the pool when the context stops. For
the record Tomcat handles this correctly. The workaround you describe for glassfish will trigger
the bug that Sylvain describes in point 2.

Sylvain: Thanks for the patch. It has been applied - with some minor tweaks to 1.6.x and will
be included in 1.6.1 onwards. I will back-port it to 1.5.x forward port it to 2.x shortly.
                
> 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: 1.6.1, 2.0
>
>         Attachments: TestGenericObjectPoolClassLoader.patch.txt, patch_Evictor_CCL.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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message