cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: lastModificationDate misuse? - old thread - progress
Date Sun, 10 Aug 2003 07:29:44 GMT
Bug was fixed some days ago: 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348. Carsten 
requested for testers of the patch, so if you can test the behaviour 
with the current Cocoon 2.0 CVS it will be good.

Joerg

John Williams wrote:
> I have been mystified by the symptoms of the problem raised by Stuart 
> Roebuck some time ago on cocoon-dev and I can't see if/when it has been 
> fixed or a workaround/hack avail:
> If XSP is the result of a pipeline then the ServerPages Generator can't 
> work out its currency and randomly re-generates and compiles. To make 
> matters worse if the XSP has the code necessary for resultant objects to 
> be cached then the code generated and compiled is not even used, ie a 
> cached object is used instead.
> 
> I have inspected the code of 2.0.4 and it is still there, ie code is 
> same as when reported in 2001. Surely a typical use of cocoon is to 
> build XSP using XSLT?
> 
> John
>  
>  
> Stuart Roebuck wrote:
>  >>On Tuesday, August 14, 2001, at 04:04  pm, Carsten Ziegeler wrote:
>  >>
>  >>> In SitemapSource.java are the lines:
>  >>>
>  >>>> // the event pipeline is cacheable
>  >>>> // now calculate a last modification date
>  >>>> String hashKey = pck.toString() + validity.toString();
>  >>>> this.lastModificationDate = HashUtil.hash(hashKey);
>  >>>
>  >>> this is used in ProgramGeneratorImpl.java:
>  >>>
>  >>>> /*
>  >>>>  * FIXME: It's the program (not the instance) that must
>  >>>>  * be queried for changes!!!
>  >>>>  */
>  >>>> if (programInstance != null &&
>  >>>> programInstance.modifiedSince(source.getLastModified())) {
>  >>>>   // Release the component.
>  >>>>   release(programInstance);
>  >>>
>  >>> consequently, any use of the ServerPages Generator which takes an input
>  >>> from within the sitemap (e.g. using a "cocoon:/" URI) will result
>  >>> in (on a
>  >>> practically random basis) certain XSP (et. al) pages being regenerated
>  >>> over and over again, and will potentially prevent updated XSP (et. al)
>  >>> from being properly regenerated.
>  >>>
>  >> Hm, that is true. The problem is that I don't saw any other way to
>  >> implement the lastModificationDate for the SitemapSource than hashing
>  >> the key.
>  >> Usually this modification date is used in the caching algorithm
>  >> and is there only tested against equal. So there this hack works.
>  >>
>  >> Any solution for this?
>  >
>  >For the caching, I presume there is a mapping of hashKeys to
>  >serializedResults.  If this is true, then couldn't these also map to a
>  >date-stamp of when the result was cached and have lastModificationDate =
>  >lastCachedDate?


Mime
View raw message