H.-Dirk Schmitt wrote:
> Hello !
>
> I have problems on a squid3 with parent fail over.
>
> The installation has the following layout.
> client --> internal-proxy --> external-proxy (2 instances parent-1 and
> parent-2) --> internet
>
> The client is a bussiness application with demand to communicate to
> distinct partners on the internet.
> The internal proxy implements a white list filtering for allowed urls.
> The external proxies are sitting in a network zone with access to the
> internet. They are located in 2 different computing centers with
> dedicated internet connections.
>
>
> Everything is well, if both parents are running. The whole traffic is
> routed to parent-1 (sitting in the same computing center).
>
> If I shut down parent-1 no fail over to parent-2 happens.
> I can track down the problem (debug 15,9) to the following log statements:
>
> 2009/12/03 22:36:01.920| getFirstUpParent: returning
> 192.168.253.17 # should be dead
> 2009/12/03 22:36:01.920| peerGetAllParents: adding alive parent
> 192.168.253.17 # should be dead
> 2009/12/03 22:36:01.920| peerGetAllParents: adding alive parent
> 192.168.253.18 # running
>
> The access log says that the requests are still handled by
> FIRST_UP_PARRENT: TCP_MISS:FIRST_UP_PARENT
> The result is a 503: X-Squid-Error: ERR_CONNECT_FAIL 111
>
> The squid.conf follows below.
>
> Has anybody a hint?
Squid for legacy reasons takes 10 failures to detect a down parent.
The change to make it configurable (connect-fail-limit=N option) is only
available in 3.1 beta and 2.HEAD alpha code.
For other releases connect-timeout=N may be able to reduce the failure
detection below the request forwarding timeout which generates the error
page.
Amos
-- Please be using Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20 Current Beta Squid 3.1.0.15Received on Fri Dec 04 2009 - 13:34:02 MST
This archive was generated by hypermail 2.2.0 : Fri Dec 04 2009 - 12:00:01 MST