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 http://jakarta.apache.org/jcs/JCSvsEHCache.html, 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.** <https://whirlycache.dev.java.net/>
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 [EMAIL PROTECTED] 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
