cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <>
Subject my doubts about the current CocoonStoreJanitor/StoreJanitorImpl
Date Mon, 17 Jul 2006 19:47:49 GMT

I am not sure if everybody is familiar with the CocoonStoreJanitor/StoreJanitorImpl, but in
short it tries to free memory from cocoon's different caches, and does this according some
configuration. For example, 

<store-janitor logger="">
    <!-- How much free memory shall be available in the jvm -->
    <parameter name="freememory" value="2048000"/>
    <!-- Indicates the limit of the jvm memory consumption. The default max
         heapsize for Sun's JVM is (almost) 64Mb -->
    <parameter name="heapsize" value="30000000"/>
    <!-- How often shall the cleanup thread check memory -->
    <parameter name="cleanupthreadinterval" value="10"/>
    <!-- Experimental adaptive algorithm for cleanup interval
    <parameter name="adaptivethreadinterval" value="true"/>
    <!-- Indicates the thread priority of the cleanup thread -->
    <parameter name="threadpriority" value="5"/>
    <!-- How much percent of the elements of each registered Store
         shall be removed when low on memory. Default 10% -->
    <parameter name="percent_to_free" value="10"/>
    <!-- Invoke the garbage collector when low memory is reached -->
    <parameter name="invokegc" value="false"/>

Now, suppose, the JVM is low on memory. Now, I am used to have 3 stores in my apps, namely
defaultTransientStore, eventAwareTransientStore and the EHDefaultStore. I am not sure how
about projects of other people/companies, but I know I can only get some memory free from
the EHDefaultStore. The other stores either store very small responses, or, like the defaultTransientStore,
it only caches a couple of xslt's, which are needed for so many pages, that removing them
makes no sense. The StoreJanitorImpl just removes keys+responses from one single cache at
a time, and moves to the next cache the next time. 

In my opinion, the StoreJanitorImpl makes my cocoon app even worse than before freeing the
cache memory is the following:
1) It removes from caches I think no gain is in
2) It removes cachekeys from the EHDefaultStore in the worst possible way: because the eviction
policy from ehcache is not available from within the EHDefaultStore, cachekeys + reponses
are just removed by starting with index 0. These are frequently the more important keys, which
are regenerated on the next request (so this request is uncached, making it even harder for
the JVM to stay away from OOM).

I have had an email conversation with Greg Luck about this, the main developer from ehcache.
Since you cannot remove cachekeys + responses according the eviction policy defined in the
ehcache, he came up with the idea to add keys with empty responses. 

So, in the StoreJanitor, I check now wether the store is instanceof EHDefaultStore, and if
so, and if the number of keys in memoryStore is larger then the (maxobjects - limit) (limit
is computed in calcToFree(store) as the number of keys to be removed), I add #limit number
of keys with response "". This means, that when maxobjects is reached, you can have 2 cases:

1) overflowToDisk=true: the reponse is serialized to diskStore, and the cachekey is moved
to diskStore cachekey array (by the way still in memory, but the response not anymore )
2) overflowToDisk=false: the cachekey + response is removed entirely

Now, at the end the added "dummy keys" are removed.


WDYT about this new way to free memory from the store. And WDYT about only trying to free
memory from the EHDefaultStore?

Regards Ard


Oosteinde 11
1017WT Amsterdam
The Netherlands
Tel  +31 (0)20 5224466
------------------------------------------------------------- /

View raw message