cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: Caching problems - solved?
Date Wed, 16 May 2001 06:28:34 GMT
> Giacomo Pati wrote:
>
> 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?
> 
Hmm, very good question. I don't know if it worked beforehand because
I never tested it...
But if you turn off caching you have the same problems and in that case
simply setting the content length by hand solves the problems.
Since the early days were we didn't have caching so many changes were
made (introduction of the stream and event pipelines, new fop version etc).

The only solution I see right now is to get reports what is working and
what not.


Carsten 

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de 
================================================================


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


Mime
View raw message