[jboss-dev] Re: AOP 2.1.0 in AS 5?
Brian Stansberry
brian.stansberry at redhat.com
Mon Apr 6 09:50:27 EDT 2009
A timeout is a sign of failure. Normally a fairly fundamental failure
that effects both servlets and remote requests to EJB2 session beans,
since what happens is multiple test methods fail and eventually the
overall test fails.
Let me look at breaking the test classes up into multiple classes.
If you send me a jar(s) with your latest stuff I'd be happy to run the
test with JBoss Profiler enabled and see what it shows.
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?
>
> 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
>
> _______________________________________________
> 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
More information about the jboss-development
mailing list