From d907dfe5f85c2d5bb8468ec3c259467a68a7621b Mon Sep 17 00:00:00 2001 From: kkolinko Date: Tue, 2 Mar 2010 08:05:40 +0000 Subject: [PATCH] Amend the documentation git-svn-id: https://svn.apache.org/repos/asf/tomcat/trunk@917907 13f79535-47bb-0310-9956-ffa450edef68 --- webapps/docs/html-manager-howto.xml | 13 +++++++++++-- webapps/docs/manager-howto.xml | 10 ++++++---- 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/webapps/docs/html-manager-howto.xml b/webapps/docs/html-manager-howto.xml index 6d27cc894..d5853f118 100644 --- a/webapps/docs/html-manager-howto.xml +++ b/webapps/docs/html-manager-howto.xml @@ -549,21 +549,30 @@ error message. Possible causes for problems include:

+ +

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 reloaded. Results should always be confirmed +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.

-

Explicitly triggering a full garbage collection from Java Code is documented +

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.

+
diff --git a/webapps/docs/manager-howto.xml b/webapps/docs/manager-howto.xml index 344342c77..a455ec722 100644 --- a/webapps/docs/manager-howto.xml +++ b/webapps/docs/manager-howto.xml @@ -903,12 +903,13 @@ http://localhost:8080/manager/text/findleaks 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 reloaded. Results should always be confirmed +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.

-

Explicitly triggering a full garbage collection from Java Code is documented +

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, @@ -919,8 +920,9 @@ you will need to check using tools like GC logging, JConsole or similar.

/leaking-webapp -

Each context path for a web application that is believed to have triggered a -memory leak when it was reloaded will be listed on a new line. If an application +

Each context path for a web application that was stopped, reloaded or +undeployed, but which classes from the previous runs are still loaded in memory, +thus causing a memory leak, will be listed on a new line. If an application has been reloaded several times, it may be listed several times.

If the command does not succeed, the response will start with -- 2.11.0