cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: AW: [C2]: Caching problems - solved?
Date Tue, 15 May 2001 19:31:42 GMT


On Mon, 14 May 2001, Carsten Ziegeler wrote:

> Hi,
>
> 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
>   response.
>
> 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.

Before having a cache didn't the pages show up correctly? Did I miss
something about the problem of the setContentLength which wasn't set
before caching either?

Giacomo

>
> Could someone verify if this is now our only remaining
> problem? And what can we do?
>
>
> Carsten
>
> Open Source Group                        sunShine - b:Integrated
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de                          mailto: cziegeler@sundn.de
> ================================================================
>
> > 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message