Ard Schrijvers escribió:
Thx!!
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. ;-)
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/>
Best Regards,
Antonio Gallardo
[1] http://www.coyotegulch.com/products/jisp/
[2] https://whirlycache.dev.java.net/
Regards Ard
Thanks Ard. I will apply this patch today after work. :-)
Best Regards,
Antonio Gallardo
Ard Schrijvers escribió:
This is a partial fix of a larger problem that I am not yet
capable of fixing: removing cachekeys according the correct
eviction policy.
This fix at least fixes the flaw, that the StoreJanitor
could delete the entire memoryStore part from ehcache. In the
JCSDefaultStore, this size() method was already correct. I
just noticed, that JCSDefaultStore is not in the cocoon trunk
anymore. Is there specific reason for it? Did it move?
Regards Ard Schrijvers
The EHDefaultStore returns in the size() method the wrong
number of keys
--------------------------------------------------------------
----------
Key: COCOON-1885
URL:
http://issues.apache.org/jira/browse/COCOON-1885
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.1.9
Reporter: Ard Schrijvers
Priority: Critical
The excalibut store interface defines a size() method for a store:
/**
* Returns count of the objects in the store, or -1 if
could not be
* obtained.
*/
int size();
What it not explicitely says, is that it is the number of
keys in memoryStore (so not the diskStore) is needed. The
StoreJanitor uses this size() to free some memory from cache
when the JVM is low on memory. Since the current
EHDefaultStore returns with size() ALL cachekeys
(memoryStoreSize + diskStoreSize), it is quite likely when
having a large cache that the StoreJanitor removes all
cachekeys in memoryStore. Simply changing the size() method
of EHDefaultStore to return the number of keys in memoryStore
is sufficient. The JCSDefaultStore did implement it
correctly already (though I do not see it in the cocoon trunk
anymore..?)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
