Return-Path: 
 <cocoon-cvs-return-5139-apmail-xml-cocoon-cvs-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-cvs-archive@xml.apache.org
Received: (qmail 80183 invoked by uid 500); 29 Jan 2002 20:02:08 -0000
Mailing-List: contact cocoon-cvs-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
list-help: <mailto:cocoon-cvs-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-cvs-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-cvs@xml.apache.org>
Delivered-To: mailing list cocoon-cvs@xml.apache.org
Received: (qmail 80174 invoked by uid 500); 29 Jan 2002 20:02:08 -0000
Delivered-To: apmail-xml-cocoon2-cvs@apache.org
Date: 29 Jan 2002 20:02:07 -0000
Message-ID: <20020129200207.85281.qmail@icarus.apache.org>
From: froehlich@apache.org
To: xml-cocoon2-cvs@apache.org
Subject: cvs commit: xml-cocoon2/src/documentation/xdocs/userdocs/concepts
 storejanitor.xml
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

froehlich    02/01/29 12:02:07

  Modified:    src/documentation/xdocs/userdocs/concepts storejanitor.xml
  Log:
  reflect changes
  
  Revision  Changes    Path
  1.2       +7 -5      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.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- storejanitor.xml	3 Jan 2002 12:31:04 -0000	1.1
  +++ storejanitor.xml	29 Jan 2002 20:02:07 -0000	1.2
  @@ -20,11 +20,11 @@
     You can combine a non-caching-stream-pipeline with a caching-event-pipeline etc.</p>
     </s1>
     <s1 title="Implementation">
  -  <p>The implementation is quit simple! Every store can call the <code>register()</code> method
  -  of the actual StoreJanitor component. This checks in a configurable interval if memory is running
  -  low. If low, then the StoreJanitor goes through all stores with a Round Robin algorithm and call
  -  the <code>free()</code> method of the registered stores (which they have to implement per the Store 
  -  interface) so long, until memory is normal.</p>
  +  <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>
     </s1>
     <s1 title="Configuration">
     <source>
  @@ -34,6 +34,7 @@
        <parameter name="heapsize" value="60000000"/>
        <parameter name="cleanupthreadinterval" value="10"/>
        <parameter name="threadpriority" value="5"/>
  +     <parameter name="percent_to_free" value="10"/>
     </store-janitor>
     ]]>
     </source> 
  @@ -55,6 +56,7 @@
         <parameter name="heapsize" value="150000000"/>
         <parameter name="cleanupthreadinterval" value="10"/>
         <parameter name="threadpriority" value="5"/>
  +      <parameter name="percent_to_free" value="10"/>
       </store-janitor>
       ]]>
       </source>
  
  
  

----------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          cocoon-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-cvs-help@xml.apache.org