cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <>
Subject Re: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys
Date Tue, 25 Jul 2006 19:09:02 GMT
Ard Schrijvers escribió:
>>> You do not happen to know where the JCSDefaultStore went in 
>> trunk..?? I read some stuff about it outperforming ehcache in 
>> almost every way (and that it might be easier to implement 
>> the eviction policy driven freeing of cachekeys).
>> WARINIG: I am far to be a cocoon expert. I guess Carsten may 
>> answer this 
>> question a long way better than me.  But let me do a try 
>> digging into my 
>> memory:
>> Apache JCS based cocoon cache was introduced as a replacement 
>> for jisp 
>> [1], we dropped out jisp based cache because the jisp owner 
>> changed his 
>> license in the newer versions and there were some big flaws 
>> in the jisp 
>> version used in cocoon. At that time, JCS was not the cache 
>> nirvana, but 
>> we saw it as a nice fast repleacement, because it was under the same 
>> apache umbrella. JCS had some problems too (problems that I 
>> don't know 
>> if they are already fixed now - but I hope so. One of the 
>> problems with 
>> JCS is that his community is very small (very few developers - 3 or 
>> less), because JCS is the kind of projects that everybody 
>> wants to use 
>> and nobody wants to develop. You know. ;-)
> It merely surprised me because I just read,
but of course, I did not measure it myself :-) 
Thanks for the link. JCS 1.2.7 was used for the benchmark. IIRC, in 
cocoon the least used jcs version was 1.2.5. Based on my jcs experience, 
a 1.2.7 release is not just a simple bug fixing release, there are some 
enhancements. Hence a good idea try jcs 1.2.7 or a jcs newer version.
>> At the same time ehcache was emerging as a new kid on the 
>> cache block. 
>> Everybody talked about it, how faster ehcache is and so on. AFAIK, 
>> basically ehcache origin is a stripped down forked old 
>> version of Apache 
>> JCS . Thanks to some cocoon community request, ehcache 
>> community agreed 
>> to have a dual license using ASF and this allowed us to use 
>> his library 
>> in cocoon. This is how the ehcache got into cocoon as another cache 
>> implementation.
>> Few cocoon releases ago, due the (memory leaks?) problems in 
>> apache jcs 
>> base cache, the cocoon community decided to switch to ehcache as our 
>> default implementation. As part of the new idea to strip down 
>> cocoon to 
>> avoid confusing users, the JCS based cache support has been 
>> droppped out.
>> Now, given the current situation, I wonder if was a smart 
>> move to remove 
>> the jcs cache based cache implementation from cocoon at all. 
>> Perhaps we 
>> might keep it into our code as another implementation and let 
>> the user 
>> decide wich one use. Do you think makes sense to ask our 
>> community if we 
>> can continue supporting jcs-base cache?
>> I hear there is another very interesting cache implementation. It is 
>> called whirlycache[2], but there is no cocoon support yet. 
>> Perhaps makes 
>> sense to give him a try.** <>
> Quite a nice historical overview! I certainly consider it worthy to check out this whirlycache.
In the first place, I like this principle that says "Disk overflow becomes a bad idea very
quickly". We have sites around consuming multiple Gb of diskStore with ehcache, this afternoon
I stumbled apon a site having 25.000+ cachekeys (combination of an old EHDefaultStore impl
not implementing time@IdleSeconds though), etc etc. This in combination with the StoreJanitor
trying to free memory from caches when low on memory, but the EHDefaultStore or JCSDefaultStore
are not capable of doing this according the correct eviction policy, makes that for us the
cache implementations have to many short comings. Turning overflow-to-disk to false for sites
seem to let them run more stable! But then I could use MRUMemoryStore as well, and throw away
ehcache. Another problem with ehcache is that you cannot set a limit to the number of keys
in diskStore. This number can grow indefinetly.
> I am going to check out if the wirlycache does not have this short comings.
It sounds great! Please share with us your experience with whirlycache. 
I hear some folks from Lenya already used it with very nice results. If 
this is the same for you, please consider to provide a patch to include 
it in our nice framework. ;-)

Many thanks in advance.

Best Regards,

Antonio Gallardo

View raw message