James Satterfield pisze:
> So it seems that setting the source address in the proxy definition is
> the culprit. At least, I've gone about 3 hours now without a
> connection failure since removing the source address definition.
> The explanation I've come up with makes sense to me, however I'm not a
> coder and I don't know C. So I'm presenting this as my understanding
> of what's going on, not as a statement of fact. Please correct me if
> I'm wrong.
> Setting the source address for the server or the proxy causes haproxy
> to call bind() to set the IP we've requested on the fd. haproxy sets
> sockopt SO_REUSEADDR. This succeeds but periodically the connect()
> fails with an EADDRINUSE.
> The reading I've done suggests that SO_REUSEADDR allows you to reuse
> local addresses but the 5 tuple must still be unique. So if haproxy
> reuses a socket currently in TIME_WAIT with web1:80 to connect() to
> web1:80 it will fail with EADDRINUSE.
I got the same issue here.
>There is something else you can do. In proto_tcp.c, you can duplicate
the line with SO_REUSEADDR in >tcpv4_bind_socket(), and replace SO_REUSEADDR with SO_REUSEPORT. Then check if it works better or not. I
>know that both FreeBSD and OpenBSD let you bind multiple processes on
same IP:ports when SO_REUSEPORT is >set, so it is possible that it would help here. Something like this :
>setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *) &one, sizeof(one));
> setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, (char *) &one, sizeof(one));
>If it works, we'll add this for FreeBSD.
I have just added this line and recompiled. I'll share results in a few days.
Piotr Rybicki Received on 2008/12/08 22:55
This archive was generated by hypermail 2.2.0 : 2008/12/08 23:01 CET