Re: [squid-users] read_timeout and "fwdServerClosed: re-forwarding"

On mån, 2007-11-26 at 14:48 -0800, Chris Hostetter wrote:

> But in situations like that, wouldn't the normal behavior of a long
> read_timeout (I believe the default is 15 minutes) be sufficient?

yes, and it is.. the retries is only done if within the forward_timeout

> : Hm, what about "retry_on_error" ? Does that do anything in an accelerator
> : setup?
>
> It might do something, but I'm not sure what :) ... even when i set it
> explicitly to "off" squid still retries when the read_timeout is exceeded.

It applies when Squid received an error from the contacted server
only...

> In the event that a request is not in the cache at all, and an origin
> server takes too long to send a response, using the "quick_abort 0" option
> in squid does exactly what I hoped it would: squid continues to wait
> around for the response so that it is available in the cache for future
> requests.

good.

> In the event that stale content is already in the cache, and the origin
> server is "down" and won't accept any connections, squid does what I'd
> hoped it would: returns the stale content even though it can't be
> validated (albeit, without a proper warning, see bug#2119)

good.

> The problem I'm running into is figuring out a way to get the analogous
> behavior when the origin server is "up" but taking "too long" to respond
> to the validation requests. Ideally (in my mind) squid would have a
> "force_stale_response_after XX milliseconds" option, such that if squid
> has a stale response available in the cache, it will return immediately
> once XX milliseconds have elapsed since the client connected. Any in
> progress validation requests would still be completed/cached if they met
> the conditions of the "quick_abort" option just as if the client had
> aborted the connection without receiving any response.

Hmm.. might be a good idea to try Squid-2.HEAD. This kind of things
behaves a little differently there than 2.6..

> "read_timeout" was the only option I could find that seemed to relate to
> how long squid would wait for an origin server once connected -- but it
> has the retry problems previously discussed. Even if it didn't retry, and
> returned the stale content as soon as the read_timeout was exceeded,
> I'm guessing it wouldn't wait for the "fresh" response from the origin
> server to cache it for future requests.

read_timeout in combination with forward_timeout should take care of the
timeout part...

> FWIW: The "refresh_stale_hit" option seemed like a promising mechanism for
> ensuring that when concurrent requests come in, all but one would get
> a stale response while waiting for a fresh response to be cached (which
> could help minimize the number of clients that "give up" while waiting
> for a fresh response) -- but it doesn't seem to work as advertised (see
> bug#2126).

Haven't looked at that report yet.. but a guess is that the refresh
failed due to read_timeout?

Regards
Henrik