froehlich 02/01/27 15:37:13
Modified: src/documentation/xdocs/userdocs/concepts mrustore.xml
Log:
Documentation needed a update.
Revision Changes Path
1.2 +32 -47
xml-cocoon2/src/documentation/xdocs/userdocs/concepts/mrustore.xml
Index: mrustore.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/mrustore.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- mrustore.xml 3 Jan 2002 12:31:04 -0000 1.1
+++ mrustore.xml 27 Jan 2002 23:37:13 -0000 1.2
@@ -3,94 +3,79 @@
<document>
<header>
- <title>MRUMemoryStore in Apache Cocoon</title>
+ <title>MRUMemoryStore and Swapping under Apache Cocoon</title>
<version></version>
<type>Technical document</type>
<authors><person name="Gerhard Froehlich" email="[EMAIL PROTECTED]"/>
</authors>
- <abstract>This document explains how the MRUMemoryStore under Cocoon
executes.</abstract>
+ <abstract>This document explains how the MRUMemoryStore and Swapping under
+ Cocoon executes.</abstract>
</header>
<body>
<s1 title="Goal">
- <p>This document explains how the MRUMemoryStore under Apache Cocoon
executes.</p>
+ <p>This document explains how the MRUMemoryStore and Swapping under
+ Cocoon executes.</p>
</s1>
<s1 title="Overview">
<p>The MRUMemoryStore was developed to provide a standard algorithm to
store data in memory. For web-based applications the MRU (Most Recently
Used) algorithm
is very suitable, because the object most frequently accessed is always on
"top".
</p>
- <p>If configured accordingly, the objects are also swapped to the filesystem,
to hold them
- in a persistent state over JVM restarts.
+ <p>If configured, the objects are also swapped to the filesystem if the
+ MRUMemoryStore reached his configured max. object limit.
</p>
</s1>
<s1 title="Implementation">
- <s2 title="Storing in memory">
+ <s2 title="MRUMemoryStore">
<p>
The heart of the MRUMemoryStore ist combination of a LinkedList and a HashMap:
</p>
<p>
The LinkedList provides the queue mechanism, and the entries in the LinkedList
- contain the key to the data in the HashMap. When calling the
<code>store()</code>
- method a new entry to the front of the list is inserted.
- If the list is already full, the <code>free()</code> method is called and the
oldest,
- the last one in the LinkedList, data entry is removed from the HashMap and from
the
- LinkedList.
- When calling the <code>get()</code> method, the store returns the object by key
- and inserts the requested key on the top of the LinkedList.
+ contain the key to the data in the HashMap. When caching a new entry in to the
list,
+ the entry is inserted to the front of the list.
+ If the list is already full, the oldest data entry is removed from the Cache.
+ When requesting a entry, the store returns the object by key and inserts the
requested key
+ on the top of the Cache.
This implementation keeps the most recent used objects in the store and
provides the best
use of the machines memory.
</p>
</s2>
- <s2 title="Storing on the filesystem">
+ <s2 title="Swapping">
<p>
- Storing in Memory is fast, but when the JVM restarts your processed Objects are
gone and
- must be processed again, although they didn't have changed. What a waste of CPU
time.
+ When the MRUMemoryStore is full or the JVM is at the heap size limit the
+ objects in the MRUMemoryStore are swapped to the Filesystem. The default
+ directory is "cache-dir" in the work-directory.
</p>
<p>
- If configured, the MRUMemoryStore will keep your objects not only in memory,
rather also on
- the filesystem. When calling the <code>store()</code> method, objects are
pushed on a stack,
- which is processed by a "writerthread" in the background. This thread pops the
object from the
- stack and serialize it to the fs. So the objects are asynchron written to the
filesystem,
- to keep the performance fast. The thread sleeps and awakes only, when one or
more objects
- are pushed on the stack. But only CacheStreamObject's and CacheEventObject's in
the moment
- are stored on the filesystem.
- </p>
- <p>
- If you restart your application memory is clean. When you request an object
with the <code>get()</code>
- method the filesystem is checked if the requested object is available,
deserialize it and give
- it back to the caller. After all the <code>store()</code> method is called and
the
- deserialized object is stored in memory for further usage.
- </p>
- </s2>
- <s2 title="Background threads">
- <p>
- The WriterThread is notified when an object is pushed on the stack and
serialize the objects
- in the stack on the filesystem.
+ NOTE: The keys under Cocoon are Strings at the moment. Therefor the
+ filenames of the swapped objects can be very long. Especially Windows OS
+ flavours have problems with long filenames. This problem is well known and
+ we are working on that.
</p>
</s2>
</s1>
<s1 title="Configuration of the MRUMemoryStore">
<source>
<![CDATA[
- <event-cache class="org.apache.cocoon.components.store.MRUMemoryStore">
+ <store class="org.apache.cocoon.components.store.MRUMemoryStore"
logger="core.store">
<parameter name="maxobjects" value="100"/>
- <parameter name="threadpriority" value="5"/>
<parameter name="filesystem" value="true"/>
- </event-cache>
+ </store>
]]>
</source>
- <p>If you want to use the MRUMemoryStore as your EventCache:</p>
- <ol>
- <li><code><event-cache
class="org.apache.cocoon.components.store.MRUMemoryStore"></code>:
- Assigns the MRUMemoryStore as the actual EventCache.</li>
+ <p>Explanation of the paramters:</p>
+ <ol>
<li><code><parameter name="maxobjects" value="100"/></code>:
- Indicates how many objects will be hold in the cache. When the number of
maxobjects has been reached.
- The last object in the cache will be thrown out.</li>
- <li><code><parameter name="threadpriority" value="5"/></code>:
- Indicates the priority of the background threads. 1 is the lowest priority
and 10 is the highest.</li>
+ Indicates how many objects will be hold in MRUMemoryStore. When the number
+ of maxobjects has been reached, the last object in the MRUMemoryStore will be
+ thrown out.</li>
<li><code><parameter name="filesystem" value="true"/></code>:
- Turns the filesystem storage for objects on or off.</li>
+ If this switch is set on true, objects are swapped out to the filesystem,
+ if the MRUMemoryStore has reached his maximum object limit, or the JVM
+ memory consumption is over the heap size limit. See StoreJanitor user
+ docs for more information.</li>
</ol>
</s1>
</body>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
