Re: backend has no server available!

Dhaval, What I put in my resolvers is the EC2 instance subnet dns server which for EC2 is always the second IP of the subnet range, xxx.xxx.xxx..2 You can also find this IP in your /etc/resolv.conf on the haproxy instances. Try replacing ​ 169.254.169.253:53 with that value and see how you go.

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

William, Am 14.11.2017 um 15:03 schrieb William Lallemand: > Well, in my opinion the return value does not need to be checked because we > should never reach the code after the exec, that means that the code after the > exec is only reached during an exec error. But we could at least display the

Re: backend has no server available!

Even after reducing "hold valid" to 1s shows the same behavior. One more observation is that after introducing ELB in haproxy config, site seems to have little late response. Provided link is helpful, however if any one face same issue or can share experience to solve it will be really helpful.

Re: Websocket metrics

Hi Claus Below is a blog on the haproxy website about websockets, I apologies if it does not have the information you need https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/ Andruw Smalley Loadbalancer.org Ltd. www.loadbalancer.org +1 888 867 9504 / +44 (0)330 380 1064

Websocket metrics

Hi, I'm looking for recommendations on best practices for collecting metrics and performing analytics on websocket connections through HAProxy. I'm already capturing the http log which serves me well for http traffic, but since websockets get upgraded to TCP connections I'm losing the kind of

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

On Tue, Nov 14, 2017 at 03:03:20PM +0100, William Lallemand wrote: > Willy, could you please apply this patch? thanks OK now done, thanks guys. Willy

Re: [PATCH] BUG/MEDIUM: mworker: Fix re-exec when haproxy is started from PATH

Hi Tim, On Sun, Nov 12, 2017 at 05:39:18PM +0100, Tim Düsterhus wrote: > From: Tim Duesterhus > > If haproxy is started using the name of the binary only (i.e. > not using a relative or absolute path) the `execv` in > `mworker_reload` fails with `ENOENT`, because it does not