cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <alexander.klimetsc...@mindquarry.com>
Subject Re: Broken caching of servlet: source in some cases
Date Fri, 20 Apr 2007 18:28:49 GMT
Grzegorz Kossakowski schrieb:
> 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.

Sorry, I understand, but it's kinda difficult to strip down those sitemaps 
and set them up in a new context like the servlet-service-samples.

>> 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?

As described in my last mails: having a last-modified of -1 and comparing it 
with a if-modified-since of -1 (aka both are unknown, no caching should be 
tried at all) you get a not-modified result because of the following line in 
HttpEnvironment.isResponseModified():

             return (if_modified_since / 1000 < lastModified  / 1000);

which results in -1/1000 == -1/1000 => response is *not* modified. This is 
wrong, since two -1 values mean that there is nothing known about 
modification timestamps, so it should retrieve the full content.

>> 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.

I fixed it by introducing servlet:<bean-name>:/foo/bar globally unique URLs, 
at least when a local servlet call is made (ie. servlet:/foo/bar). 
servlet:super:/ and servlet:something:/ stay unmodified (maybe these have to 
be tweaked as well to solve my last unresolved exception).

>> 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).

I implemented this in ServletServiceContext.getNamedContext() by looking up 
servlet:<bean-name>: as well via Spring's application context. So the URLs 
in 2) become actually resolvable.

>> 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?

No, you don't necessarily see the exception, in the end you get an empty 
response and this gives a new exception, the well-known "Premature end of 
file". Any exception in the called block must be passed through, otherwise 
you never see what you were doing wrong in your "backend" sitemap. Had a lot 
of problems with that when exceptions were swallowed in the first blocks-fw 
implementation.

>> 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.

Yes, but still looking for it. My cocoon code is now full of 
System.out.println() statements ;-)

Alex

-- 
Alexander Klimetschek
http://www.mindquarry.com


Mime
View raw message