Definitely haproxy process, nothing else runs on there and the older version
remains stable for days/weeks:
F S UIDPID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
1 S nobody 15547 1 18 80 0 - 1026097 epoll_ 10:54 ? 00:54:30
/usr/sbin/haproxy14d5 -D -f
On 2010-01-06 00:44, Willy Tarreau wrote:
Hi Krzysztof,
Hi Willy,
I've merged all of your patches.
Thanks.
However I have a minor concern
about something in this one :
-The currently supported settings are the following ones.
+The currently supported settings are the following ones, the
From 7046fe6b5245deb06f760896fa7e10c2163eda60 Mon Sep 17 00:00:00 2001
From: Krzysztof Piotr Oledzki o...@ans.pl
Date: Wed, 6 Jan 2010 15:03:18 +0100
Subject: [BUG] stats: cookie should be reported under backend not under proxy
---
src/dumpstats.c | 29 -
1 files
From 0d95cf9f607de59487c644af3077be1a84eb4b81 Mon Sep 17 00:00:00 2001
From: Krzysztof Piotr Oledzki o...@ans.pl
Date: Wed, 6 Jan 2010 16:25:05 +0100
Subject: [BUG] cfgparser/stats: fix error message
Fix the error message by unification and goto, previously we had
two independent lists of
I sent this out yesterday (1/5/2010) but didn't see it come back to me
on the list, nor do I see it in the mailing list archives at
http://www.formilux.org/archives/haproxy/1001/date.html so I'm trying
again. The other msg I sent yesterday (about Retries/Option Dispatch)
did make it to the list
Busy little haproxy beaver today :)
The docs under retries says if a connection attempt fails, it waits
one second, and then tries again. I was wondering how (if at all)
that works in conjunction with timeout connect, which is how long
haproxy waits to try to connect to a backend server. Is the
Le Mardi 5 Janvier 2010 23:42:46, Willy Tarreau a écrit :
On Tue, Jan 05, 2010 at 11:14:32PM +0100, Cyril Bonté wrote:
Well, eventually after several different tests, that's OK for me.
A short http-request timeout (some seconds max) will prevent the
accumulation of connections ESTABLISHED
Hi Cyril,
On Wed, Jan 06, 2010 at 08:58:17PM +0100, Cyril Bonté wrote:
Le Mardi 5 Janvier 2010 23:42:46, Willy Tarreau a écrit :
On Tue, Jan 05, 2010 at 11:14:32PM +0100, Cyril Bonté wrote:
Well, eventually after several different tests, that's OK for me.
A short http-request timeout
displays the listener address and port instead of its id.
See the patch in attachment if it's OK for you (done with the 20100106
snapshot) ;)
Good Idea!
However, the same functionality is provided by very recently introduced
stats show-legends option, but you need to enable it explicitly. I
didn't
, NULL);
src/checks.c:
set_server_check_status(s, HCHK_STATUS_SOCKERR, NULL);
Could you please try to change the second NULL to strerror(errno)?
I've made that patch. I am using 1.4-dev5.tar.gz, but not the snaphot
from 1.4-ss-20100106.tar.gz. With your three strerror(errno) patches
in, I am now
haproxy process running, processing one very long request. I run
another haproxy -sf, which does the whole reload, etc stuff. The long
request (ldap database query) continues on its way. :) So that's good
:)
But I thought the old process would stick around until that entire
request was done,
think it can be very helpful for diagnostics if the auto-calcultated
listener name displays the listener address and port instead of its id.
See the patch in attachment if it's OK for you (done with the 20100106
snapshot) ;)
Good Idea!
However, the same functionality is provided by very
, HCHK_STATUS_SOCKERR, NULL);
Could you please try to change the second NULL to strerror(errno)?
I've made that patch. I am using 1.4-dev5.tar.gz, but not the snaphot
from 1.4-ss-20100106.tar.gz. With your three strerror(errno) patches
in, I am now seeing a bit more info in my /var/log/messages
Hi All
I was wondering if the HA Proxy's Balancing Mechanism be called a NAT
Mechanism, because it's masking the servers' IP addresses, and then route
the traffic to the location.
because i was just discussing with my colleague, and my argument is that:
it's only a proxy which in between two pc
14 matches
Mail list logo
