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.