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

sorry for the late reply, i was seriously sick last week and basically
dead to the world...

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

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

Alas ... I don't think i could convince my boss to get on board the idea
of using a devel releases. then again, i'm not too clear on how
branch/release management is done in squid ... do merges happen from
2.HEAD to 2.6 (in which case does 2.6.STABLE17 have the behavior you are
refering to?) or will 2.HEAD ultimately become 2.7 once it's more stable?

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

what do you mean by "in combination with forward_timeout" ...
forward_timeout is just the 'connect' timeout for origin server requests
right? so i guess you mean that if i have a magic value of XX seconds
that i'm willing to wait for data to come back, that i need to set
fowrad_timeout and read_timeout such that they add up to XX right? but as
you say, that just solves the tieout problem, it doesn't get me stale
content.

In my case, i'm not worried about the "connect" time for the origin server
-- if it doesn't connect right away give up, not problem there. it's
getting stale content to be returned if the total request time excedes XX
seconds that i'm worried about (without getting a bunch of
automatic retries)

So it kind of seems like i'm out of luck right? my only option being to
try 2.HEAD which *may* have the behavior i'm describing.

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

(actually that was totally orthoginal to the read_timeout issues ... with
refresh_stale_hit set to Y seconds, all requets are still considered cache
hits up to Y seconds afer they expire -- with no attempt to validate.)

-Hoss
Received on Wed Dec 05 2007 - 15:33:51 MST