froehlich 02/03/17 05:44:52
Modified: src/documentation/xdocs/userdocs/concepts storejanitor.xml
Log:
more doc update
Revision Changes Path
1.4 +21 -23
xml-cocoon2/src/documentation/xdocs/userdocs/concepts/storejanitor.xml
Index: storejanitor.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/storejanitor.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- storejanitor.xml 5 Feb 2002 01:46:44 -0000 1.3
+++ storejanitor.xml 17 Mar 2002 13:44:52 -0000 1.4
@@ -11,20 +11,13 @@
<abstract>This document describes the usage of the StoreJanitor under
Cocoon.</abstract>
</header>
<body>
- <s1 title="Goal"><p>This document describes the usage of the StoreJanitor under
Apache Cocoon.</p></s1>
- <s1 title="Overview">
- <p>In the current design of Apache Cocoon there can be different stores for the
different pipelines.
- For example you can choose a weaker store for the event pipelines (weaker=caches
- not many objects) and a "big" store for the stream pipelines. If you know which
ones are more
- "cacheable", you can fine-tune your stores. This decision was made, because of
the two pipeline objects.
- You can combine a non-caching-stream-pipeline with a caching-event-pipeline
etc.</p>
- </s1>
- <s1 title="Implementation">
+ <s1 title="Goal"><p>This document describes the usage of the StoreJanitor under
+ Apache Cocoon.</p></s1>
+ <s1 title="Description">
<p>The implementation is quit simple! Every implementation of a Store can
register in the
StoreJanitor. He checks in a configurable interval if memory is running low. If
low,
- then the StoreJanitor first runs the GC. If Memory is still low, he greps via
Round Robin
- a victim (Store) and frees xx% of all emlements in this Store. After that the
StoreJanitor
- sleeps and waits for the next iteration.</p>
+ he greps via Round Robin a victim (Store) and frees xx% of all emlements in this
Store.
+ After that the StoreJanitor sleeps and waits for the next iteration.</p>
</s1>
<s1 title="Configuration">
<source><![CDATA[
@@ -42,11 +35,11 @@
<s2 title="Example configuration">
<ul><li>Tomcat settings in tomcat.sh or tomcat.bat:</li></ul>
<source><![CDATA[
-%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" -Xms100000000 \
+%_RUNJAVA% %TOMCAT_OPTS% -Dtomcat.home="%TOMCAT_HOME%" \
-Xmx200000000 org.apache.tomcat.startup.Tomcat %2 %3 %4 %5 %6 %7 %8 %9
]]></source>
<ul><li>StoreJanitor settings:</li></ul>
- <p>The freememory and heapsize paramter always depends on the Xms and Xmx
+ <p>The freememory and heapsize paramter always depends on the Xmx
parameter.</p>
<source><![CDATA[
<store-janitor
@@ -59,15 +52,20 @@
<parameter name="percent_to_free" value="10"/>
</store-janitor>
]]></source>
- <p>The <code>heapsize</code> _must_ be higher then the -Xms parameter and
<code>freememory</code> _between_ those both. If you set
- the <code>heapsize</code> lower then the -Xms parameter and
<code>freememory</code> very thin, then the cleanupthread
- will work all the time and cause a high system load. If you set the
<code>heapsize</code> to close to the
- Xmx paramter and <code>freememory</code> to broad can cause a
OutOfMemoryException. Somewhere in the middle
- is always the best.</p>
- <p> The <code>cleanupthreadinterval</code> defines the interval of the
background thread which
- checks memory in seconds. Also this paramter should configured wisely. A to
short interval can
- cause also a high system load. The <code>threadpriority</code> defines the
priority of the
- background thread. 1 is lowest level and 10 the highest.</p>
+ <p>It is recommended to have <code>heapsize</code> equal to -Xmx, especially
+ on Sun's JVM which are unable to shrink its heap once it grows above minimum.
+ <code>freememory</code> should be greater than amount of memory necessary for
normal
+ application operation.
+ </p>
+ <p> The <code>cleanupthreadinterval</code> defines the interval of the
background
+ thread which checks memory in seconds. Also this paramter should configured
wisely.
+ A to short interval can cause also a high system load. The
+ <code>threadpriority</code> defines the priority of the background thread.
+ 1 is lowest level and 10 the highest.</p>
+ <p>
+ The <code>percent_to_free</code> parameter describes, how much percent of the
+ elements of each registered Store shall be removed when low on memory.
+ </p>
</s2>
</s1>
</body>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
