Stephen Ng wrote:
Okay, I think I've found the problem with my aggregate caching.... which means that these two URLs produce different Validity objects in from-an-xsp pipeline. Is it right?
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.
(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?
Vadim
...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
