You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2003/08/01 09:51:59 UTC
DO NOT REPLY [Bug 14348] -
Caching problem with XSP, XSL and cocoon pseudo protocol
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348>.
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.