On 31.07.2011 01:10, Brian Braun wrote: > Hi, > > I'm using Tomcat 7.0.11. I have noticed that after a reload of an app, the > "Find Leaks" button sometimes declares that there is a leak. But after a few > minutes (without restarting/stopping/reloading the app) it says that there > are no leaks. > > I guess the reason is that some objects are refering to the class loader and > avoiding it to be garbage collected when we press the "Find leaks" button > the first time, so it finds the leak. Then, somehow, those objects that > retain the class loader dissappear or stop reffering to it, so then the > class loader is collected by the GC. So then when I press the button, it > says no leaks.
The documentation states: The find leaks diagnostic triggers a full garbage collection. It should be used with extreme caution on production systems. The find leaks diagnostic attempts to identify web applications that have caused memory leaks when they were stopped, reloaded or undeployed. Results should always be confirmed with a profiler. The diagnostic uses additional functionality provided by the StandardHost implementation. It will not work if a custom host is used that does not extend StandardHost. This diagnostic will list context paths for the web applications that were stopped, reloaded or undeployed, but which classes from the previous runs are still present in memory, thus being a memory leak. If an application has been reloaded several times, it may be listed several times. Explicitly triggering a full garbage collection from Java code is documented to be unreliable. Furthermore, depending on the JVM used, there are options to disable explicit GC triggering, like -XX:+DisableExplicitGC. If you want to make sure, that the diagnostics were successfully running a full GC, you will need to check using tools like GC logging, JConsole or similar. So: did you check, whether a MajorGC had run after you pressed the button? Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org