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
Attachment:
signature.asc
Description: This is a digitally signed message part
