cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-2151) Sub-optimal implementation of AbstractDoubleMapEventRegistry
Date Tue, 27 Nov 2007 12:46:43 GMT

    [ https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545809
] 

Ard Schrijvers commented on COCOON-2151:
----------------------------------------

The problem with (1) is that it did not work for me for ehcache when also using filesystem
cache (which I always wanted to have). You can configure caches like ehcache or jcscache to
use memory only cache, or to overflow to disk. When overflowing to disk was enabled, ehcache
in combination with the WeakReference did not work. I investigated ehcache, but could not
find the reason. Since, ehcache at that moment (think they enabled it) did not offer a way
to limit the number of filesystem entries, and jcscache did, and jcscache worked with the
WeakReferences, I choose my solution with the WeakReferences. 

Do realize however, that I build my solution on the fact, that jcscache honoured references
(overflowing cache entries to disk kept the same references for cachekey) but this is *not*
a general specification of how a cache works. Therefor, however my solution works very well,
and sites never went down anymore because of OOM, I do not think the solution is strong enough
as  standard cocoon code

The problem with (2) is, that if you serialize the WeakReferences registry, you only serialize
the string cachekeys and string event. At startup, you have to traverse to entire cache to
recreate the correct WeakReferences, which might imply slow restarts for persistent caches.

So, the problem is really quite hard to have a proper cocoon core solution if you ask me.
 I can help out with pointers, but am really occupied ATM with other things, so am not in
a position to contribute code (except for the code I wrote). 

Perhaps the easiest way to solve the current problem is a background thread which from time
to time checks the multihashmaps for duplicate values like [{key1}, {value1,value1,value1}]
and remove these. To use hashcodes for the events (to reduce memory a lot for the events (remember,
the cachekey strings are already present in the jvm because of the cache, so shouldn't take
a lot of extra memory...)).  Then, the only thing the background thread (similar to  the StoreJanitor
) should check for keys in the multivaluemap wether they are still somewhere in cache, and
if not, clean up these values. There is one pretty obvious con: testing for the presence of
a key in the cache influences 

1) the TTL (it is used again)
2) messes up the logical LRU/MRU eviction policy

Sry for only giving pointers, and not the time to help with the implementation

ps Also whirlycache might be worth looking at by the way (jcscache has a very hard configuration
to start with) 

> Sub-optimal implementation of AbstractDoubleMapEventRegistry
> ------------------------------------------------------------
>
>                 Key: COCOON-2151
>                 URL: https://issues.apache.org/jira/browse/COCOON-2151
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: Blocks: Event Cache
>    Affects Versions: 2.1.10, 2.2-dev (Current SVN)
>            Reporter: Jörg Heinicke
>
> This is just a follow-up from COCOON-2146 where Ard pointed out some issues with AbstractDoubleMapEventRegistry.
I just didn't want to lose the information when I actually fixed the issue. So I will add
it here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message