Re: haproxy & websockets

Actually, I spoke too soon. When I create a config similar to Laurie's (see below), I find that I still don't see headers and my default backend is always utilized. I originally mistook this for working. Laurie, are you positive you are actually routing traffic based on the hdr rule? This implies to me the default is tcp? When I explicitly declare mode http in the backends, the client never sees the response, as I mentioned in the first email.

haproxy.cfg:
global
  maxconn 4096
  user nobody
  group nobody

  #chroot /var/run/haproxy_jail

defaults
  retries 3
  maxconn 2000
  contimeout 5000
  clitimeout 50000
  srvtimeout 50000

frontend ws_in
  bind *:80
  acl is_lists hdr_end(host) -i lists.asana.com   acl is_beta hdr_end(host) -i beta.asana.com

  use_backend beta_ws if is_beta
  use_backend lists_ws if is_lists
  default_backend ws

backend ws
  option tcplog

  log /dev/log local0 debug

  balance leastconn
  server ws_0 prod_ws0.ec2.:8080 check
  server ws_1 prod_ws1.ec2.:8080 check

backend beta_ws
  option tcplog

  log /dev/log local0 debug

  balance leastconn
  server beta_ws_0 beta_ws0.ec2.:8080 check

backend lists_ws
  option tcplog

  log /dev/log local0 debug

  balance leastconn
  server ws_2 prod_ws2.ec2.:8080 check
  server ws_3 prod_ws3.ec2.:8080 check

listen stats 0.0.0.0:8090
  mode http
  stats enable
  stats uri /haproxy
  stats refresh 5s

On Tue, Apr 27, 2010 at 5:11 PM, Dustin Moskovitz <moskov#asana.com> wrote:

> Yea, this was due to a failure to clean between builds, sorry about that. I
> think we've got what we need now, thanks!
>
>
> On Tue, Apr 27, 2010 at 3:11 PM, Willy Tarreau <w#1wt.eu> wrote:
>
>> On Tue, Apr 27, 2010 at 02:54:24PM -0700, Dustin Moskovitz wrote:
>> > 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.
>>
>> First, depending on the system you'll use it on, you could get better
>> performance. On Linux, use "TARGET=linux26" to get support for epoll(),
>> and on FreeBSD/OpenBSD, use the appropriate makefile to get support for
>> kqueue().
>>
>> > [ALERT] 116/214946 (671) : socket for logger #1 failed: Address family
>> not
>> > supported by protocol (errno=97)
>>
>> Huh ? It's the first time I ever see that ! Looks like you can't
>> create a UDP socket to send your logs ! Did you perform a "make clean"
>> before rebuilding ? It is possible that some struct members have moved
>> between the two versions and that you rebuilt without replacing all of
>> your .o files.
>>
>> > Requests just seem to hang from the client's perspective and I don't see
>> > anything on the console indicating they are being handled.
>>
>> Depending on the reason for the anomaly above, it could be anything. It's
>> possible that the process is spinning or waiting forever or doing anything
>> stupid.
>>
>> > 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?
>>
>> No, there is no reason for this. And you would not get such a strange
>> message anyway. If you want, you can send me your config in private,
>> I'll retry here, just in case. If I can reproduce, whatever the reason
>> we have to work on it so that either it cannot happen anymore or at least
>> there are indications of the reason !
>>
>> Regards,
>> Willy
>>
>>
>
Received on 2010/04/28 02:36