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: Scott M Stark 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?lo... 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