 | | | cocoon-ehcache-1.data becomes very large | cocoon-ehcache-1.data becomes very large 2006-07-13 - By Andreas Hartmann
Back
Ard Schrijvers wrote:
>> 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:
Ard, thanks for your comprehensive answers!
I'll take a closer look at your recommendations.
Will you announce your how-to on the list?
-- Andreas
>
> 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)
>>
>>
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@(protected) andreas@(protected)
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
|
|
|