cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: CaheValidity & toString()
Date Mon, 28 Oct 2002 22:08:42 GMT
Stephen Ng wrote:

>Okay, I think I've found the problem with my aggregate caching.
>I have an xsp, and I use the cocoon:/ protocol to map:aggregate that xsp.  Something like
the usual:
><map:match pattern="foo">
> <map:aggregate element="site">
>  <map:part src="cocoon:/from-an-xsp.xml"/>
> </map:aggregate>
>The symptom is that if I ask for 
>and then ask for that same url again, everything appears to be read from the cache.
>But, if I ask for
>and then ask for  
>according the logs, Cocoon is re-aggregating the cached content of my xsp, rather than
using the cached aggregated value. 

... which means that these two URLs produce different Validity objects 
in from-an-xsp pipeline. Is it right?

>(This is a problem because I have quite a few transformations that take place after that
aggregation, and they all get re-run needlessly).
>The problem appears to be that the aggregated content has a key which is based upon the
src string (cocoon:/from-an-xsp.xml) which, in this case, is identical--it doesn't bother
to ask the xsp for its key value.

But what about validity? Seems that it changes.

>A workaround for this is to make the ContentAggregator key based upon the source's getLastModified()
number (which, at least, is based upon hash of xsp's validity object [SitemapSource:refresh()]).
>In ContentAggregator:
>    public long generateKey() {
>		    // ...
>                if (current.getLastModified() == 0) {
>                        return 0;
>                } else {
>			  // ...
>                    key += current.getLastModified();  // <-- ADD THIS LINE

Right now it has:
                        key += HashUtil.hash("P=" +
                                         part.stripRootElement + ':' +
                                         current.getSystemId() + ';');

And that is correct.

>                }
>                // ...
>Does the problem & solution make sense?

No, it does not (yet) make sense to me. May be your explanation about 
validity of the aggregated pipeline will help.



To unsubscribe, e-mail:
For additional commands, email:

View raw message