[jira] Commented: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
[ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545761 ] Ard Schrijvers commented on COCOON-2146: Presumably though, if site-usage is fairly uniform, stuff that expires and is still referenced from AbstractDoubleMapEventRegistry will get regenerated again at some fairly near point, and replace the old entry with the new one, allowing it to be freed by the JVM? Only if you're generating lots of unique pages or short-lived pages and caching them for a long time may it become a 'real' problem? Yes, you would think you absolutely had a point here.but, unfortunately I found out, that the MultiHashMap doen *not* act that way !! (note, it has been a year, and i am not in a position now to dive in the code again but from the top of my head) : If you have a MultiHashMap and you put something like m_keyMMap.put(key1, value1); multiple times, your map grows! you'll have 5 times value1 in it (obviously from a performance POV this is easy to understand) So, exactly what you describe above, will result in OOM. Even if you have only a few possible links, resulting in limited cachekeys, you'll run into OOM in the endI am sorry :-) Anyway, the WeakReference solution is capable of being persisted, but needs some extra stuff to be done at restart. OTOH, notification from ehcache with some listeners might be a solution as well, though 1) it has to be independant of ehcache 2) I still think a DoubleMap is really not the way it should be solved. I would always use WeakReferences for these kind of problems, because the overhead of keeping the maps in sync is not needed. Using EventAware cache implementation breaks persistent cache restore on restart Key: COCOON-2146 URL: https://issues.apache.org/jira/browse/COCOON-2146 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10 Reporter: Ellis Pritchard Assignee: Jörg Heinicke Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: patch.txt In revision 412307 (Cocoon 2.1.10), AbstractDoubleMapEventRegistry and EventRegistryDataWrapper were changed (without an informative SVN comment!) to use the commons MultiValueMap instead of the MultiHashMap; I presume this was done in good faith because the latter map is deprecated and will be removed from Apache commons-collections 4.0 However, as a result, the persistent cache cannot be restored if the EventAware cache implementation is used, since MultiValueMap is not Serializable! The old MultiHashMap was... Depending on whether StoreEventRegistryImpl or DefaultEventRegistryImpl is used, either the event cache index is never written (ehcache doesn't store non-serializable objects on disk), or a java.io.NotSerializableException is thrown (and caught, causing a full cache-clear) when attempting to restore the event cache index. This is Major for us, since we use Event-based caching alot, and this is causing the *entire* cache to no-longer persist across restarts (it's been like that for 8 months, since I upgraded Cocoon to 2.1.10 in the last week I was working here, and now I'm back, they've actually noticed!!) Work-around at the moment is to down-grade AbstractDoubleMapEventRegistry and EventRegistryDataWrapper to the 2.1.9 versions (pre-412307), which works so long as Apache-commons 3.x is still in use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2151) Sub-optimal implementation of AbstractDoubleMapEventRegistry
[ https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545763 ] Ard Schrijvers commented on COCOON-2151: I commented on COCOON-2146, I'll repeat my text over here: Presumably though, if site-usage is fairly uniform, stuff that expires and is still referenced from AbstractDoubleMapEventRegistry will get regenerated again at some fairly near point, and replace the old entry with the new one, allowing it to be freed by the JVM? Only if you're generating lots of unique pages or short-lived pages and caching them for a long time may it become a 'real' problem? Yes, you would think you absolutely had a point here.but, unfortunately I found out, that the MultiHashMap doen *not* act that way !! (note, it has been a year, and i am not in a position now to dive in the code again but from the top of my head) : If you have a MultiHashMap and you put something like m_keyMMap.put(key1, value1); multiple times, your map grows! you'll have 5 times value1 in it (obviously from a performance POV this is easy to understand) So, exactly what you describe above, will result in OOM. Even if you have only a few possible links, resulting in limited cachekeys, you'll run into OOM in the endI am sorry :-) Anyway, the WeakReference solution is capable of being persisted, but needs some extra stuff to be done at restart. OTOH, notification from ehcache with some listeners might be a solution as well, though 1) it has to be independant of ehcache 2) I still think a DoubleMap is really not the way it should be solved. I would always use WeakReferences for these kind of problems, because the overhead of keeping the maps in sync is not needed. 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.
[jira] Commented: (COCOON-2151) Sub-optimal implementation of AbstractDoubleMapEventRegistry
[
https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545767
]
Ard Schrijvers commented on COCOON-2151:
Only if you're generating lots of unique pages or short-lived pages and
caching them for a long time may it become a 'real' problem
Sorry, one more add on this line: It is actually vice versa: when you cache for
a short period of time, you'll run into a 'real' problem much faster: Every
time a page is evicted from the cache by its TTL (time to live) or LRU/MRU
(you'll have faster OOM when you have a small possible number of cache entries)
and it is reloaded, an extra cachekey and event is added to the double maps!
So, the smaller your TTL, the faster you'll run into OOMsounds as a
contradiction I admit :-)
ps if you are suffering from OOM because of growing registry (set TTL low, and
crawl you site several times and use some profiler to see memory) and you don't
want the hassle of WeakReferences with JCSCache (it will take you a few weeks)
you can have a lightweight improvement which would delay the OOM pretty much:
Instead of storing in the doublemaps the events as string, you can easily use
the hashcode of the events. This reduces memory consumption pretty much
already. In the absolute rare cases that two hashcodes coincide, all that
happens is a 'not necessary' removal from a cachekey.
Furthermore, You might hook in something that is similar to the StoreJanitor
for the event registry: ie, every 10 or 60 seconds, check their maps, and if
something is found like
[key1, {value1, value1, value2, value1, value2} ] replace it by
[key1 , {value1, {value2}]
I did something similar on putting a key in, because I had a growing multimap
with WeakReferences(null) after the cachekeys where removed.
Anyway, think there is a lightweight solution possible which works pretty
wellbut i still don't like it :-)
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.
[jira] Commented: (COCOON-2151) Sub-optimal implementation of AbstractDoubleMapEventRegistry
[ https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545801 ] Ellis Pritchard commented on COCOON-2151: - Having looked at MultiHashMap (and MultiValueMap) more closely, I see what you are saying is, of course, true... Looks like the work to do here is: 1/ Implement WeakReference version of EventRegistry, using Ard's code as a base (using MultiValueMap again for future compatibility!) 2/ Implement java.io.Externalizable interface in EventRegistryDataWrapper (or equivalent) to handle custom serialization for the WeakReference maps. Should this be a re-implementation of the existing classes (which now look rather broken), or a completely new implementation which requires a configuration change to select? 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.
[jira] Commented: (COCOON-2151) Sub-optimal implementation of AbstractDoubleMapEventRegistry
[
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.
[jira] Reopened: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
[ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ellis Pritchard reopened COCOON-2146: - Not sure whether to reopen thisbug, or treat this as a 'sub-optimal' implementation issue...(!) When using the DefaultEventRegistryImpl the functionality now works as expected (events are persisted and restored) after the patch applied in COCOON-2146. However, there's still a problem with StoreEventRegistryImpl. The behaviour is that it doesn't seem to actually write/restore any event entries: the maps in the EventRegistryDataWrapper are empty (but not null) after restart, even though the actual cache entry (key EVENTREGWRAPPER) was found in the Store, and the entries were present when persist() was called. The effect of this is to correctly restore the cached entries, but discard all the events, which means that event-flushes don't work any more, which is not a good thing. I've tracked this down to the fact that AbstractDoubleMapEventRepository#dispose() which performs the persist(), then immediately clear()s the maps, WHICH HAVEN'T YET BEEN WRITTEN TO DISK BY EHCACHE SHUTDOWN! This code has probably never worked :) Patches to follow; I propose modifying dispose() to null the map fields, but not perform clear() on them. Using EventAware cache implementation breaks persistent cache restore on restart Key: COCOON-2146 URL: https://issues.apache.org/jira/browse/COCOON-2146 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10 Reporter: Ellis Pritchard Assignee: Jörg Heinicke Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: patch.txt In revision 412307 (Cocoon 2.1.10), AbstractDoubleMapEventRegistry and EventRegistryDataWrapper were changed (without an informative SVN comment!) to use the commons MultiValueMap instead of the MultiHashMap; I presume this was done in good faith because the latter map is deprecated and will be removed from Apache commons-collections 4.0 However, as a result, the persistent cache cannot be restored if the EventAware cache implementation is used, since MultiValueMap is not Serializable! The old MultiHashMap was... Depending on whether StoreEventRegistryImpl or DefaultEventRegistryImpl is used, either the event cache index is never written (ehcache doesn't store non-serializable objects on disk), or a java.io.NotSerializableException is thrown (and caught, causing a full cache-clear) when attempting to restore the event cache index. This is Major for us, since we use Event-based caching alot, and this is causing the *entire* cache to no-longer persist across restarts (it's been like that for 8 months, since I upgraded Cocoon to 2.1.10 in the last week I was working here, and now I'm back, they've actually noticed!!) Work-around at the moment is to down-grade AbstractDoubleMapEventRegistry and EventRegistryDataWrapper to the 2.1.9 versions (pre-412307), which works so long as Apache-commons 3.x is still in use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
[ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545962 ] Ard Schrijvers commented on COCOON-2146: H, I am really confident that persistent caches with the event registry used to work (we have used it for years until i disabled it...but the last time i used it was with 2.1.8, so not sure if something changed :-) ). A restart did use to work. You are really sure that you have a restart persistent cache configuration? I've tracked this down to the fact that AbstractDoubleMapEventRepository#dispose() which performs the persist(), then immediately clear()s the maps, WHICH HAVEN'T YET BEEN WRITTEN TO DISK BY EHCACHE SHUTDOWN! This shouldn't matter. When the registry is persisted, you can clear the double maps. The cache takes care of persisting itself. Can you comment your store configuration of your ehcache? Can you confirm, that on disk, in your work dir after shutdown, you have serialized ehcache files? Can you also confirm you have (i think in the WEB-INF dir somewhere) serialized .ser registry files. Open them with notepad to see that they contain some data if you want At startup, I know that for every entry in the registry, the cachekey is checked wether it is still present in the cache. When not, the registry of this cachekey is discarded. I think you have a problem somewhere in this (though depends on wether your .ser files are empty or not...if empty, the problem is ofcourse in the shutdown) Using EventAware cache implementation breaks persistent cache restore on restart Key: COCOON-2146 URL: https://issues.apache.org/jira/browse/COCOON-2146 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10 Reporter: Ellis Pritchard Assignee: Jörg Heinicke Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: patch.txt In revision 412307 (Cocoon 2.1.10), AbstractDoubleMapEventRegistry and EventRegistryDataWrapper were changed (without an informative SVN comment!) to use the commons MultiValueMap instead of the MultiHashMap; I presume this was done in good faith because the latter map is deprecated and will be removed from Apache commons-collections 4.0 However, as a result, the persistent cache cannot be restored if the EventAware cache implementation is used, since MultiValueMap is not Serializable! The old MultiHashMap was... Depending on whether StoreEventRegistryImpl or DefaultEventRegistryImpl is used, either the event cache index is never written (ehcache doesn't store non-serializable objects on disk), or a java.io.NotSerializableException is thrown (and caught, causing a full cache-clear) when attempting to restore the event cache index. This is Major for us, since we use Event-based caching alot, and this is causing the *entire* cache to no-longer persist across restarts (it's been like that for 8 months, since I upgraded Cocoon to 2.1.10 in the last week I was working here, and now I'm back, they've actually noticed!!) Work-around at the moment is to down-grade AbstractDoubleMapEventRegistry and EventRegistryDataWrapper to the 2.1.9 versions (pre-412307), which works so long as Apache-commons 3.x is still in use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
Joerg Heinicke pisze: On 26.11.2007 21:03 Uhr, Jörg Heinicke (JIRA) wrote: Jörg Heinicke closed COCOON-2146. - Resolution: Fixed Assignee: Jörg Heinicke (was: Grzegorz Kossakowski) URL: https://issues.apache.org/jira/browse/COCOON-2146 Sorry Grek, that I supplanted you. I only saw on closing the issue that you actually assigned it to you. I hope you don't mind :-) No problem, Jörg! I assigned it to myself because I thought that the issue was trivial but recent comments confused me greatly. Thanks for taking care of applying a patch. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
RE: [jira] Closed: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
Sorry Grek, that I supplanted you. I only saw on closing the issue that you actually assigned it to you. I hope you don't mind :-) Grzegorz Kossakowski wrote: No problem, Jörg! I assigned it to myself because I thought that the issue was trivial but recent comments confused me greatly. Sry about that :-) -Ard Thanks for taking care of applying a patch. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: [jira] Closed: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
Ard Schrijvers pisze: Grzegorz Kossakowski wrote: No problem, Jörg! I assigned it to myself because I thought that the issue was trivial but recent comments confused me greatly. Sry about that :-) Don't be sorry, Ard :-) It's just me who has currently no time to dig into cache-related issues deeply. I'm really looking forward to finish all of my math exams because I have so many nice, Cocoon-related things to show laying on my disk... -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
[jira] Issue Comment Edited: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
[ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546023 ] [EMAIL PROTECTED] edited comment on COCOON-2146 at 11/27/07 2:13 PM: - Can you please make it a new issue though? This one should really be only about the serializability. Thanks. And btw., they made COLLECTIONS-240 a blocker after I added a comment yesterday, so it will at least be fixed in Commons Collections 3.3. was (Author: [EMAIL PROTECTED]): Can you please make it a new issue though? This one should really be only about the serializability. Thanks. Using EventAware cache implementation breaks persistent cache restore on restart Key: COCOON-2146 URL: https://issues.apache.org/jira/browse/COCOON-2146 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10 Reporter: Ellis Pritchard Assignee: Jörg Heinicke Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: patch.txt In revision 412307 (Cocoon 2.1.10), AbstractDoubleMapEventRegistry and EventRegistryDataWrapper were changed (without an informative SVN comment!) to use the commons MultiValueMap instead of the MultiHashMap; I presume this was done in good faith because the latter map is deprecated and will be removed from Apache commons-collections 4.0 However, as a result, the persistent cache cannot be restored if the EventAware cache implementation is used, since MultiValueMap is not Serializable! The old MultiHashMap was... Depending on whether StoreEventRegistryImpl or DefaultEventRegistryImpl is used, either the event cache index is never written (ehcache doesn't store non-serializable objects on disk), or a java.io.NotSerializableException is thrown (and caught, causing a full cache-clear) when attempting to restore the event cache index. This is Major for us, since we use Event-based caching alot, and this is causing the *entire* cache to no-longer persist across restarts (it's been like that for 8 months, since I upgraded Cocoon to 2.1.10 in the last week I was working here, and now I'm back, they've actually noticed!!) Work-around at the moment is to down-grade AbstractDoubleMapEventRegistry and EventRegistryDataWrapper to the 2.1.9 versions (pre-412307), which works so long as Apache-commons 3.x is still in use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
[ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546023 ] Jörg Heinicke commented on COCOON-2146: --- Can you please make it a new issue though? This one should really be only about the serializability. Thanks. Using EventAware cache implementation breaks persistent cache restore on restart Key: COCOON-2146 URL: https://issues.apache.org/jira/browse/COCOON-2146 Project: Cocoon Issue Type: Bug Components: Blocks: Event Cache Affects Versions: 2.1.10 Reporter: Ellis Pritchard Assignee: Jörg Heinicke Priority: Minor Fix For: 2.1.11-dev (Current SVN) Attachments: patch.txt In revision 412307 (Cocoon 2.1.10), AbstractDoubleMapEventRegistry and EventRegistryDataWrapper were changed (without an informative SVN comment!) to use the commons MultiValueMap instead of the MultiHashMap; I presume this was done in good faith because the latter map is deprecated and will be removed from Apache commons-collections 4.0 However, as a result, the persistent cache cannot be restored if the EventAware cache implementation is used, since MultiValueMap is not Serializable! The old MultiHashMap was... Depending on whether StoreEventRegistryImpl or DefaultEventRegistryImpl is used, either the event cache index is never written (ehcache doesn't store non-serializable objects on disk), or a java.io.NotSerializableException is thrown (and caught, causing a full cache-clear) when attempting to restore the event cache index. This is Major for us, since we use Event-based caching alot, and this is causing the *entire* cache to no-longer persist across restarts (it's been like that for 8 months, since I upgraded Cocoon to 2.1.10 in the last week I was working here, and now I'm back, they've actually noticed!!) Work-around at the moment is to down-grade AbstractDoubleMapEventRegistry and EventRegistryDataWrapper to the 2.1.9 versions (pre-412307), which works so long as Apache-commons 3.x is still in use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
