[jboss-jira] [JBoss JIRA] Commented: (JBAS-4429) Classloader leak to JBossTS ReaperThread

[Clebert Suconic (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-4429?page=comments#action_12365456 ] 
            
Clebert Suconic commented on JBAS-4429:
---------------------------------------

The ReaperThread is started only once from what I could see at:

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/labs/labs/jbosstm/tags/JBOSSTS_4_2_3_SP4/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/TransactionReaper.java?view=markup

But it looks like it could use whatever is the first application's classloader to start the first transaction. That's why depending on how you configure your application server, the behavior could change.


The solution would be:

- something starting the ReaperThread outside of the client's application, since the leak is on ReaperThread::contextClassLoader...

- Or changing the contextClassLoader by hand when the ReaperThread is started.

I actually like the second option more...  So you just need to set the ContextClassLoader like this:


public void run ()
    {
          this.setContextClassLoader(ReaperThread.class.getClassLoader());


Making this change at:

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/labs/labs/jbosstm/tags/JBOSSTS_4_2_3_SP4/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/coordinator/ReaperThread.java?revision=12235&view=markup


> Classloader leak to JBossTS ReaperThread
> ----------------------------------------
>
>                 Key: JBAS-4429
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4429
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.2.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Clebert Suconic
>         Attachments: cl-leak.zip
>
>
> ClassloaderLeakUnitTestCase is showing a classloader leak when the test does remote calls to EJB2 SLSBs.  See http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.2-testsuite-1.5?log=log20070518001349
> JBoss Profiler analysis (see attached) shows the leak is to the JBossTS ReaperThread -- the DelegatingClassLoader for the ejb jar deployment is set as the TCCL on that thread.
> Oddities I observed while trying to track this down:
> 1) The leak doesn't occur if JMS is deployed.  By mistake I changed the AS config for the test such that JBossMQ no longer gets deployed; that's when the leak appeared.  The test doesn't use JMS in any way.  Can only speculate that if MQ is running the TCCL on the ReaperThread gets cleared or changed somehow or never gets set to the ejb's DelegatingClassLoader.
> 2) The test class includes 3 different tests that basically make the same calls. The differences between the tests is just how the ejbs are packaged -- one in a plan jar, one with an ear and the plain jar, one with the ear but a loader-repository configured.  Only the first of these that gets executed fails; the other two pass.  I changed the order in which the tests execute, and whichever was first failed.  Hence the success/failure doesn't appear to be a function of the packaging.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira