cocoon-ehcache-1.data becomes very large 2006-07-13 - By Ard Schrijvers
Back
> On 7/13/06, Andreas Hartmann <andreas@(protected)> wrote:
>
> > ...<parameter name="overflow-to-disk" value="false"/>
> >
> > Is there a special reason why this is set to "false"?...
>
> It's because in that case we only want a short-term cache. There are
> more parameters which might help, they are read by the
> src/java/org/apache/cocoon/components/store/impl/EHDefaultStore.java
> class IIUC.
Beside the fact that I am (have to begin but is on my agenda) going to write a
best practice on these kind of things, I will try some to explain some stuff
here in short:
First of all, make sure you have the EHDefaultStore.java from the trunk. This
one has some important patches.
Now, a common configuration for your store would be:
<store logger="core.store">
<parameter name="maxobjects" value="1000"/>
<parameter name="eternal" value="false"/>
<parameter name="timeToLiveSeconds" value="0"/>
<!-- 1 day -->
<parameter name="timeToIdleSeconds" value="86400"/>
<parameter name="overflow-to-disk" value="true"/>
<parameter name="diskpersistent" value="true"/>
</store>
This means, a maximum of 1000 object (keys+response) are kept in memory. Since
eternal is false, timeToLiveSeconds and timeToIdleSeconds are taken into
account. Is timeToLiveSeconds < timeToIdleSeconds, then only timeToIdleSeconds
matters. In the configuration above, after 1 day of not being used, the
cachekey is removed from cache.
So, when overflow-to-disk is set to true, and you don't have eternal false and
timeToIdleSeconds > 0, then ones a cachekey is in memory/disk, it will never be
removed (apart from the StoreJanitor which when low on memory lets the
EHDefaultStore free its cache ---though this couldn't be implemented worse
because it just starts removing cachekeys/reponses from index 0 (which are
commonly the most important ones) instead of removing them according the
correct eviction policy. I have posted already to the ehcache mailinglist how
to find the LRU one, but not yet got an answer--- and I assume you dont use
eventAware cache actively removing keys )
So, it is very well possible, to let your cache grow INFINITELY large. Setting
timeToIdleSeconds is important. Certainly when for example you have cachekeys
including current date (though, watch out with these kind of cache practices
because your cache could grow very large)
diskpersistent is added to be configurable since short, but does not really
matter. It only indicates persistent cache between JVM restarts (used to be
default true).
If you are working with a cocoon versions < 2.1.9, and you dont want to switch,
but want to use the latest EHDefaultStore, just add the EHDefaultStore.java
from trunk in your src/java/country/yourcomapany/cocoon..., and add to user
.roles:
<role name="org.apache.excalibur.store.Store  "
shorthand="store"
default-class="country.yourcompany.cocoon.components.store.impl
.EHDefaultStore"
/>
Now, just check it out configuring timeToIdleSeconds to 5 secs or something.
Then look at the StatusGenerator, and you will see cachekeys being dumped after
5 sec (by the way, dont refresh the StatusGenerator to often then, because
looking at the StatusGenerator uses the keys, implying they are not idle for
another 5 sec... :-) )
Hope things are little clearer...
Regards Ard
>
> -Bertrand
>
> -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
|
|
