6:16 a.m.
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:
3:30 p.m.
New subject: AOP 2.1.0 in AS 5?
Kabir Khan wrote:
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
5:13 a.m.
New subject: AOP 2.1.0 in AS 5?
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:
2:02 p.m.
New subject: AOP 2.1.0 in AS 5?
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:
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
3:55 p.m.
New subject: AOP 2.1.0 in AS 5?
I've attached the report I got from a failure of the
ClassloaderLeakUnitTestCase.testSimpleWeb() method.
Not sure about OS X. Clebert? I know if you build JBoss Profiler in the
jvmti-lib dir there is a macos dir. But how well it works I can't say.
http://www.jboss.org/community/docs/DOC-9294 has details on how to set
things up to get a report like the attached. Unfortunately it's a bit of
a black art.
Kabir Khan wrote:
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5 p.m.
New subject: AOP 2.1.0 in AS 5?
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:
5:53 p.m.
New subject: AOP 2.1.0 in AS 5?
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:
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
7:43 p.m.
New subject: AOP 2.1.0 in AS 5?
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?
Brian Stansberry wrote:
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
9:21 p.m.
New subject: AOP 2.1.0 in AS 5?
Last response to myself:
Brian Stansberry wrote:
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
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
3:09 a.m.
New subject: AOP 2.1.0 in AS 5?
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);
}
5:44 a.m.
New subject: AOP 2.1.0 in AS 5?
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:
12:30 p.m.
New subject: AOP 2.1.0 in AS 5?
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:
5:17 a.m.
New subject: AOP 2.1.0 in AS 5?
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 :-)
On 3 Apr 2009, at 21:36, Jason T. Greene wrote:
9:08 a.m.
New subject: AOP 2.1.0 in AS 5?
I have released AOP 2.1.0.CR 3 which fixes the classloader leak tests.
It also contains the fixes for the tx and security aop tests that were
in the rolled back AOP 2.1.0.CR2 upgrade. Locally, the aop, leak and
smoke tests work.
On 6 Apr 2009, at 16:35, Kabir Khan wrote:
8:50 a.m.
New subject: AOP 2.1.0 in AS 5?
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:
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5836
days inactive
5851
days old
jboss-development@lists.jboss.org
23 comments
4 participants
participants (4)
-
Ales Justin -
Brian Stansberry -
Jason T. Greene -
Kabir Khan