cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Broken caching of servlet: source in some cases
Date Fri, 20 Apr 2007 18:58:00 GMT
Alexander Klimetschek napisaƂ(a):
> 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.

Maybe try creating sample from scratch instead of stripping down your complicated pipelines?
I guess this would help also you to track down
cases when it actually fails and focus on it.

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

I see. The only place where if-modified-since could be set to -1 and that I know of is ServletSource$ServletValidity#isValid()
You got me! (I realized what's going on with this one while writing an e-mail)
The bug is in ServletSourc#getValidity(). It returns validity object even though information
(Last-Modified header) needed to calculate it
does not exists! This way, ServletValidity will hold "-1" value in it's lastModified field
and will pass it to the request as
If-Modified-Since next time it is asked if it is still valid.
This bug only show up if called pipeline is non-caching and calling is caching one.
I'm really not sure why I didn't catch it while implementing caching for ServletSource.

I'll commit fix in minutes, could you test it in your env?

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

Think about servlet:<shorthand_name>:/** URIs as _relative_ ones (because they are relative
to block's context) and servlet:<bean-id>:/** as
_absolute_ ones (because they are independent from any context). Now, ServletSource#getURI()
*must always* return absolute one because it's
part of contract.
So if you have it implemented, can you provide a patch?

> 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 don't agree with this one. AFAIK, in servlet-service-fw implementation exception are passed
back to the calling sitemap. It was you who
provided a patch: :-)

Grzegorz Kossakowski

View raw message