[PATCH 5/5] [MINOR] Add down termination condition

If a connection is closed by because the backend became unavailable then log 'D' as the termination condition. Signed-off-by: Simon Horman ho...@verge.net.au --- include/types/session.h |3 ++- src/checks.c|1 + src/log.c |2 +- 3 files changed, 4

[PATCH 3/5] [MINOR] Add active connection list to server

The motivation for this is to allow iteration of all the connections of a server without the expense of iterating over the global list of connections. The first use of this will be to implement an option to close connections associated with a server when is is marked as being down or in

[PATCH 4/5] [MINOR] Allow shutdown of sessions when a server becomes unavailable

--- v2 * Iterate per-server session list instead of global session list in shutdown_sessions() * Set nice level of tasks of sessions to be closed to 1024 * Use TASK_WOKEN_OTHER instead of TASK_WOKEN_RES in shutdown_sessions() As suggested by Willy Tarreau * Use list_for_each_entry_safe()

[PATCH 1/5] [CLEANUP] peers.h: fix declarations

* The declaration of peer_session_create() does not match its definition. As it is only used inside of peers.c make it static. * Make the declaration of peers_register_table() match its definition. * Also, make all functions in peers.c that are not also in peers.h static ---

[PATCH v3 0/4] Allow shutdown of sessions when a server becomes unavailable

Hi, this is v3 of this series which adds an option to allow connections to be closed if their backend becomes unavailable. Changes since v2 are: [PATCH 4/5] [MINOR] Allow shutdown of sessions when a server becomes * Rename server element of session as by_srv * Don't close sessions unless

[PATCH 2/5] [CLEANUP] session.c: Make functions static where possible

--- include/proto/session.h |3 +- src/session.c | 68 +++--- 2 files changed, 35 insertions(+), 36 deletions(-) diff --git a/include/proto/session.h b/include/proto/session.h index 15f3fe7..c9195f6 100644 --- a/include/proto/session.h +++

Strange problem with haproxy

Hi all, At the moment I am evaluating haproxy as a reverse proxy. Everything seems to work great except one thing and I do not know where is the problem. The situations in which I get the problem is the following: 1. client uploads big file to the haproxy 2. all incoming data seems to be sent

Re: [PATCH v3 0/4] Allow shutdown of sessions when a server becomes unavailable

Hi Simon, On Tue, Jun 21, 2011 at 02:34:54PM +0900, Simon Horman wrote: Hi, this is v3 of this series which adds an option to allow connections to be closed if their backend becomes unavailable. Changes since v2 are: [PATCH 4/5] [MINOR] Allow shutdown of sessions when a server becomes

Re: Strange problem with haproxy

On Tue, Jun 21, 2011 at 04:23:52PM +0200, Galfy Pundee wrote: Hi all, At the moment I am evaluating haproxy as a reverse proxy. Everything seems to work great except one thing and I do not know where is the problem. The situations in which I get the problem is the following: 1. client

haproxy start problem

hello list.. for some reason I broke my config when I tried to move the web servers out of the wrong group and into the right one..I was hoping I could get your opinion on this. ## machine info [root@VIRTCENT01:~] #cat /etc/redhat-release CentOS release 5.5 (Final) [root@VIRTCENT01:~]

halog assitance

I'm in the process of trying to debug a somewhat sluggish set of backends. The backends are ~20 python tornado web servers that implement a simple blocking db call to mongodb. I would theorize that the request rate can overload the number of backends and their ability to service periodically when

Re: haproxy start problem

Hello Tim, On Tue, Jun 21, 2011 at 08:55:11PM -, Tim Dunphy wrote: hello list.. for some reason I broke my config when I tried to move the web servers out of the wrong group and into the right one..I was hoping I could get your opinion on this. ## haproxy version

Re: halog assitance

Hi David, On Tue, Jun 21, 2011 at 02:04:50PM -0700, David Birdsong wrote: I'm in the process of trying to debug a somewhat sluggish set of backends. The backends are ~20 python tornado web servers that implement a simple blocking db call to mongodb. I would theorize that the request rate can

[PATCH v4 0/5] Allow shutdown of sessions when a server becomes unavailable

Hi, this is v3 of this series which adds an option to allow connections to be closed if their backend becomes unavailable. Changes: v4: [PATCH 5/5] [MINOR] Add down termination condition * Add documentation v3: [PATCH 4/5] [MINOR] Allow shutdown of sessions when a server becomes * Rename

[PATCH 2/5] [CLEANUP] session.c: Make functions static where possible

--- include/proto/session.h |3 +- src/session.c | 68 +++--- 2 files changed, 35 insertions(+), 36 deletions(-) diff --git a/include/proto/session.h b/include/proto/session.h index 15f3fe7..c9195f6 100644 --- a/include/proto/session.h +++

[PATCH 4/5] [MINOR] Allow shutdown of sessions when a server becomes unavailable

--- v2 * Iterate per-server session list instead of global session list in shutdown_sessions() * Set nice level of tasks of sessions to be closed to 1024 * Use TASK_WOKEN_OTHER instead of TASK_WOKEN_RES in shutdown_sessions() As suggested by Willy Tarreau * Use list_for_each_entry_safe()

[PATCH 5/5] [MINOR] Add down termination condition

If a connection is closed by because the backend became unavailable then log 'D' as the termination condition. Signed-off-by: Simon Horman ho...@verge.net.au v4 * Document 'D' termination condition --- doc/configuration.txt |2 ++ include/types/session.h |3 ++- src/checks.c