[Deployers on JBoss (Deployers/JBoss)] - Re: Ordering of .ear subdeployments
by bstansberry@jboss.com
I think with the latest change if an ear doesn't have a jboss-app.xml, deployment will fail with an NPE at EARDeployer line 275. This is causing o.j.t.cluster.test.CrossContextCallsTestCase to fail.
I'd have just fixed this by changing 'if (moduleOrder.equals("strict"))' to 'if ("strict".equals(moduleOrder))' but I saw that in the else block it's logging a warning. My recommendation would be to get rid of the warning (or log it at a lower level) and use the "strict".equals(...) syntax. With this WARN log, anyone who upgrades to 4.0.5 and doesn't add this new config element will get a WARN log. A WARN in a production app is a serious problem; to make it go away the users will have to add the new element. If they are going to have to add the element there is no point having a default.
Actually, "strict".equalsIgnoreCase(moduleOrder) would be better.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967666#3967666
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967666
18 years, 2 months
[Design of JBoss Profiler] - Redeployment Class Leak in commons logging ?
by deas0815
Hallo everybody,
even though my story is not directly related to jboss-profiler, I'm
posting it here as I hope experienced memory-leak tacklers are
around. :)
I'm running jboss-4.0.4 on jdk 1.5 with ejb3 clustering enabled. I
have an isolated (ear) application coming with the hibernate 3.2.0cr3
and most of the libraries hibernate depends upon bundled in order to
avoid class leakage caused by static references from classes not
bundled with the application.
Unfortunately, I found that I'm still "suffering" from a redeployment
memory leak in the permanent generation, so I tried to locate the
cause using several memory profilers (jboss-profiler was among them
:). In the end, the "picture" provided by the profiler coming with jdk
6 (jhat) provided the clearest picture (to me) so far. It showed that
there where two WeakHashMaps left refencing the ears UCL.
The first one looks jvm internal and hence ok to me:
Static reference from com.sun.naming.internal.ResourceManager.propertiesCache (from class com.sun.naming.internal.ResourceManager) :
--> java.util.WeakHashMap@0x96c95258 (44 bytes) (field table:)
--> [Ljava.util.WeakHashMap$Entry;@0x97a8dea8 (264 bytes) (Element 45 of [Ljava.util.WeakHashMap$Entry;@0x97a8dea8:)
--> java.util.WeakHashMap$Entry@0x980e20d8 (36 bytes) (field referent:)
--> org.jboss.mx.loading.UnifiedClassLoader3@0x97f1d7e8 (107 bytes)
The second one held by org.apache.commons.logging.LogFactory seems suspicious:
Static reference from org.jboss.resource.connectionmanager.PoolFiller.filler (from class org.jboss.resource.connectionmanager.PoolFiller) :
--> org.jboss.resource.connectionmanager.PoolFiller@0x97876fb8 (16 bytes) (field fillerThread:)
--> java.lang.Thread@0x97876f30 (104 bytes) (field contextClassLoader:)
--> org.jboss.mx.loading.UnifiedClassLoader3@0x966708c0 (107 bytes) (field classes:)
--> java.util.Vector@0x96690400 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x97e3b2a0 (10248 bytes) (Element 166 of [Ljava.lang.Object;@0x97e3b2a0:)
--> class org.apache.commons.logging.LogFactory (84 bytes) (static field factories:)
--> java.util.Collections$SynchronizedMap@0x96a6e8c0 (28 bytes) (field m:)
--> java.util.WeakHashMap@0x96b4e458 (44 bytes) (field table:)
--> [Ljava.util.WeakHashMap$Entry;@0x96b68330 (72 bytes) (Element 13 of [Ljava.util.WeakHashMap$Entry;@0x96b68330:)
--> java.util.WeakHashMap$Entry@0x97f6b358 (36 bytes) (field referent:)
--> org.jboss.mx.loading.UnifiedClassLoader3@0x97f1d7e8 (107 bytes)
I don't know how and when LogFactory is supposed to release the UCL,
but it does not seem to happen for me. Looking at the jboss source, I
found a call to LogFactory.release(...) in WebCtXLoader - and nowhere
else.
Are we missing this call somewhere else and am I suffering from a bug
related to commons logging ?
regards
Andreas
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3967625#3967625
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967625
18 years, 2 months