Mark, Thanks for that suggestion. I had independently come to the same idea, after posting my message, but haven't yet had a chance to try it out. I currently have hierarchies of cache_peer parents but stop the hierarchies just before the last step to the origin servers because they were selected by the host & port number in the URLs. The origin servers have their own squids configured in accelerator mode so I think I will just extend the hierarchies all the way to them and let the squids (the ones which were formerly the top of the hierarchies) take care of detecting when an origin server goes down (using the cache_peer monitorurl option). I did a little experiment and found out that it doesn't matter what the host and port number are in a URL if the top of a cache_peer parent hierarchy is an accelerator mode squid, so I don't think I'll even have to change the application. - Dave On Fri, Oct 03, 2008 at 11:21:19AM +1000, Mark Nottingham wrote: > Have you considered setting squid up to know about both origins, so it > can fail over automatically? > > > On 26/09/2008, at 5:04 AM, Dave Dykstra wrote: > > >I am running squid on over a thousand computers that are filtering data > >coming out of one of the particle collision detectors on the Large > >Hadron Collider. There are two origin servers, and the application > >layer is designed to try the second server if the local squid returns a > >5xx HTTP code (server error). I just recently found that before squid > >2.7 this could never happen because squid would just return stale data > >if the origin server was down (more precisely, I've been testing with > >the server up but the listener process down so it gets 'connection > >refused'). In squid 2.7STABLE4, if squid.conf has 'max_stale 0' or if > >the origin server sends 'Cache-Control: must-revalidate' then squid will > >send a 504 Gateway Timeout error. Unfortunately, this timeout error > >does not get cached, and it gets sent upstream every time no matter what > >negative_ttl is set to. These squids are configured in a hierarchy > >where each feeds 4 others so loading gets spread out, but the fact that > >the error is not cached at all means that if the primary origin server > >is down, the squids near the top of the hierarchy will get hammered with > >hundreds of requests for the server that's down before every request > >that succeeds from the second server. > > > >Any suggestions? Is the fact that negative_ttl doesn't work with > >max_stale a bug, a missing feature, or an unfortunate interpretation of > >the HTTP 1.1 spec? > > > >By the way, I had hoped that 'Cache-Control: max-stale=0' would work the > >same as squid.conf's 'max_stale 0' but I never see an error come back > >when the origin server is down; it returns stale data instead. I wonder > >if that's intentional, a bug, or a missing feature. I also note that > >the HTTP 1.1 spec says that there MUST be a Warning 110 (Response is > >stale) header attached if stale data is returned and I'm not seeing > >those. > > > >- Dave
