[
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.
