Re: haproxy & websockets

From: Dustin Moskovitz <moskov#asana.com>
Date: Tue, 27 Apr 2010 14:54:24 -0700

Yea, I should have thought of that - certainly we are on the cutting edge :)

Unfortunately, when I try to upgrade from 1.4.0, I am unable to get the proxy up and handling requests (forgetting the virtual hosts thing, just trying to use the config I already had working). The only thing I see in the log output is:
Available polling systems :

       poll : pref=200,  test result OK
     select : pref=150,  test result OK

Total: 2 (2 usable), will use poll.
Using poll() as the polling mechanism.
[ALERT] 116/214946 (671) : socket for logger #1 failed: Address family not supported by protocol (errno=97)

Requests just seem to hang from the client's perspective and I don't see anything on the console indicating they are being handled. There is nothing in the log, which makes sense given the logging alert. I will get a separate alert for each backend block I have defined, regardless of whether it actually has a log line or what options I try using there. Is it possible that the new haproxy somehow enforces ipv6 addresses?

On Tue, Apr 27, 2010 at 1:28 PM, Willy Tarreau <w#1wt.eu> wrote:

> Hi Laurie, hi Dustin,
>
> First, Dustin, you really need to get a very recent version of haproxy.
> 1.4.4 is fine. This is particularly important because handling of the
> 101-switching protocol is something new (and the WebSockets draft is
> evolving quickly and the latest version is not anymore compatible with
> earlier implementations).
>
> On Tue, Apr 27, 2010 at 10:24:20AM +0100, Laurie Young wrote:
> > We are doing something very similar. I have a sample of our config file
> > below. However this is not perfect. We are seeing a lot of dirty
> connections
> > for normal http traffic because of the long timeout,
> > and we are having some, as yet not-fully-diagnosed issues with
> incorrectly
> > terminated connections to the http backend.
>
> I'm realizing that given your extremely large timeouts, you may want to try
> "option nolinger" in the frontend to get rid of the kernel socket buffers
> when haproxy decides to timeout a connection. That will avoid needless
> FIN_WAIT2 states that can last for ages. Be careful though, as it also
> means that clients who don't receive the last packet of a connection
> might get a RST when asking for it again because the kernel will not
> buffer data longer than the socket's life.
>
> Regards,
> Willy
>
>
Received on 2010/04/27 23:54