tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kkoli...@apache.org
Subject svn commit: r917907 - in /tomcat/trunk/webapps/docs: html-manager-howto.xml manager-howto.xml
Date Tue, 02 Mar 2010 08:05:40 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message