0 Replies Latest reply on Oct 15, 2015 7:29 PM by cmhdave3266

    Question about static Logger in OSGI


      All, we've been running into this issue where every time we deploy our code to an AEM instance (5.6.1) the PermGen space increases which I can monitor by attaching VisualVM. Now there are some good resources available by Frank Kievet about this so I've been reading through this blog post: http://frankkieviet.blogspot.ca/2006/10/how-to-fix-dreaded-permgen-space.html[1]

      To try this I follow these steps

      1. Deploy code to AEM
      2. Log into Felix console and stop our code bundle
      3. Run jmap -dump:format=b,file=leak <pid> from the console
      4. Run jhat -J-Xmx1024m leak
      5. Open the browser to http://localhost:7000
      6. Search for any instance of any of our classes (which shouldn't appear if I'm understanding this correctly since we've stopped the bundle)

      I can do this and find 103 classes still loaded in the heap after the bundle has been stopped. The large majority of these are static references to a logger.

      Here would be an example:

      Static reference from org.company.cq.servlets.DataServlet.log (from class org.company.cq.servlets.DataServlet) : --> org.apache.sling.commons.log.internal.slf4j.SlingLogger@0x7bd99b160 (32 bytes) (??:) --> class org.apache.sling.commons.log.internal.slf4j.SlingLogger (160 bytes) (??:) --> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5@0x7b89b1ba8 (147 bytes) (field m_wiring:) --> org.apache.felix.framework.BundleWiringImpl@0x7b8aa0c88 (171 bytes) (field m_resolver:) --> org.apache.felix.framework.StatefulResolver@0x7b814a3d8 (97 bytes) (field m_revisions:) --> java.util.HashSet@0x7b8183ca8 (24 bytes) (field map:) --> java.util.HashMap@0x7b8167ec0 (64 bytes) (field table:) --> [Ljava.util.HashMap$Entry;@0x7b89b5178 (4112 bytes) (Element 74 of [Ljava.util.HashMap$Entry;@0x7b89b5178:) --> java.util.HashMap$Entry@0x7bd81c800 (44 bytes) (field key:) --> org.apache.felix.framework.BundleRevisionImpl@0x7b88d0da0 (142 bytes) (field m_wiring:) --> org.apache.felix.framework.BundleWiringImpl@0x7bd828730 (171 bytes) (field m_classLoader:) --> org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5@0x7bd75ca10 (147 bytes)

      So it's somehow holding on to the classloader through SlingLogger. My question is, how do we eliminate this problem?