Mark BLUF: Thanks for your explanations and assistance. I plan to follow up with the Log4J2 group. My simple responses below.
-----Original Message----- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, July 21, 2016 3:47 PM To: Tomcat Users List Subject: Re: OutOfMemoryError: PermGen space > On 21/07/2016 18:17, Berneburg, Cris wrote: > > From: Mark Thomas [mailto:ma...@apache.org] > > <snip/> > > > > > Used the Java Visual VM to pull a heap dump after the app > > restart and GC. Used Eclipse Memory Analyzer to analyze > > the heap dumps. Found the WebappClassLoader with started > > == false and used Path to GC roots: > > > > <classloader> org.apache.logging.log4j.core.jmx.LoggerContextAdminMBean ... > > com.sun.jmx.mbeanserver.StandardMBeanIntrospector > > > > <classloader> org.apache.logging.log4j.core.jmx.LoggerContextAdmin ... > > com.sun.jmx.mbeanserver.StandardMBeanIntrospector > > > > <classloader> org.apache.logging.log4j.core.jmx.StatusLoggerAdmin ... > > com.sun.jmx.mbeanserver.StandardMBeanIntrospector > > The three above look problematic. > > > referent java.util.WeakHashMap$Entry ... java.lang.reflect.Proxy > > That should disappear once the problematic entries have been fixed > > > <classloader> $Proxy3 ... java.lang.reflect.Proxy > > That looks to be related to the previous GC root and should also > disappear once the problematic entries are fixed. > > > referent java.util.WeakHashMap$Entry ... > > org.apache.juli.ClassLoaderLogManager > > ... (many java.util.logging.*) > > Again, those will disappear once the issues are fixed. They are Tomcat's > internal logging Thanks for explaining those to me. > > I don't see anything pointing back to our code. With > > no previous experience with heap analysis on my part, > > it looks to me to be due to Log4J2. > > Agreed. Great! > > Changing the args for the call to LogManager.getLogger from > Class<T> clazz to none made no appreciable difference. > > I wouldn't expect that to make any difference. > > > (Did I somehow set up Log4J2 incorrectly to get it to misbehave?) > > I don't think so. I wanted to make sure that holding onto class references wasn't a problem. Later I even replaced all the static vars with non-static locals as an experiment just in case ;-) and it made no diff. Yeah, I know, you previously said that removing a static would not help, but I had to try anyway because I don't fully understand it all. If there's a chance I did something goofy to cause the issue, I want to eliminate that possibility. > > Not sure what else I can do. Report it to the Log4J2 dev group perhaps? > > Ask on their users' list. It may be that when you use log4j2 in a webapp > there is some clean-up method you need to call from a > ServletContextListener. OK, I'll do that next after following up with the other folks in this group. > >> One thing worth noting. Yourkit offers two types of heap dumps. > >> You don't want YourKit's own. There is a JVM bug that prevents > >> some GC roots from being shown in that format and if your leak > >> traces back to one of those you can end up scratching your head > >> for days. > >> > >> Mark > > > > > > Is there a likely chance that the bug interfered with my usage of > > Java Visual VM and Eclipse Memory Analyzer and thus prevented me > > from determining the real problem source? > > No. The bug just hides GC roots. If the only GC roots you see are for > weak references then you might have hit this bug. Ah good, that's a relief and good to know. Thanks! -- Cris Berneburg CACI Lead Software Engineer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
