cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Broken caching of servlet: source in some cases
Date Fri, 20 Apr 2007 17:30:17 GMT
Alexander Klimetschek napisaƂ(a):
> Grzegorz Kossakowski schrieb:
>> I don't understand your setup a little bit. What is the first
>> transformer for? It would be good if you provided whole pipelines
>> fragment.
>> Attaching whole test blocks to the issue in JIRA is not a bad idea
>> because we can be sure that we execute exactly the same code.
>>
> 
> There are three sitemaps involved and they are very large and complex,
> thus its not so easy to strip them down. But I will do that once I see
> the problems fixed.

Why not earlier? This way I'd be able to help with this issues. Now it is not possible because
I cannot reproduce most of your problems.

> 
> For the bugs: there are multiple bugs, each related to each other and
> behaving differently depending on a caching or non-caching pipeline:
> 
> 1) Last-Modified header set to -1 instead of skipping it (my last mail)

Couldn't reproduce. I also think that this should not harm even though it's not valid to set
Last-Modified header to -1. What kind of
problem this behavior causes for you?

> 
> 2) Equal URIs in different blocks make the first request return an empty
> response. Looks like the resource is in cache because of the same URI
> but cannot be retrieved, thus empty response. On second attempt the
> cache is filled with data. (I haven't been able to debug that
> specifically, so maybe I am not correct here)

Yes, I agree that this can be a problem and should be fixed ASAP.

> 3) When introducing globally unique URIs in ServletSource.getURI() with
> a non-resolvable scheme (eg.
> servlet:com.mycompany.myservlet-bean-id:/foobar) this will make any
> relative resolving of resources fail. Eg. XSLT <include> or <import>
> statements work by taking Source.getURI() as base path for the relative
> path and then resolve this new included source in a normal way. Thus
> things returned by Source.getURI() *must* be resolvable!

I see. It sounds reasonable. We'll have to think how to implement this (should not be that
hard).

> 4) ServletSource.ServletValidity.isValid(SourceValidity) swallows
> exceptions thrown in connect, thus any ProcessingExceptions in the
> called block. It simply returns UNKNOWN validity status and one gets an
> empty response without knowing that an exception was a reason for this.

Thanks for spotting it. I committed logging of this exceptions.
However, I cannot understand how you get empty response. If validity is unknown the resource
should be retrieved from original source.
Second request should occur and if exception still occurs it would be passed down the processing
instead of being swallowed.
What I'm lacking?

> 
> I have fixes for all of this, unfortunately I still get an exception via
> 4) that I cannot explain. It's the same old
> "org.xml.sax.SAXParseException: Premature end of file" because of an
> empty response. :-(

I suspect that all this problems are caused by one (or two) obscure bugs that make parts going
crazy.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message