cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [jira] Created: (COCOON-1885) The EHDefaultStore returns in the size() method the wrong number of keys
Date Tue, 25 Jul 2006 15:39:00 GMT
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
>>     
>>>         
>>>   
>>>       
>>     


Mime
View raw message