Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 74136 invoked by uid 500); 1 Aug 2003 07:49:12 -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 Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 74118 invoked from network); 1 Aug 2003 07:49:11 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 1 Aug 2003 07:49:11 -0000 Received: (qmail 28648 invoked by uid 50); 1 Aug 2003 07:51:59 -0000 Date: 1 Aug 2003 07:51:59 -0000 Message-ID: <20030801075159.28647.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: dev@cocoon.apache.org Cc: Subject: DO NOT REPLY [Bug 14348] - Caching problem with XSP, XSL and cocoon pseudo protocol X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348 Caching problem with XSP, XSL and cocoon pseudo protocol ------- Additional Comments From m_rolappe@web.de 2003-08-01 07:51 ------- the bug is the way SitemapSource (here cocoon:/bar) computes its last modified date; it hashes a combination of the event pipeline's cache key and the corresponding validity. this yields (in most cases?) a negative number. when ProgramGeneratorImpl checks the xsp's creation date against the source's last modified date it 'finds out' that the xsp is 'newer' and must be updated. in cocoon 2.1 (from a quick look at a checkout) the SitemapSource just returns 0; can't determine. which means that recompilation of the XSP would be done here also. so, the solution is to get a valid last modification date for the SitemapSource, for which there are probably many ways, e.g. - store the creation/modification date for a cached stream/event pipeline, and make it accessible - store that date and the pipeline's validity in transient cache and later on check previous (stored) validity against current validity and if validity changed, update last modified and store validity I've tried the latter one. if there's any interest I could provide a patch.