You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by kk...@apache.org on 2010/03/02 09:10:37 UTC

svn commit: r917909 - in /tomcat/tc6.0.x/trunk/webapps/docs: html-manager-howto.xml manager-howto.xml

Author: kkolinko
Date: Tue Mar  2 08:10:37 2010
New Revision: 917909

URL: http://svn.apache.org/viewvc?rev=917909&view=rev
Log:
Amend the documentation

Modified:
    tomcat/tc6.0.x/trunk/webapps/docs/html-manager-howto.xml
    tomcat/tc6.0.x/trunk/webapps/docs/manager-howto.xml

Modified: tomcat/tc6.0.x/trunk/webapps/docs/html-manager-howto.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/html-manager-howto.xml?rev=917909&r1=917908&r2=917909&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/html-manager-howto.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/html-manager-howto.xml Tue Mar  2 08:10:37 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>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/tc6.0.x/trunk/webapps/docs/manager-howto.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/manager-howto.xml?rev=917909&r1=917908&r2=917909&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/manager-howto.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/manager-howto.xml Tue Mar  2 08:10:37 2010
@@ -909,7 +909,8 @@
 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>
@@ -925,8 +926,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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org