I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched to use the new classpools that understand AS classloading better. If there are no problems I'll do a GA over the next week or so On 16 Mar 2009, at 19:35, Jason T. Greene wrote: > Oh ok, well you have alot of time, freeze is 6 weeks away :) > > Kabir Khan wrote: >> It is ready to go. When is the freeze? I won't be around Wed-Fri this >> week. Tomorrow is a bit tight, but if the freeze is next week it >> should be possible >> On 16 Mar 2009, at 18:10, Jason T. Greene wrote: >>> Right, the question is can you have GA in place, with no >>> regressions, by the CR1 freeze? >>> >>> Dimitris Andreadis wrote: >>>> It depends how trouble-free you think this will be and what other >>>> changes would be needed by components using it. >>>> Kabir Khan wrote: >>>>> I have reimplemented the classpools used by javassist in AOP to >>>>> understand AS classloading better. For this I want to release an >>>>> AOP 2.1.0. Can this be included in AS 5.1.0? Or do I have to wait? >>>>> >>>>> Cheers, >>>>> >>>>> Kabir >>> >>> >>> -- >>> Jason T. Greene >>> JBoss, a division of Red Hat > > > -- > Jason T. Greene > JBoss, a division of Red Hat _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Kabir Khan wrote: > I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched to use > the new classpools that understand AS classloading better. If there > are no problems I'll do a GA over the next week or so It looks like a number of AOP tests are now failing after this update. Can you look into these? http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... -- Jason T. Greene JBoss, a division of Red Hat

I tested these when I commited, and reverting my local copy to my last commit (revision 86202) the aop tests all work. It must be something commited later. The main problems are anything involving the transaction aspects (ScopedUnitTestCase, ScopedAttachUnitTestCase, TxLockTestCase, TxTestCase, VersionedObjectTestCase) and security aspects (SecurityUnitTestCase). Looking at the changes to thirdparty jars nothing springs out http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/ Branch_5_x/component-matrix/pom.xml?r1=86546&r2=86201 On 31 Mar 2009, at 12:20, Kabir Khan wrote: > Sure > On 30 Mar 2009, at 21:30, Jason T. Greene wrote: > >> Kabir Khan wrote: >>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched to >>> use the new classpools that understand AS classloading better. If >>> there are no problems I'll do a GA over the next week or so >> >> It looks like a number of AOP tests are now failing after this >> update. Can you look into these? >> >> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Great thanks. Kabir Khan wrote: > It seems the classloader used to deploy the tx, security etc. > aspects is wrong so it cannot find the base-aspects.xml file before > running these tests. I'll fix and deploy a new CR. > On 1 Apr 2009, at 11:13, Kabir Khan wrote: >> I tested these when I commited, and reverting my local copy to my >> last commit (revision 86202) the aop tests all work. It must be >> something commited later. The main problems are anything involving >> the transaction aspects (ScopedUnitTestCase, >> ScopedAttachUnitTestCase, TxLockTestCase, TxTestCase, >> VersionedObjectTestCase) and security aspects >> (SecurityUnitTestCase). >> >> Looking at the changes to thirdparty jars nothing springs out >> http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/ >> Branch_5_x/component-matrix/pom.xml?r1=86546&r2=86201 >> >> >> >> On 31 Mar 2009, at 12:20, Kabir Khan wrote: >> >>> Sure >>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote: >>> >>>> Kabir Khan wrote: >>>>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched to >>>>> use the new classpools that understand AS classloading better. >>>>> If there are no problems I'll do a GA over the next week or so >>>> >>>> It looks like a number of AOP tests are now failing after this >>>> update. Can you look into these? >>>> >>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>> >>>> -- >>>> Jason T. Greene >>>> JBoss, a division of Red Hat >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development -- Jason T. Greene JBoss, a division of Red Hat

I've been looking into the cause of the classloader leak test failures[1] and am seeing leaks leading through org .jboss .aop.asintegration.jboss5.RegisterModuleCallback.registeredModules Looking further into it, I see RegisterModuleCallback.registerModule(Module) is called, but nowhere is removeModule(Module) called. The registerModule call is from JBossClDelegatingClassPoolFactory.create(...). [1] http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... Kabir Khan wrote: > I've released AOP 2.1.0.CR2 and upgraded AS Branch_5_x to use that > On 1 Apr 2009, at 18:38, Jason T. Greene wrote: >> Great thanks. >> >> Kabir Khan wrote: >>> It seems the classloader used to deploy the tx, security etc. >>> aspects is wrong so it cannot find the base-aspects.xml file >>> before running these tests. I'll fix and deploy a new CR. >>> On 1 Apr 2009, at 11:13, Kabir Khan wrote: >>>> I tested these when I commited, and reverting my local copy to >>>> my last commit (revision 86202) the aop tests all work. It must >>>> be something commited later. The main problems are anything >>>> involving the transaction aspects (ScopedUnitTestCase, >>>> ScopedAttachUnitTestCase, TxLockTestCase, TxTestCase, >>>> VersionedObjectTestCase) and security aspects >>>> (SecurityUnitTestCase). >>>> >>>> Looking at the changes to thirdparty jars nothing springs out >>>> http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/ >>>> Branch_5_x/component-matrix/pom.xml?r1=86546&r2=86201 >>>> >>>> >>>> >>>> On 31 Mar 2009, at 12:20, Kabir Khan wrote: >>>> >>>>> Sure >>>>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote: >>>>> >>>>>> Kabir Khan wrote: >>>>>>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched >>>>>>> to use the new classpools that understand AS classloading >>>>>>> better. If there are no problems I'll do a GA over the next >>>>>>> week or so >>>>>> >>>>>> It looks like a number of AOP tests are now failing after this >>>>>> update. Can you look into these? >>>>>> >>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> JBoss, a division of Red Hat >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

I've been looking into the cause of the classloader leak test failures[1] and am seeing leaks leading through org .jboss .aop.asintegration.jboss5.RegisterModuleCallback.registeredModules Looking further into it, I see RegisterModuleCallback.registerModule(Module) is called, but nowhere is removeModule(Module) called. The registerModule call is from JBossClDelegatingClassPoolFactory.create(...). [1] http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... Kabir Khan wrote: > I've released AOP 2.1.0.CR2 and upgraded AS Branch_5_x to use that > On 1 Apr 2009, at 18:38, Jason T. Greene wrote: >> Great thanks. >> >> Kabir Khan wrote: >>> It seems the classloader used to deploy the tx, security etc. >>> aspects is wrong so it cannot find the base-aspects.xml file >>> before running these tests. I'll fix and deploy a new CR. >>> On 1 Apr 2009, at 11:13, Kabir Khan wrote: >>>> I tested these when I commited, and reverting my local copy to >>>> my last commit (revision 86202) the aop tests all work. It must >>>> be something commited later. The main problems are anything >>>> involving the transaction aspects (ScopedUnitTestCase, >>>> ScopedAttachUnitTestCase, TxLockTestCase, TxTestCase, >>>> VersionedObjectTestCase) and security aspects >>>> (SecurityUnitTestCase). >>>> >>>> Looking at the changes to thirdparty jars nothing springs out >>>> http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/ >>>> Branch_5_x/component-matrix/pom.xml?r1=86546&r2=86201 >>>> >>>> >>>> >>>> On 31 Mar 2009, at 12:20, Kabir Khan wrote: >>>> >>>>> Sure >>>>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote: >>>>> >>>>>> Kabir Khan wrote: >>>>>>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched >>>>>>> to use the new classpools that understand AS classloading >>>>>>> better. If there are no problems I'll do a GA over the next >>>>>>> week or so >>>>>> >>>>>> It looks like a number of AOP tests are now failing after this >>>>>> update. Can you look into these? >>>>>> >>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> JBoss, a division of Red Hat >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development -- Brian Stansberry Lead, AS Clustering JBoss, a division of Red Hat brian.stansberry(a)redhat.com _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Hmm, perhaps that's not it then -- at least not directly. A debugger shows me that method isn't called. But there's other stuff on that report; so perhaps the Module isn't uninstalled properly. I'll keep poking tonight. Kabir Khan wrote: > Actually, RegisterModuleCallback.removeModule() should be called by > the MC. From bootstrap/aop.xml: > <bean name="AOPRegisterModuleCallback" > class="org.jboss.aop.asintegration.jboss5.RegisterModuleCallback"> > <incallback method="addModule" state="Installed"/> > <uncallback method="removeModule" state="Installed"/> > </bean> > > Anyway, I'll have a proper look tomorrow > > On 1 Apr 2009, at 20:02, Brian Stansberry wrote: > >> I've been looking into the cause of the classloader leak test >> failures[1] and am seeing leaks leading through >> org.jboss.aop.asintegration.jboss5.RegisterModuleCallback.registeredModules >> >> >> Looking further into it, I see >> RegisterModuleCallback.registerModule(Module) is called, but nowhere >> is removeModule(Module) called. The registerModule call is from >> JBossClDelegatingClassPoolFactory.create(...). >> >> [1] >> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >> >> >> Kabir Khan wrote: >>> I've released AOP 2.1.0.CR2 and upgraded AS Branch_5_x to use that >>> On 1 Apr 2009, at 18:38, Jason T. Greene wrote: >>>> Great thanks. >>>> >>>> Kabir Khan wrote: >>>>> It seems the classloader used to deploy the tx, security etc. >>>>> aspects is wrong so it cannot find the base-aspects.xml file >>>>> before running these tests. I'll fix and deploy a new CR. >>>>> On 1 Apr 2009, at 11:13, Kabir Khan wrote: >>>>>> I tested these when I commited, and reverting my local copy to my >>>>>> last commit (revision 86202) the aop tests all work. It must be >>>>>> something commited later. The main problems are anything >>>>>> involving the transaction aspects (ScopedUnitTestCase, >>>>>> ScopedAttachUnitTestCase, TxLockTestCase, TxTestCase, >>>>>> VersionedObjectTestCase) and security aspects >>>>>> (SecurityUnitTestCase). >>>>>> >>>>>> Looking at the changes to thirdparty jars nothing springs out >>>>>> http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/Branch_5_... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 31 Mar 2009, at 12:20, Kabir Khan wrote: >>>>>> >>>>>>> Sure >>>>>>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote: >>>>>>> >>>>>>>> Kabir Khan wrote: >>>>>>>>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched >>>>>>>>> to use the new classpools that understand AS classloading >>>>>>>>> better. If there are no problems I'll do a GA over the next >>>>>>>>> week or so >>>>>>>> >>>>>>>> It looks like a number of AOP tests are now failing after this >>>>>>>> update. Can you look into these? >>>>>>>> >>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jason T. Greene >>>>>>>> JBoss, a division of Red Hat >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> >>>> -- >>>> Jason T. Greene >>>> JBoss, a division of Red Hat >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> >> -- >> Brian Stansberry >> Lead, AS Clustering >> JBoss, a division of Red Hat >> brian.stansberry(a)redhat.com >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development

Last response to myself: Brian Stansberry wrote: > The "addModule" method isn't being called either. Neither callback is > happening; only the call to registerModule made by > JBossClDelegatingClassPoolFactory.create(...) happens. > > Is the VFSDeploymentClassLoaderPolicyModule an MC bean? > No, it's not. It's a DeploymentUnit attachment created by VFSClassLoaderDescribeDeployer. MC is unaware of it, so no install/uninstall callbacks are made.

> Brian Stansberry wrote: >> Hmm, perhaps that's not it then -- at least not directly. A debugger >> shows me that method isn't called. But there's other stuff on that >> report; so perhaps the Module isn't uninstalled properly. I'll keep >> poking tonight. >> >> Kabir Khan wrote: >>> Actually, RegisterModuleCallback.removeModule() should be called by >>> the MC. From bootstrap/aop.xml: >>> <bean name="AOPRegisterModuleCallback" >>> class="org.jboss.aop.asintegration.jboss5.RegisterModuleCallback"> >>> <incallback method="addModule" state="Installed"/> >>> <uncallback method="removeModule" state="Installed"/> >>> </bean> >>> >>> Anyway, I'll have a proper look tomorrow >>> >>> On 1 Apr 2009, at 20:02, Brian Stansberry wrote: >>> >>>> I've been looking into the cause of the classloader leak test >>>> failures[1] and am seeing leaks leading through >>>> org.jboss.aop.asintegration.jboss5.RegisterModuleCallback.registeredModules >>>> >>>> >>>> Looking further into it, I see >>>> RegisterModuleCallback.registerModule(Module) is called, but >>>> nowhere is removeModule(Module) called. The registerModule call is >>>> from JBossClDelegatingClassPoolFactory.create(...). >>>> >>>> [1] >>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>> >>>> >>>> Kabir Khan wrote: >>>>> I've released AOP 2.1.0.CR2 and upgraded AS Branch_5_x to use that >>>>> On 1 Apr 2009, at 18:38, Jason T. Greene wrote: >>>>>> Great thanks. >>>>>> >>>>>> Kabir Khan wrote: >>>>>>> It seems the classloader used to deploy the tx, security etc. >>>>>>> aspects is wrong so it cannot find the base-aspects.xml file >>>>>>> before running these tests. I'll fix and deploy a new CR. >>>>>>> On 1 Apr 2009, at 11:13, Kabir Khan wrote: >>>>>>>> I tested these when I commited, and reverting my local copy to >>>>>>>> my last commit (revision 86202) the aop tests all work. It must >>>>>>>> be something commited later. The main problems are anything >>>>>>>> involving the transaction aspects (ScopedUnitTestCase, >>>>>>>> ScopedAttachUnitTestCase, TxLockTestCase, TxTestCase, >>>>>>>> VersionedObjectTestCase) and security aspects >>>>>>>> (SecurityUnitTestCase). >>>>>>>> >>>>>>>> Looking at the changes to thirdparty jars nothing springs out >>>>>>>> http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/Branch_5_... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 31 Mar 2009, at 12:20, Kabir Khan wrote: >>>>>>>> >>>>>>>>> Sure >>>>>>>>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote: >>>>>>>>> >>>>>>>>>> Kabir Khan wrote: >>>>>>>>>>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and switched >>>>>>>>>>> to use the new classpools that understand AS classloading >>>>>>>>>>> better. If there are no problems I'll do a GA over the next >>>>>>>>>>> week or so >>>>>>>>>> >>>>>>>>>> It looks like a number of AOP tests are now failing after >>>>>>>>>> this update. Can you look into these? >>>>>>>>>> >>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jason T. Greene >>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-development mailing list >>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jboss-development mailing list >>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> JBoss, a division of Red Hat >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> >>>> -- >>>> Brian Stansberry >>>> Lead, AS Clustering >>>> JBoss, a division of Red Hat >>>> brian.stansberry(a)redhat.com >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> > >

I've actually just changed ClassLoading to have a set of ModuleRegistry-ies. - https://jira.jboss.org/jira/browse/JBCL-96 public void addModule(Module module) { if (module == null) throw new IllegalArgumentException("Null module"); String domainName = module.getDeterminedDomainName(); boolean parentFirst = module.isJ2seClassLoadingCompliance(); String parentDomainName = module.getDeterminedParentDomainName(); Domain domain = getDomain(domainName, parentDomainName, parentFirst); domain.addModule(module); Set<ModuleRegistry> added = new HashSet<ModuleRegistry>(); try { for (ModuleRegistry mr : moduleRegistries) { mr.addModule(module); added.add(mr); } } catch (Exception e) { for (ModuleRegistry mr : added) { try { mr.removeModule(module); } catch (Exception ignored) { } } module.release(); throw new IllegalArgumentException("Exception while registering Module.", e); } } public void removeModule(Module module) { if (module == null) throw new IllegalArgumentException("Null module"); for (ModuleRegistry mr : moduleRegistries) { try { mr.removeModule(module); } catch (Exception e) { log.warn("Exception unregistering module, registry: " + mr + ", cause: " + e); } } module.release(); } We also need to add another callback to ClassLoading: <incallback method="addModuleRegistry"/> <uncallback method="removeModuleRegistry"/> Then all you need to do is to implement ModuleRegistry. ;-) Ales Justin wrote: >> Last response to myself: >> >> Brian Stansberry wrote: >>> The "addModule" method isn't being called either. Neither >>> callback is happening; only the call to registerModule made by >>> JBossClDelegatingClassPoolFactory.create(...) happens. >>> >>> Is the VFSDeploymentClassLoaderPolicyModule an MC bean? >>> >> >> No, it's not. It's a DeploymentUnit attachment created by >> VFSClassLoaderDescribeDeployer. MC is unaware of it, so no install/ >> uninstall callbacks are made. > Afaik, the callback mechanism only applies to > <classloader ...> element, which is parsed into 2 BeanMetaData(s). > See VFSClassLoaderFactory in JBoss Classloading. > One of those beans is a VFSClassLoaderPolicyModule, which is > Module's subclass. > This one gets picked up by the ClassLoading (and Kabir) bean's > callback mechanism. > For the deployment's Module, as Brian noted, it doesn't register > against MC. > But it still registers with ClassLoading bean - programmatically in > AbstractClassLoaderDescribeDeployer. > Perhaps a solution would be to have some ModuleRegistry interface > (with add/removeModule methods) + > AbstractClassLoaderDescribeDeployer would keep a record of them via > MR's callback. > e.g. > <bean name="ClassLoaderDescribeDeployer" > class="org.jboss.deployers....AbstractClassLoaderDescribeDeployer"> > <incallback method="addModuleRegistry"/> > <uncallback method="removeModuleRegistry" /> > </bean> > and then instead of just registering newly created deployment's > Module > against ClassLoading (which would implement MR), > we would register it against all MR's, Kabir's being one of those. > // Create the module > ClassLoaderPolicyModule module = createModule(unit, deployment); > if (module != null) > { > // pseudo (need to handle possible exception, > rollingback ...) > for (MR mr : mrs) > mr.addModule(module); > unit.addAttachment(Module.class, module); > } >>> Brian Stansberry wrote: >>>> Hmm, perhaps that's not it then -- at least not directly. A >>>> debugger shows me that method isn't called. But there's other >>>> stuff on that report; so perhaps the Module isn't uninstalled >>>> properly. I'll keep poking tonight. >>>> >>>> Kabir Khan wrote: >>>>> Actually, RegisterModuleCallback.removeModule() should be >>>>> called by the MC. From bootstrap/aop.xml: >>>>> <bean name="AOPRegisterModuleCallback" >>>>> class >>>>> ="org.jboss.aop.asintegration.jboss5.RegisterModuleCallback"> >>>>> <incallback method="addModule" state="Installed"/> >>>>> <uncallback method="removeModule" state="Installed"/> >>>>> </bean> >>>>> >>>>> Anyway, I'll have a proper look tomorrow >>>>> >>>>> On 1 Apr 2009, at 20:02, Brian Stansberry wrote: >>>>> >>>>>> I've been looking into the cause of the classloader leak test >>>>>> failures[1] and am seeing leaks leading through >>>>>> org >>>>>> .jboss >>>>>> .aop >>>>>> .asintegration.jboss5.RegisterModuleCallback.registeredModules >>>>>> >>>>>> Looking further into it, I see >>>>>> RegisterModuleCallback.registerModule(Module) is called, but >>>>>> nowhere is removeModule(Module) called. The registerModule >>>>>> call is from JBossClDelegatingClassPoolFactory.create(...). >>>>>> >>>>>> [1] http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>> >>>>>> Kabir Khan wrote: >>>>>>> I've released AOP 2.1.0.CR2 and upgraded AS Branch_5_x to use >>>>>>> that >>>>>>> On 1 Apr 2009, at 18:38, Jason T. Greene wrote: >>>>>>>> Great thanks. >>>>>>>> >>>>>>>> Kabir Khan wrote: >>>>>>>>> It seems the classloader used to deploy the tx, security >>>>>>>>> etc. aspects is wrong so it cannot find the base- >>>>>>>>> aspects.xml file before running these tests. I'll fix and >>>>>>>>> deploy a new CR. >>>>>>>>> On 1 Apr 2009, at 11:13, Kabir Khan wrote: >>>>>>>>>> I tested these when I commited, and reverting my local >>>>>>>>>> copy to my last commit (revision 86202) the aop tests all >>>>>>>>>> work. It must be something commited later. The main >>>>>>>>>> problems are anything involving the transaction aspects >>>>>>>>>> (ScopedUnitTestCase, ScopedAttachUnitTestCase, >>>>>>>>>> TxLockTestCase, TxTestCase, VersionedObjectTestCase) and >>>>>>>>>> security aspects (SecurityUnitTestCase). >>>>>>>>>> >>>>>>>>>> Looking at the changes to thirdparty jars nothing springs >>>>>>>>>> out >>>>>>>>>> http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/ >>>>>>>>>> branches/Branch_5_x/component-matrix/pom.xml? >>>>>>>>>> r1=86546&r2=86201 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 31 Mar 2009, at 12:20, Kabir Khan wrote: >>>>>>>>>> >>>>>>>>>>> Sure >>>>>>>>>>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote: >>>>>>>>>>> >>>>>>>>>>>> Kabir Khan wrote: >>>>>>>>>>>>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and >>>>>>>>>>>>> switched to use the new classpools that understand AS >>>>>>>>>>>>> classloading better. If there are no problems I'll do a >>>>>>>>>>>>> GA over the next week or so >>>>>>>>>>>> >>>>>>>>>>>> It looks like a number of AOP tests are now failing >>>>>>>>>>>> after this update. Can you look into these? >>>>>>>>>>>> >>>>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Jason T. Greene >>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jboss-development mailing list >>>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> jboss-development mailing list >>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jason T. Greene >>>>>>>> JBoss, a division of Red Hat >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>>> >>>>>> -- >>>>>> Brian Stansberry >>>>>> Lead, AS Clustering >>>>>> JBoss, a division of Red Hat >>>>>> brian.stansberry(a)redhat.com >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> >>> >>> >> >> _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Kabir Khan wrote: > I've worked around this while waiting for a release and fixed > another leak. AopPreparedClassesClassloaderLeakUnitTestCase passes > now, but ClassloaderLeakUnitTestCase, > CommonsLoggingClassloaderLeakUnitTestCase and > Ejb3ClassloaderLeakUnitTestCase time out. Is there a way to make > the timeout longer? Or does a timeout normally mean it is doing > lots of extra stuff because the test is failing due to leaks? It normally means the latter (gc ends up in a loop because nothing is free) -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Please ignore, increasing the report depth shows some references from aop On 6 Apr 2009, at 11:17, Kabir Khan wrote: > Here is the jboss-profiler leak report for > ClassloaderLeakUnitTestCase and > CommonsLoggingClassloaderLeakUnitTestCase against my local fixed > checkout. It doesn't look like AOP classes appear anywhere any > more, but I am not sure if that is what I should be looking for. > Brian/Jesper, from what I hear you are good at parsing this stuff :-) > > <Leaks.txt> > > > On 3 Apr 2009, at 21:36, Jason T. Greene wrote: > >> Kabir Khan wrote: >>> I've worked around this while waiting for a release and fixed >>> another leak. AopPreparedClassesClassloaderLeakUnitTestCase >>> passes now, but ClassloaderLeakUnitTestCase, >>> CommonsLoggingClassloaderLeakUnitTestCase and >>> Ejb3ClassloaderLeakUnitTestCase time out. Is there a way to make >>> the timeout longer? Or does a timeout normally mean it is doing >>> lots of extra stuff because the test is failing due to leaks? >> >> It normally means the latter (gc ends up in a loop because nothing >> is free) >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

I've worked around this while waiting for a release and fixed another leak. AopPreparedClassesClassloaderLeakUnitTestCase passes now, but ClassloaderLeakUnitTestCase, CommonsLoggingClassloaderLeakUnitTestCase and Ejb3ClassloaderLeakUnitTestCase time out. Is there a way to make the timeout longer? Or does a timeout normally mean it is doing lots of extra stuff because the test is failing due to leaks? On 2 Apr 2009, at 11:44, Ales Justin wrote: > I've actually just changed ClassLoading > to have a set of ModuleRegistry-ies. > - https://jira.jboss.org/jira/browse/JBCL-96 > > > public void addModule(Module module) > { > if (module == null) > throw new IllegalArgumentException("Null module"); > > String domainName = module.getDeterminedDomainName(); > boolean parentFirst = module.isJ2seClassLoadingCompliance(); > String parentDomainName = module.getDeterminedParentDomainName(); > Domain domain = getDomain(domainName, parentDomainName, > parentFirst); > domain.addModule(module); > > Set<ModuleRegistry> added = new HashSet<ModuleRegistry>(); > try > { > for (ModuleRegistry mr : moduleRegistries) > { > mr.addModule(module); > added.add(mr); > } > } > catch (Exception e) > { > for (ModuleRegistry mr : added) > { > try > { > mr.removeModule(module); > } > catch (Exception ignored) > { > } > } > module.release(); > > throw new IllegalArgumentException("Exception while > registering Module.", e); > } > } > > public void removeModule(Module module) > { > if (module == null) > throw new IllegalArgumentException("Null module"); > > for (ModuleRegistry mr : moduleRegistries) > { > try > { > mr.removeModule(module); > } > catch (Exception e) > { > log.warn("Exception unregistering module, registry: " + mr > + ", cause: " + e); > } > } > > module.release(); > } > > We also need to add another callback to ClassLoading: > > <incallback method="addModuleRegistry"/> > <uncallback method="removeModuleRegistry"/> > > > Then all you need to do is to implement ModuleRegistry. ;-) > > Ales Justin wrote: >>> Last response to myself: >>> >>> Brian Stansberry wrote: >>>> The "addModule" method isn't being called either. Neither callback >>>> is happening; only the call to registerModule made by >>>> JBossClDelegatingClassPoolFactory.create(...) happens. >>>> >>>> Is the VFSDeploymentClassLoaderPolicyModule an MC bean? >>>> >>> >>> No, it's not. It's a DeploymentUnit attachment created by >>> VFSClassLoaderDescribeDeployer. MC is unaware of it, so no >>> install/uninstall callbacks are made. >> Afaik, the callback mechanism only applies to >> <classloader ...> element, which is parsed into 2 BeanMetaData(s). >> See VFSClassLoaderFactory in JBoss Classloading. >> One of those beans is a VFSClassLoaderPolicyModule, which is Module's >> subclass. >> This one gets picked up by the ClassLoading (and Kabir) bean's >> callback mechanism. >> For the deployment's Module, as Brian noted, it doesn't register >> against MC. >> But it still registers with ClassLoading bean - programmatically in >> AbstractClassLoaderDescribeDeployer. >> Perhaps a solution would be to have some ModuleRegistry interface >> (with add/removeModule methods) + AbstractClassLoaderDescribeDeployer >> would keep a record of them via MR's callback. >> e.g. >> <bean name="ClassLoaderDescribeDeployer" >> class="org.jboss.deployers....AbstractClassLoaderDescribeDeployer"> >> <incallback method="addModuleRegistry"/> >> <uncallback method="removeModuleRegistry" /> >> </bean> >> and then instead of just registering newly created deployment's Module >> against ClassLoading (which would implement MR), >> we would register it against all MR's, Kabir's being one of those. >> // Create the module >> ClassLoaderPolicyModule module = createModule(unit, deployment); >> if (module != null) >> { >> // pseudo (need to handle possible exception, rollingback ...) >> for (MR mr : mrs) >> mr.addModule(module); >> unit.addAttachment(Module.class, module); >> } >>>> Brian Stansberry wrote: >>>>> Hmm, perhaps that's not it then -- at least not directly. A >>>>> debugger shows me that method isn't called. But there's other >>>>> stuff on that report; so perhaps the Module isn't uninstalled >>>>> properly. I'll keep poking tonight. >>>>> >>>>> Kabir Khan wrote: >>>>>> Actually, RegisterModuleCallback.removeModule() should be called >>>>>> by the MC. From bootstrap/aop.xml: >>>>>> <bean name="AOPRegisterModuleCallback" >>>>>> class="org.jboss.aop.asintegration.jboss5.RegisterModuleCallback"> >>>>>> <incallback method="addModule" state="Installed"/> >>>>>> <uncallback method="removeModule" state="Installed"/> >>>>>> </bean> >>>>>> >>>>>> Anyway, I'll have a proper look tomorrow >>>>>> >>>>>> On 1 Apr 2009, at 20:02, Brian Stansberry wrote: >>>>>> >>>>>>> I've been looking into the cause of the classloader leak test >>>>>>> failures[1] and am seeing leaks leading through >>>>>>> org.jboss.aop.asintegration.jboss5.RegisterModuleCallback.registeredModules >>>>>>> >>>>>>> >>>>>>> Looking further into it, I see >>>>>>> RegisterModuleCallback.registerModule(Module) is called, but >>>>>>> nowhere is removeModule(Module) called. The registerModule call >>>>>>> is from JBossClDelegatingClassPoolFactory.create(...). >>>>>>> >>>>>>> [1] >>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>>> >>>>>>> >>>>>>> Kabir Khan wrote: >>>>>>>> I've released AOP 2.1.0.CR2 and upgraded AS Branch_5_x to use that >>>>>>>> On 1 Apr 2009, at 18:38, Jason T. Greene wrote: >>>>>>>>> Great thanks. >>>>>>>>> >>>>>>>>> Kabir Khan wrote: >>>>>>>>>> It seems the classloader used to deploy the tx, security etc. >>>>>>>>>> aspects is wrong so it cannot find the base-aspects.xml file >>>>>>>>>> before running these tests. I'll fix and deploy a new CR. >>>>>>>>>> On 1 Apr 2009, at 11:13, Kabir Khan wrote: >>>>>>>>>>> I tested these when I commited, and reverting my local copy >>>>>>>>>>> to my last commit (revision 86202) the aop tests all work. >>>>>>>>>>> It must be something commited later. The main problems are >>>>>>>>>>> anything involving the transaction aspects >>>>>>>>>>> (ScopedUnitTestCase, ScopedAttachUnitTestCase, >>>>>>>>>>> TxLockTestCase, TxTestCase, VersionedObjectTestCase) and >>>>>>>>>>> security aspects (SecurityUnitTestCase). >>>>>>>>>>> >>>>>>>>>>> Looking at the changes to thirdparty jars nothing springs out >>>>>>>>>>> http://fisheye.jboss.com/browse/~br=Branch_5_x/JBossAS/branches/Branch_5_... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 31 Mar 2009, at 12:20, Kabir Khan wrote: >>>>>>>>>>> >>>>>>>>>>>> Sure >>>>>>>>>>>> On 30 Mar 2009, at 21:30, Jason T. Greene wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Kabir Khan wrote: >>>>>>>>>>>>>> I have upgraded Branch_5_x to use AOP 2.1.0.CR1 and >>>>>>>>>>>>>> switched to use the new classpools that understand AS >>>>>>>>>>>>>> classloading better. If there are no problems I'll do a >>>>>>>>>>>>>> GA over the next week or so >>>>>>>>>>>>> >>>>>>>>>>>>> It looks like a number of AOP tests are now failing after >>>>>>>>>>>>> this update. Can you look into these? >>>>>>>>>>>>> >>>>>>>>>>>>> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.1.x-test... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Jason T. Greene >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jboss-development mailing list >>>>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jboss-development mailing list >>>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jason T. Greene >>>>>>>>> JBoss, a division of Red Hat >>>>>>>> _______________________________________________ >>>>>>>> jboss-development mailing list >>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Lead, AS Clustering >>>>>>> JBoss, a division of Red Hat >>>>>>> brian.stansberry(a)redhat.com >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>>> >>>> >>>> >>> >>> > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development