0 Replies Latest reply on Aug 26, 2006 5:30 AM by deas0815

    Redeployment Class Leak in commons logging ?

      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