Tomcat 7.0.11: "Find Leaks" Button says there is a leak... then after a few minutes, it says the opposite (without any restarts in between)!

[Brian Braun <br...@gmail.com>]

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.

Question: Does it mean that it is not reliable to press the button
immediately after the app restart, and that I should wait for a while before
doing it?

Re: Tomcat 7.0.11: "Find Leaks" Button says there is a leak... then after a few minutes, it says the opposite (without any restarts in between)!

[Rainer Jung <ra...@kippdata.de>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org