[
https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545506
]
Ard Schrijvers commented on COCOON-2146:
----------------------------------------
FYI : IMO, the AbstractDoubleMapEventRegistry is a very bad implementation, and
OOM sensitive. I was facing sites needing a restart every few days (very high
traffic sites, > 100.000 pages ) because of the double map event registry in
combination with ehcache, It has been more than a year ago, so I might be off
at some places, but :
The AbstractDoubleMapEventRegistry used for event caching was build a long
time ago (I wasn't around) and was based on an internal cocoon cache, which in
turn was managed by the StoreJanitor. This internal cache has been replaced by
ehcache, or jcscache. These caches handle their own cache (TTL, LRU, ETERNAL,
etc etc). This means, that when this cache decides to remove a cached entry,
this remove was not initialized by the StoreJanitor, hence not propagated to
the event registry. This ends up in an ever growing event registry.
Also, I totally did not like the AbstractDoubleMapEventRegistry. Keeping
double mapped maps in sync....it kind of is stupid. And, this is exactly the
thing you use WeakReferences for. So I rebuild the registry for our projects to
use WeakReferences. Only problem I faced, was that for a reason I have never
been able to find or reproduce outside cocoon, it didn't play well with ehcache
because references seemed to change. Therefor I did implement it in combination
with JCSCache (which by the way performed better). While I was busy I changed
the registry to enable multiple caches because I wanted filesystem caches for
binary repository data, a seperate cache for repository xml files, and a
seperate one for pipelines.
I am not sure if anyone is interested... :-) Because of the ehcache reference
problems and the fact that I had no easy way (without reading the entire cache
at startup) to have a persistent cache with a registry (WeakReferences cannot
be persisted ofcourse) I never considered the code suitable for Cocoon. OTOH,
I left EHCache without problems, and IMO, needing a persistent cache does seem
to me that you should have implemented your application differently. I have
always been concerned performance, and I just know that an uncached pipepline
with external repository sources, with webdav calls en searches, can easily
finish within 50-100 ms. If you must rely on your cache that havily that it
should survive a restart, I think you are misusing cocoon's cache anyway. Just
my 2 cents
Anyway, if anybody is interested, the code is over here:
https://svn.hippocms.org/repos/hippo/hippo-cocoon-extensions/trunk/eventcache/src/java/org/apache/cocoon/caching/impl/
and then mainly AbstractWeakRefMapEventRegistry.java.
> 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, 2.1.11-dev (Current SVN)
> Reporter: Ellis Pritchard
> Assignee: Grzegorz Kossakowski
> 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.
