From dev-return-97590-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Mon Nov 26 20:26:05 2007 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 21994 invoked from network); 26 Nov 2007 20:26:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 26 Nov 2007 20:26:05 -0000 Received: (qmail 7688 invoked by uid 500); 26 Nov 2007 20:25:51 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 7622 invoked by uid 500); 26 Nov 2007 20:25:51 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 7611 invoked by uid 99); 26 Nov 2007 20:25:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Nov 2007 12:25:51 -0800 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Nov 2007 20:25:40 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 0E4D4714208 for ; Mon, 26 Nov 2007 12:25:43 -0800 (PST) Message-ID: <23662215.1196108743032.JavaMail.jira@brutus> Date: Mon, 26 Nov 2007 12:25:43 -0800 (PST) From: "Ellis Pritchard (JIRA)" To: dev@cocoon.apache.org Subject: [jira] Commented: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart In-Reply-To: <20005364.1194631070566.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/COCOON-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545589 ] Ellis Pritchard commented on COCOON-2146: ----------------------------------------- Thanks for your comment, Ard. Your analysis may well explain some performance problems we were seeing on our system; unfortunately I was not around at the time to analyze them, so I can't really be sure what caused them. The action they took at the time was simply to cache less, i.e. only the expensive stuff, rather than, well, basically everything! 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? I think that ehcache 1.4 (now in beta) may provide at least one solution to this problem, with its new listeners functionality, which can get notification of the keys of entries removed (for any reason) from the cache. However, maybe there's a 'redesign the whole thing' kind of solution too? As for whether we need it or not: according to "the powers that be" we do need a persistent cache, so that when we bring the site up under load, on n instances (each with their own cache), it doesn't hammer our database. The fact that was running without one for 8 months due to this bug is not enough to convince them otherwise! It's either that, or having to pre-warm the cache during site-down time (and making site down time longer), or even worse, running the whole site behind mod_cache with an expiry time of about an hour or so, to cover any lag in getting it up again. A persistent EventCache just looks so attractive compared to those options... > 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.