cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: [C2]: Caching problems - solved?
Date Mon, 14 May 2001 12:22:10 GMT

debugging the caching algorithm I found and fixed two bugs:

- The first one produced in some cases wrong pipeline
  chaines for the xml compiler. So the response was
  cached at the wrong stage.
- The second one was in the caching output stream component.
  If byte arrays were written to the output stream they
  were sometimes copied twice into the output stream but
  not in the cached version. So the first not cached response
  was wrong and refetching it from the cache got a correct

The patches fix some of the problems with the caching, but
unfortunalety not all:

I reproduced the behaviour from Rick and Jason by simply 
always returning 0 for the cache key in the TraxTransformer.
If the TraxTransformer can not cache, the response of the
hello.pdf is not shown in the browser (I use IE with 
the acrobat reader plugin). If the TraxTransformer can
cache - the whole response is cached by the CachingStreamPipeline
and everything is fine. If theTraxTransformer is not cacheable
the partial response is cached by the CachingEventPipeline.

Now I started to compare the output of the two runs.
And my result is: 
- The bytes outputted to the OutputStream are in both cases 
  exactly the same (1135 bytes). 
- If the CachingStreamPipeline caches only the methods
  getOutputStream(), setContentType and setContentLength
  of the HttpResponse are called.
- If the CachingEventPipeline caches only the methods
  getOutputStream() and setContentType are called.

So, the only difference is the content length which is not
set if the CachingEventPipeline  caches!
For testing I added an explicit setContentLength() and 
that was it. Everything worked fine again.
The Acrobat reader can not display the pdf correctly if the
content length is not set, I assume. Saving the pdf link
of the welcome page to disk and opening the saved file works
in both cases.

So, how can we solve this? If not the whole response is 
cached it is as far as I see not possible to get the
length of the content. So we can't set it correctly.

Could someone verify if this is now our only remaining
problem? And what can we do?


Open Source Group                        sunShine - b:Integrated
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn                          mailto: 

> Carsten Ziegeler wrote:
> Hi,
> thanks for your results Rick. Attached are my results. As you
> can see both responds are equal. There is no difference.
> After comparing your cocoon.log with my cocoon.log I found
> an interesting difference: The TraxTransformer is not able
> to get the last modification date of your stylesheet (it is 0).
> So the caching algorithm is not able to cache the whole
> response for the welcome page but only the stage directly
> after the generator.
> On my system I the TraxTransformer gets the last modification
> date of the stylesheet and the whole response is cached.
> So my former assumption that it is not always possible to get
> the last modification date seems to be correct. (So the over
> the last weeks reported bug that changed stylesheets are not
> handled correctly must be related to exactly this!).
> Ok back to this problem now: I don't know why your last
> modification date is 0. Has anyone an idea?
> But anyway, the caching algorithm should work even in that
> case. I have to take a closer look at your log for what
> is happening with the cached response.
> Jason, could you please check your cocoon.log for the 
> last modification date of the stylesheet. Is it also 0?
> Carsten
> PS: The same problem applies to the generation of the pdf.
> > Rick Tessner wrote:
> > 
> > On Fri, 11 May 2001 09:43:57 EDT, Jason Foster wrote:
> > 
> > >> Is someone else still having problems with the latest cvs
> > >> on those examples?
> > 
> > Hi All!
> > 
> > I've attached a zip file containing the results of the welcome page
> > refresh issue.  There are 3 files in the zipfile (unzips in a directory
> > called welcome)
> > 
> >   welcome/welcome-new.html
> >   welcome/welcome-cache.html
> >   welecome/cocoon.log
> > 
> >   - The "welcome-new.html" is the results of the first hit against the
> >     welcome page.  Everything in here looks as it should.
> >   - The "welcome-cache.html" is the result of a second hit against the
> >     welcome page when it is already sitting in the cache.
> >   - The "cocoon.log" is the entire cocoon.log for the above two
> >     hits and only those two hits.
> > 
> > I'll put together an similiar archive for what I'm seeing with
> > the "hello.pdf".
> > 
> > My setup is:
> > 
> >   Latest cocoon2 from xml-cocoon2
> >   Java HotSpot(TM) Client VM (build Blackdown-1.3.0-FCS, mixed mode)
> >   Resin 1.2.5
> > 
> >   Vanilla sitemap.xmap, cocoon.xconf, web.xml
> > 
> > 

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

View raw message