Amend the documentation

git-svn-id: https://svn.apache.org/repos/asf/tomcat/trunk@917907 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/webapps/docs/html-manager-howto.xml b/webapps/docs/html-manager-howto.xml
index 6d27cc8..d5853f1 100644 (file)
--- 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:</p>
 
 <section name="Diagnostics">
 
+<subsection name="Finding memory leaks">
+
 <p><strong>The find leaks diagnostic triggers a full garbage collection. It
 should be used with extreme caution on production systems.</strong></p>
 
 <p>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.</p>
 
-<p>Explicitly triggering a full garbage collection from Java Code is documented
+<p>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.</p>
+
+<p>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 <code>-XX:+DisableExplicitGC</code>.
 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.</p>
 
+</subsection>
 </section>
 
 <section name="Server Information">

diff --git a/webapps/docs/manager-howto.xml b/webapps/docs/manager-howto.xml
index 344342c..a455ec7 100644 (file)
--- 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.</strong></p>
 
 <p>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.</p>
 
-<p>Explicitly triggering a full garbage collection from Java Code is documented
+<p>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 <code>-XX:+DisableExplicitGC</code>.
 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.</p>
 /leaking-webapp
 </source>
 
-<p>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
+<p>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.</p>
 
 <p>If the command does not succeed, the response will start with