RE: Issues with stats logging
Hi Willy, Thanx for your suggestion, I moved httplog to appropriate sections and warning is gone. I do have keep-alive enabled at client side and now that you say I recall that while upgrading haproxy I increased the 'timeout client' from 10s to 5m because of some remote clients with very slow connections. I am pretty sure you are right that's the problem but I will check it tonight and let you know for sure. Btw, I am unable to figure out how 'grace' option works. Looking at the sources it seems it is 0 by default which shall effectively disable soft-stop but apparently it doesn't. How does it work then? Kind regards, Hristo -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Wednesday, June 16, 2010 8:00 AM To: Христо Красимиров Григоров Cc: haproxy@formilux.org Subject: Re: Issues with stats logging Hi Hristo, On Wed, Jun 16, 2010 at 06:36:59AM +0300, grigorov.hrist...@neftochim.bg wrote: Thanx Willy, About the second issue... I didn't notice 'log global' can be specified for specific listen thus I had it in defaults section. I moved it to the one of the listeners and now everything seems fine, just that warning which is actually good as it reminds of possible config problem: [WARNING] 166/062459 (12999) : config : log format ignored for proxy 'stats' since it has no log address. This is because of option httplog in your defaults section. You should move it to the sections you that want to log (the same as the ones which have log global). Btw, I upgraded to 1.4.7 and using the provided init script, haproxy no longer shutdowns properly on my system. Signal USR1 is sent, it logs that it shuts down but the process remains active. I assume it must be a problem of my system (Linux 2.6) unless someone else confirms the same? I don't see why this could be caused by your system, and I really don't like this type of behaviour at all. I've checked the changes and I see nothing that could cause that. I've tried here too and I cannot reproduce the issue. Normally, the old process remains alive as long as it has established connections. You could check these connections with netstat -atnp. Do you have keep-alive enabled on the client side, with a browser that might keep a connection for a long time ? By default if not specified, the timeout http-keep-alive is equal to timeout client which might be long. You can also ask haproxy to report you the connection it sees. For this you have to enable the stats socket in the global section : stats socket /var/run/haproxy.sock level admin Then once you have sent your SIGUSR1, you can check what connection it sees : # printf show sess\r\n | socat stdio unix-connect:/var/run/haproxy.sock 0x80c8590: proto=tcpv4 src=127.0.0.1:57092 fe=echo1 be=echo1 srv=none ts=0a age=26s calls=1 rq[f=501000h,l=0,an=0eh,rx=24s,wx=,ax=] rp[f=001000h,l=0,an=00h,rx=,wx=,ax=] s0=[7,18h,fd=6,ex=] s1=[0,0h,fd=-1,ex=] exp=24s 0x80cca80: proto=unix_stream ts=09 age=0s calls=2 rq[f=d09200h,l=0,an=00h,rx=10s,wx=,ax=] rp[f=008002h,l=219,an=00h,rx=,wx=,ax=] s0=[7,8h,fd=4,ex=] s1=[7,0h,fd=-1,ex=] exp=10s = the first line is a TCP connection which has been there for 26 second and will expire in 24 seconds. The second line is just your connection on the socket using socat. Please keep me informed if you can reliably reproduce the issue, as well as if you find this is just caused by too long keep-alive connections. Regards, Willy
Can't get stick match src to work, what am I doing wrong?
Hi guys, I am using haproxy 1.4.7 and I cannot get stick on src to work. It appears to be ignoring my sticky src. I am using a vanilla haproxy. When I use curl to visit my configured proxy I am always cycled to a new server, each time I hit the page. If src stickiness was working I would expect to always connect to the same backend server. I've attached my configuation below, any help would be super appreciated. Thanks again, Ben #configuration below: defaults log global modehttp option httplog retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 5 srvtimeout 5 listen appli1-rewrite 0.0.0.0:10001 modetcp balance roundrobin stick-table type ip size 200k expire 20m stick store-request src stick match src server app1_1 127.0.0.1:80 id 1 server app1_2 127.0.0.1:81 id 2 server app1_3 127.0.0.1:82 id 3 server app1_4 127.0.0.1:83 id 4
Re: Issues with stats logging
On Wed, Jun 16, 2010 at 09:20:44AM +0300, grigorov.hrist...@neftochim.bg wrote: Btw, I am unable to figure out how 'grace' option works. Looking at the sources it seems it is 0 by default which shall effectively disable soft-stop but apparently it doesn't. How does it work then? It was used a long time ago to keep the listen active during that time after the USR1 signal even if there was no traffic. The idea was to make some instances go down immediately so that external components could detect them, and have the other ones remain active so that we would be sure the instances were detected as failed. It's no longer used now that we have the soft restart. Willy
haproxy 1.4.7 segfaults under load around 1k connections
Hi there We have been running haproxy 1.4.1 perfectly fine without any problems for several months. Today haproxy started crashing with the following message in /var/log/messages: Jun 16 13:26:21 lb2 kernel: [ 3352.666283] haproxy[4679]: segfault at 8 ip 0043e462 sp 7fff0dac92c8 error 4 in haproxy[40+54000] I tried upgrading to 1.4.7 with no luck. We primarily use haproxy for TCP load balancing of SMTP, RPC (Exchange 2010) and RDP. The load might have increased slightly the last few days, and this might be what triggers it. Initially I suspected it was because of only 512 MB RAM had been assigned to the machine (running x86_64 SuSE on ESX), so I increased that to 1GB. Also ulimit -n showed 1024, so I increased that to 32768 and sysctl fs.file-max = 65535 - that didn't seem to do any difference. Also tried to disable some logging, just to see if that had anything to do with it. It seems to crash everytime the total connection count gets around 800-1000... lb2:~ # uname -a Linux lb2 2.6.31.12-0.1-default #1 SMP 2010-01-27 08:20:11 +0100 x86_64 x86_64 x86_64 GNU/Linux lb2:~ # haproxy -vv HA-Proxy version 1.4.7 2010/06/07 Copyright 2000-2010 Willy Tarreau w...@1wt.eumailto:w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -O2 -g OPTIONS = USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Available polling systems : sepoll : pref=400, test result OK epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 4 (4 usable), will use sepoll. ## gdb session # lb2:/usr/local/sbin # gdb ./haproxy GNU gdb (GDB) SUSE (6.8.91.20090930-2.4) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-suse-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/sbin/haproxy...done. (gdb) run -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -db Starting program: /usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -db Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 Try: zypper install -C debuginfo(build-id)=591af1afa33f255704fb6a60859b93d00e205302 Missing separate debuginfo for /lib64/libcrypt.so.1 Try: zypper install -C debuginfo(build-id)=b4127c6e9abfb7711018173fc6010b5853a5a781 Missing separate debuginfo for /lib64/libpcreposix.so.0 Try: zypper install -C debuginfo(build-id)=89f575b0c91220f553dff19b0f5d8ac786cf3e21 Missing separate debuginfo for /lib64/libpcre.so.0 Try: zypper install -C debuginfo(build-id)=faf1aba9b565a29c99ce1d3944978347d6209cc3 Missing separate debuginfo for /lib64/libc.so.6 Try: zypper install -C debuginfo(build-id)=b5ded0f18b9b11c5cd6b26387426ead562c332f8 Program received signal SIGSEGV, Segmentation fault. eb32_lookup_ge (root=0x656df0, x=2160585045) at ebtree/eb32tree.c:212 212 troot = (eb_untag(troot, EB_LEFT))-b[EB_RGHT]; (gdb) (gdb) bt #0 eb32_lookup_ge (root=0x656df0, x=2160585045) at ebtree/eb32tree.c:212 #1 0x004080de in process_runnable_tasks (next=0x7fffe64c) at src/task.c:206 #2 0x00402829 in run_poll_loop () at src/haproxy.c:966 #3 0x0040426f in main (argc=value optimized out, argv=0x7fffe788) at src/haproxy.c:1240 (gdb) list 207 while (eb_gettag(troot) != EB_LEFT) 208 /* Walking up from right branch, so we cannot be below root */ 209 troot = (eb_root_to_node(eb_untag(troot, EB_RGHT)))-node_p; 210 211 /* Note that troot cannot be NULL at this stage */ 212 troot = (eb_untag(troot, EB_LEFT))-b[EB_RGHT]; 213 if (eb_clrtag(troot) == NULL) 214 return NULL; 215 216 node = eb32_entry(eb_walk_down(troot, EB_LEFT), struct eb32_node, node); ## /etc/haproxy/haproxy.cfg ## global log 127.0.0.1 local0 #log 127.0.0.1 local1 notice #log netwatch local0 info maxconn 5000 #chroot /usr/share/haproxy stats socket /var/run/haproxy.stat mode 600 user haproxy group haproxy daemon #debug #quiet defaults log global modehttp option dontlognull option redispatch retries 3 maxconn 5000 timeout connect 5000 timeout client 5 timeout server 5 # Axapta Terminal Services listen AXTS_rdp 10.131.25.20:3389 mode tcp balance roundrobin option tcpka #option tcplog timeout connect 10s timeout client 3h timeout server 3h monitor-net 10.131.25.62/32 server axts1 10.131.25.21 weight 1 check server axts2 10.131.25.22 weight 1 check # CAS HTTP balancing listen CAS_http 10.131.25.75:80 mode http balance source option httplog option httpclose option forwardfor monitor-net 10.131.25.62/32 server cas1 10.131.25.73 weight 1 check
Re: haproxy 1.4.7 segfaults under load around 1k connections
Hi again Just an update on this issue. I had it crash instantly by telnetting on the CAS_smtp listener port from the host defined in the monitor-net option. It connects and then instantly disconnects without being load-balanced (which is expected behaviour for the monitor-net host). The problem is that haproxy segfaults right after - or maybe after 4-5 tries. If I remove the monitor-net option in the listener section it stops crashing. vr was very helpful in #hapr...@irc.gnu.org and he was able to replicate the error. - Thanks vr!! -- Med venlig hilsen Fleggaard IT Morten Gade Sørensen Network Engineer Tlf: +45 7230 3999 Fax: +45 7230 3998 Mail: m...@fleggaard.dkx-msg://16/m...@fleggaard.dk Web: www.fleggaard-holding.dkx-msg://16/www.fleggaard-holding.dk On 16/06/2010, at 13.57, Morten Gade Sørensen wrote: Hi there We have been running haproxy 1.4.1 perfectly fine without any problems for several months. Today haproxy started crashing with the following message in /var/log/messages: Jun 16 13:26:21 lb2 kernel: [ 3352.666283] haproxy[4679]: segfault at 8 ip 0043e462 sp 7fff0dac92c8 error 4 in haproxy[40+54000] I tried upgrading to 1.4.7 with no luck. We primarily use haproxy for TCP load balancing of SMTP, RPC (Exchange 2010) and RDP. The load might have increased slightly the last few days, and this might be what triggers it. Initially I suspected it was because of only 512 MB RAM had been assigned to the machine (running x86_64 SuSE on ESX), so I increased that to 1GB. Also ulimit -n showed 1024, so I increased that to 32768 and sysctl fs.file-max = 65535 - that didn't seem to do any difference. Also tried to disable some logging, just to see if that had anything to do with it. It seems to crash everytime the total connection count gets around 800-1000... lb2:~ # uname -a Linux lb2 2.6.31.12-0.1-default #1 SMP 2010-01-27 08:20:11 +0100 x86_64 x86_64 x86_64 GNU/Linux lb2:~ # haproxy -vv HA-Proxy version 1.4.7 2010/06/07 Copyright 2000-2010 Willy Tarreau w...@1wt.eumailto:w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -O2 -g OPTIONS = USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Available polling systems : sepoll : pref=400, test result OK epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 4 (4 usable), will use sepoll. ## gdb session # lb2:/usr/local/sbin # gdb ./haproxy GNU gdb (GDB) SUSE (6.8.91.20090930-2.4) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-suse-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/sbin/haproxy...done. (gdb) run -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -db Starting program: /usr/local/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -db Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 Try: zypper install -C debuginfo(build-id)=591af1afa33f255704fb6a60859b93d00e205302 Missing separate debuginfo for /lib64/libcrypt.so.1 Try: zypper install -C debuginfo(build-id)=b4127c6e9abfb7711018173fc6010b5853a5a781 Missing separate debuginfo for /lib64/libpcreposix.so.0 Try: zypper install -C debuginfo(build-id)=89f575b0c91220f553dff19b0f5d8ac786cf3e21 Missing separate debuginfo for /lib64/libpcre.so.0 Try: zypper install -C debuginfo(build-id)=faf1aba9b565a29c99ce1d3944978347d6209cc3 Missing separate debuginfo for /lib64/libc.so.6 Try: zypper install -C debuginfo(build-id)=b5ded0f18b9b11c5cd6b26387426ead562c332f8 Program received signal SIGSEGV, Segmentation fault. eb32_lookup_ge (root=0x656df0, x=2160585045) at ebtree/eb32tree.c:212 212 troot = (eb_untag(troot, EB_LEFT))-b[EB_RGHT]; (gdb) (gdb) bt #0 eb32_lookup_ge (root=0x656df0, x=2160585045) at ebtree/eb32tree.c:212 #1 0x004080de in process_runnable_tasks (next=0x7fffe64c) at src/task.c:206 #2 0x00402829 in run_poll_loop () at src/haproxy.c:966 #3 0x0040426f in main (argc=value optimized out, argv=0x7fffe788) at src/haproxy.c:1240 (gdb) list 207 while (eb_gettag(troot) != EB_LEFT) 208 /* Walking up from right branch, so we cannot be below root */ 209 troot = (eb_root_to_node(eb_untag(troot, EB_RGHT)))-node_p; 210 211 /* Note that troot cannot be NULL at this stage */ 212 troot = (eb_untag(troot, EB_LEFT))-b[EB_RGHT]; 213 if (eb_clrtag(troot) == NULL) 214 return NULL; 215 216 node = eb32_entry(eb_walk_down(troot, EB_LEFT), struct eb32_node, node); ## /etc/haproxy/haproxy.cfg ## global log 127.0.0.1 local0
Re: Fwd: load balancing RPC server
Thank you for confirming. Yeah, I notice the two balance line. I think this could be the server side since it might be expecting a rpc open/close specific to the protocol. Now let me change to a different question :-). If I want to use a different port for health check and route the traffic to the actual port. How do I set the config? Appreciate your help. On Tue, Jun 15, 2010 at 10:21 PM, Willy Tarreau w...@1wt.eu wrote: Hi, On Tue, Jun 15, 2010 at 02:47:06PM -0700, Qiwen Zhao wrote: Hi, First, I want to Thank you for HAProxy, it is great! I have been using it for http load balance, works very well. I have some newbie questions on load balancing non-http RPC servers. The problem I am running into is the HAProxy will keep ping the server, server open new connection, but does not close them. I must be missing something obvious. Are you talking about the health checks ? If so, I'm pretty sure they *do* close the connections ! And in your case, since you're running with pure TCP checks, the connection will close as soon as it's established. If you take a network capture, you should see this : haproxy server SYN --- - SYN/ACK -- ACK --- FIN --- --- FIN ACK --- Be careful, you have two balance methods in your config below, only the last one is used : *backend 9876_wave_server* * balance leastconn* * mode tcp* * balance roundrobin* * server wave1 localhost:9871 check inter 3000 rise 2 fall 2 weight 1 * server wave2 localhost:9872 check inter 3000 rise 2 fall 2 weight 1 Regards, Willy
Re: Can't get stick match src to work, what am I doing wrong?
Hello Ben,
As discussed on IRC channel, you spot a regression on stick-table
introduced in 1.4.7, Willy send me the patch that fix that.
When you came back from sleeping, can you tell me if it works for you ?
(btw it works for me :))
Hervé.
On 06/16/2010 09:17 AM, Ben Congleton wrote:
Hi guys,
I am using haproxy 1.4.7 and I cannot get stick on src to work. It
appears to be ignoring my sticky src. I am using a vanilla haproxy.
When I use curl to visit my configured proxy I am always cycled to a
new server, each time I hit the page. If src stickiness was working I
would expect to always connect to the same backend server.
I've attached my configuation below, any help would be super appreciated.
Thanks again,
Ben
--
Your Network supports your *BUSINESS !*
Appliances de *contrôle d'activité* et d'*optimisation* du réseau
EXCELIANCE - Rule your Network ! - www.exceliance.fr
ZAC des Metz - 3 Rue du petit robinson
78350 Jouy en Josas
Tél: +33 1 30 67 60 74 - Fax: +33 1 75 43 40 70
From 0d91af355b9a9b83f9e31b54e9f734efb5c81cb3 Mon Sep 17 00:00:00 2001
From: Willy Tarreau w...@1wt.eu
Date: Wed, 16 Jun 2010 16:01:24 +0200
Subject: [BUG] stick_table: the fix for the memory leak caused a regression
Commit d6e9e3b5e320b957e6c491bd92d91afad30ba638 caused recently created
entries to be removed as soon as they were created, breaking stickiness.
It is not clear whether a use-after-free was possible or not in this case.
---
src/session.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/session.c b/src/session.c
index dc2babe..5d089b2 100644
--- a/src/session.c
+++ b/src/session.c
@@ -802,11 +802,12 @@ int process_store_rules(struct session *s, struct buffer
*rep, int an_bit)
/* process store request and store response */
for (i = 0; i s-store_count; i++) {
- if (stktable_store(s-store[i].table, s-store[i].ts,
s-srv-puid) 0) {
+ if (stktable_store(s-store[i].table, s-store[i].ts,
s-srv-puid) 0)
stksess_free(s-store[i].table, s-store[i].ts);
- s-store[i].ts = NULL;
- }
+ /* always remove pointer to session to ensure we won't free it
again */
+ s-store[i].ts = NULL;
}
+ s-store_count = 0; /* everything is stored */
rep-analysers = ~an_bit;
rep-analyse_exp = TICK_ETERNITY;
--
1.6.0.4
Re: Fwd: load balancing RPC server
On Wed, Jun 16, 2010 at 08:00:44AM -0700, Qiwen Zhao wrote: Thank you for confirming. Yeah, I notice the two balance line. I think this could be the server side since it might be expecting a rpc open/close specific to the protocol. Now let me change to a different question :-). Maybe, but it should not keep a closed connection open anyway, otherwise it will regularly end up with massive CLOSE_WAIT sockets and a shortage of file descriptors. If I want to use a different port for health check and route the traffic to the actual port. How do I set the config? Simply add the port parameter on the server lines. You can even force a different address if you like, using addr X. Regards, Willy
Re: Fwd: load balancing RPC server
Maybe, but it should not keep a closed connection open anyway, otherwise it will regularly end up with massive CLOSE_WAIT Yeah, that is exactly what is happening. Simply add the port parameter on the server lines. You can even force a different address if you like, using addr X. Great. I will play with that. Thank you! Regards, Willy
Re: haproxy 1.4.7 segfaults under load around 1k connections
Hello mgades,
Willy send me the patch who fix this bug.
It is good for me, can you test it on your configuration ?
On 06/16/2010 03:16 PM, Morten Gade Sørensen wrote:
Hi again
Just an update on this issue.
I had it crash instantly by telnetting on the CAS_smtp listener port
from the host defined in the monitor-net option.
It connects and then instantly disconnects without being load-balanced
(which is expected behaviour for the monitor-net host).
The problem is that haproxy segfaults right after - or maybe after 4-5
tries.
If I remove the monitor-net option in the listener section it stops
crashing.
vr was very helpful in #hapr...@irc.gnu.org and he was able to
replicate the error. - Thanks vr!!
You're welcome. :)
Hervé.
--
Your Network supports your *BUSINESS !*
Appliances de *contrôle d'activité* et d'*optimisation* du réseau
EXCELIANCE - Rule your Network ! - www.exceliance.fr
ZAC des Metz - 3 Rue du petit robinson
78350 Jouy en Josas
Tél: +33 1 30 67 60 74 - Fax: +33 1 75 43 40 70
From 7ec37ed4e0b24535cd20e12ac2b3774b128f6875 Mon Sep 17 00:00:00 2001
From: Willy Tarreau w...@1wt.eu
Date: Wed, 16 Jun 2010 17:17:39 +0200
Subject: [BUG] client: don't add a new session to the list too early
Adding a new session to the sessions list too early can cause it to
indefinitely remain in the list if a request from a monitor-net comes
in TCP mode, because the session will then not be removed from the
list. This issue causes crashes very soon after when this happens.
It should be backported to 1.3 too.
---
src/client.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/client.c b/src/client.c
index be0c902..476ad9f 100644
--- a/src/client.c
+++ b/src/client.c
@@ -126,7 +126,6 @@ int event_accept(int fd) {
goto out_close;
}
- LIST_ADDQ(sessions, s-list);
LIST_INIT(s-back_refs);
s-flags = 0;
@@ -146,6 +145,8 @@ int event_accept(int fd) {
s-flags |= SN_MONITOR;
}
+ LIST_ADDQ(sessions, s-list);
+
if ((t = task_new()) == NULL) { /* disable this proxy for a
while */
Alert(out of memory in event_accept().\n);
EV_FD_CLR(fd, DIR_RD);
--
1.6.0.4
Re: haproxy 1.4.7 segfaults under load around 1k connections
Hi Hervé I have applied the patch, and it seems to do the trick - thanks Hervé/Willy. -- Med venlig hilsen Fleggaard IT Morten Gade Sørensen Network Engineer Tlf: +45 7230 3999 Fax: +45 7230 3998 Mail: m...@fleggaard.dkx-msg://16/m...@fleggaard.dk Web: www.fleggaard-holding.dkx-msg://16/www.fleggaard-holding.dk On 16/06/2010, at 18.27, Hervé COMMOWICK wrote: Hello mgades, Willy send me the patch who fix this bug. It is good for me, can you test it on your configuration ? On 06/16/2010 03:16 PM, Morten Gade Sørensen wrote: Hi again Just an update on this issue. I had it crash instantly by telnetting on the CAS_smtp listener port from the host defined in the monitor-net option. It connects and then instantly disconnects without being load-balanced (which is expected behaviour for the monitor-net host). The problem is that haproxy segfaults right after - or maybe after 4-5 tries. If I remove the monitor-net option in the listener section it stops crashing. vr was very helpful in #hapr...@irc.gnu.org and he was able to replicate the error. - Thanks vr!! You're welcome. :) Hervé. -- Your Network supports your *BUSINESS !* Appliances de *contrôle d'activité* et d'*optimisation* du réseau EXCELIANCE - Rule your Network ! - www.exceliance.frhttp://www.exceliance.fr/ ZAC des Metz - 3 Rue du petit robinson 78350 Jouy en Josas Tél: +33 1 30 67 60 74 - Fax: +33 1 75 43 40 70 0001--BUG-client-don-t-add-a-new-session-to-the-list-to.patch
Re: Can't get stick match src to work, what am I doing wrong?
Patch worked, Thanks for your help Hervé When do you think 1.4.7 will be truely stable :-) -Ben 2010/6/16 Hervé COMMOWICK hcommow...@exceliance.fr: Hello Ben, As discussed on IRC channel, you spot a regression on stick-table introduced in 1.4.7, Willy send me the patch that fix that. When you came back from sleeping, can you tell me if it works for you ? (btw it works for me :)) Hervé. On 06/16/2010 09:17 AM, Ben Congleton wrote: Hi guys, I am using haproxy 1.4.7 and I cannot get stick on src to work. It appears to be ignoring my sticky src. I am using a vanilla haproxy. When I use curl to visit my configured proxy I am always cycled to a new server, each time I hit the page. If src stickiness was working I would expect to always connect to the same backend server. I've attached my configuation below, any help would be super appreciated. Thanks again, Ben -- Your Network supports your *BUSINESS !* Appliances de *contrôle d'activité* et d'*optimisation* du réseau EXCELIANCE - Rule your Network ! - www.exceliance.fr ZAC des Metz - 3 Rue du petit robinson 78350 Jouy en Josas Tél: +33 1 30 67 60 74 - Fax: +33 1 75 43 40 70
share number of backend-server-connections among backend configurations
Hi, I have some backend-servers (eg A and B) in multiple backends (B has some special sites running that's why). Algorithm is least connection. But the information about the number of active connections is not shared between the backend configurations, even though servers have the same name. So if A has 10 connections in backend TWO, backend ONE will still see A as unused with 0 connections. Using the least connection algorithm I would wish that connection numbers are counted overall. Sample configuration frontend myfrontend *:80 acl acl_site1 url_sub use_backend TWO if acl_site1 default_backend ONE backend ONE server A ... server B ... backend TWO server A ... What can I do to use the least conn algorithm in this setup? Thank you! Martin
[ANNOUNCE] haproxy 1.4.8
Hi, today, Ben Congleton, Morten Gade Sørensen and Hervé Commowick reported and diagnosed two bugs in 1.4.7. One was a regression introduced in 1.4.7, breaking the stick-table feature due to a side effect of the fix for a memory leak in it. The second one is quite old, it dates 1.3.16 ! It causes crashes soon after a connection has matched a monitor-net in a tcp-only instance. I wanted to quickly fix both issues so that users who have not yet upgraded to 1.4.7 don't waste their time, and I'm very grateful to the 3 guys above who were extremely reactive and allowed the bugs to be fixed in a few hours. And yes, despite these few bugs, 1.4 is quite stable. I'm not much worried by regressions caused by incomplete fixes and which are spotted and fixed within one week, nor am I with features that remained unusable for 2 years and that nobody seemed to be using ;-) I'll send a separate announcement for the 1.3 version. I tool this opportunity to also merge Pierre Mézard's doc fixes and updates. The usual builds are available there along with the sources : site index : http://haproxy.1wt.eu/ sources: http://haproxy.1wt.eu/download/1.4/src/ changelog : http://haproxy.1wt.eu/download/1.4/src/CHANGELOG binaries : http://haproxy.1wt.eu/download/1.4/bin/ Willy
