richard@hekkihek.hacom.nl writes:
>In article <50u8ms$n7@zeus.hekkihek.hacom.nl>, richard@hekkihek.hacom.nl (Rich
ard Huveneers) writes:
>>This is with Squid 1.1alpha17 with patch 01 and 02 applied.
>>
>>When our parent is detected to be DEAD, it never revives. This happened last
night
>>(after upgrading to 1.1alpha17). I just tried it manually by blocking the UDP
>>traffic to our parent, and it seems reproducible.
>>
>>I'm now trying to track this bug down, but I don't count on it that I will
>>be able to find it.
>
>Yes! I found the bug. When a parent dies, the mem->e_pings_n_pings counter
>is not incremented (neighbors.c:491). As a result, neighborsUdpPing()
>returns 0 (we have only one parent). But then the ping_status will remain
>PING_NONE instead of PING_WAITING (proto.c:232), and all ICP replies
>will be ignored (icp.c:1116), so the parent will remain dead forever...
>
>I applied the following patch, of which I'm not sure whether it's the
>right way to go, but it works for me. It just increments the mem->e_pings_n_pi
ngs
>for dead parents too. I think this is correct, but I'm not sure.
>
>Anyway, here's the patch:
Excellent detective work!
Your patch has the effect that e_pings_n_pings gets incremented always
so when a parent is down every request might suffer the 'ping_timeout'
(2 seconds).
The better fix is to remove the check for PING_WAITING at icp.c:1116
and call neighborsUdpAck() so the deficit gets reset.
Duane W.
Received on Wed Sep 11 1996 - 13:40:24 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:59 MST