Author: kkolinko
Date: Tue Mar 2 08:05:40 2010
New Revision: 917907
URL: http://svn.apache.org/viewvc?rev=917907&view=rev
Log:
Amend the documentation
Modified:
tomcat/trunk/webapps/docs/html-manager-howto.xml
tomcat/trunk/webapps/docs/manager-howto.xml
Modified: tomcat/trunk/webapps/docs/html-manager-howto.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/html-manager-howto.xml?rev=917907&r1=917906&r2=917907&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/html-manager-howto.xml (original)
+++ tomcat/trunk/webapps/docs/html-manager-howto.xml Tue Mar 2 08:05:40 2010
@@ -549,21 +549,30 @@
<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">
Modified: tomcat/trunk/webapps/docs/manager-howto.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/manager-howto.xml?rev=917907&r1=917906&r2=917907&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/manager-howto.xml (original)
+++ tomcat/trunk/webapps/docs/manager-howto.xml Tue Mar 2 08:05:40 2010
@@ -903,12 +903,13 @@
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 @@
/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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
