Re: CaheValidity & toString()

[Vadim Gritsenko]

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
http://foo?param=1

and then ask for that same url again, everything appears to be read from the cache.

But, if I ask for

http://foo?param=2

and then ask for
http://foo?param=1

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.

Vadim

...



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]