[
https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545680
]
[EMAIL PROTECTED] edited comment on COCOON-2151 at 11/26/07 6:08 PM:
-----------------------------------------------------------------
Ard Schrijvers wrote at COCOON-2146:
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.
was (Author: [EMAIL PROTECTED]):
Ard Schrijvers wrote at COCOON-2146#action_12545506:
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.
> 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.
