[jboss-dev] Re: AOP 2.1.0 in AS 5?
Kabir Khan
kabir.khan at jboss.com
Fri Apr 3 13:30:55 EDT 2009
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-testSuite-sun15/169/testReport/org.jboss.test.classloader.leak.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-testSuite-sun15/lastBuild/testReport/
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jason T. Greene
>>>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> jboss-development mailing list
>>>>>>>>>>>> jboss-development at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> jboss-development mailing list
>>>>>>>>>>> jboss-development at 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 at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Lead, AS Clustering
>>>>>>> JBoss, a division of Red Hat
>>>>>>> brian.stansberry at redhat.com
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
More information about the jboss-development
mailing list