Re: [RFC v2 0/4] Allow shutdown of sessions when a server becomes unavailable
On Thu, Jun 16, 2011 at 02:41:03PM +0900, Simon Horman wrote: > > One question though : what flags are emitted in the logs when a > > session is closed that way ? I'm wondering if we should not add a new flag > > such as "D" (for "down") and/or "K" (for "killed") on the first character > > to indicate why the session was terminated. It would also make room for the > > ability to kill sessions from the CLI later. But this new flag could impact > > more code, we have to check this. > > Good point, I'll take a look into implementing that. OK. Be careful, I remember about a bitfield and a mask in the session which is set by set_term_flags(). From what I recall, we currently have 8 values (3 full bits) so it might not be that obvious to implement. > > One comment about the "struct list server" in the session. I'm afraid this > > name could cause confusion with the "srv" field, especially since it appears > > at the beginning. Maybe we should find another name such as "by_srv" or > > something like this to more clearly indicate it's the node used to chain > > the session from the server's list. > > I'm not entirely sure what a good name is, but I would like to avoid > confusion. I'll change it to by_srv and repost. It should be easy enough > to change it again later if we come up with a better name. OK, and I agree we can change it later if needed. > > Last point, I'm amazed by the number of functions you managed to turn to > > static. A few years ago this would not have been possible at all, and when > > I read your changes, for each of them I remember what we changed which made > > that possible. This means to me that the code is becoming much more modular > > and that's a very good news ! I'll try to be careful in the future about > > what functions can be turned to static after changes (provided it makes > > sense of course). > > Great. > > I did restrict those changes to a few files. Mainly because I wanted > to see if the changes were acceptable or not. I assume there is quite > a lot of scope for other files to have symbols made static. The idea should be that we don't want to jump on this and change all the code, because sometimes I have to do the opposite. But doing so in the context of related changes makes sense of course. Regards, Willy
Re: [RFC v2 0/4] Allow shutdown of sessions when a server becomes unavailable
On Thu, Jun 16, 2011 at 07:24:00AM +0200, Willy Tarreau wrote: > Hi Simon, > > On Thu, Jun 16, 2011 at 09:10:37AM +0900, Simon Horman wrote: > > Hi, > > > > I believed this addresses all of the issues raised with the previous > > version of this change. I have also verified that connections are shutdown > > a backend is placed in maintenance mode. > > That's really cool, thank you. I've quickly checked your patches an see > nothing obviously wrong, so we'll have to merge them to detect any possible > issue. One question though : what flags are emitted in the logs when a > session is closed that way ? I'm wondering if we should not add a new flag > such as "D" (for "down") and/or "K" (for "killed") on the first character > to indicate why the session was terminated. It would also make room for the > ability to kill sessions from the CLI later. But this new flag could impact > more code, we have to check this. Good point, I'll take a look into implementing that. > One comment about the "struct list server" in the session. I'm afraid this > name could cause confusion with the "srv" field, especially since it appears > at the beginning. Maybe we should find another name such as "by_srv" or > something like this to more clearly indicate it's the node used to chain > the session from the server's list. I'm not entirely sure what a good name is, but I would like to avoid confusion. I'll change it to by_srv and repost. It should be easy enough to change it again later if we come up with a better name. > Last point, I'm amazed by the number of functions you managed to turn to > static. A few years ago this would not have been possible at all, and when > I read your changes, for each of them I remember what we changed which made > that possible. This means to me that the code is becoming much more modular > and that's a very good news ! I'll try to be careful in the future about > what functions can be turned to static after changes (provided it makes > sense of course). Great. I did restrict those changes to a few files. Mainly because I wanted to see if the changes were acceptable or not. I assume there is quite a lot of scope for other files to have symbols made static.
Re: [RFC v2 0/4] Allow shutdown of sessions when a server becomes unavailable
Hi Simon, On Thu, Jun 16, 2011 at 09:10:37AM +0900, Simon Horman wrote: > Hi, > > I believed this addresses all of the issues raised with the previous > version of this change. I have also verified that connections are shutdown > a backend is placed in maintenance mode. That's really cool, thank you. I've quickly checked your patches an see nothing obviously wrong, so we'll have to merge them to detect any possible issue. One question though : what flags are emitted in the logs when a session is closed that way ? I'm wondering if we should not add a new flag such as "D" (for "down") and/or "K" (for "killed") on the first character to indicate why the session was terminated. It would also make room for the ability to kill sessions from the CLI later. But this new flag could impact more code, we have to check this. One comment about the "struct list server" in the session. I'm afraid this name could cause confusion with the "srv" field, especially since it appears at the beginning. Maybe we should find another name such as "by_srv" or something like this to more clearly indicate it's the node used to chain the session from the server's list. Last point, I'm amazed by the number of functions you managed to turn to static. A few years ago this would not have been possible at all, and when I read your changes, for each of them I remember what we changed which made that possible. This means to me that the code is becoming much more modular and that's a very good news ! I'll try to be careful in the future about what functions can be turned to static after changes (provided it makes sense of course). Thanks, Willy
[PATCH 2/4] [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
+++ b/include/proto/session.h
@@ -32,15 +32,14 @@ extern struct pool_head *pool2_session;
extern struct list sessions;
int session_accept(struct listener *l, int cfd, struct sockaddr_storage *addr);
-void session_free(struct session *s);
/* perform minimal intializations, report 0 in case of error, 1 if OK. */
int init_session();
+
void session_process_counters(struct session *s);
void sess_change_server(struct session *sess, struct server *newsrv);
struct task *process_session(struct task *t);
-void sess_set_term_flags(struct session *s);
void default_srv_error(struct session *s, struct stream_interface *si);
int parse_track_counters(char **args, int *arg,
int section_type, struct proxy *curpx,
diff --git a/src/session.c b/src/session.c
index 2c1d359..f32ca9f 100644
--- a/src/session.c
+++ b/src/session.c
@@ -320,7 +320,7 @@ int session_accept(struct listener *l, int cfd, struct
sockaddr_storage *addr)
/*
* frees the context associated to a session. It must have been removed first.
*/
-void session_free(struct session *s)
+static void session_free(struct session *s)
{
struct http_txn *txn = &s->txn;
struct proxy *fe = s->fe;
@@ -520,7 +520,7 @@ void session_process_counters(struct session *s)
* SI_ST_CON (no change). The function returns 0 if it switches to SI_ST_CER,
* otherwise 1.
*/
-int sess_update_st_con_tcp(struct session *s, struct stream_interface *si)
+static int sess_update_st_con_tcp(struct session *s, struct stream_interface
*si)
{
struct buffer *req = si->ob;
struct buffer *rep = si->ib;
@@ -588,7 +588,7 @@ int sess_update_st_con_tcp(struct session *s, struct
stream_interface *si)
* and SI_ST_REQ when an immediate redispatch is wanted. The buffers are
* marked as in error state. It returns 0.
*/
-int sess_update_st_cer(struct session *s, struct stream_interface *si)
+static int sess_update_st_cer(struct session *s, struct stream_interface *si)
{
/* we probably have to release last session from the server */
if (target_srv(&s->target)) {
@@ -669,7 +669,7 @@ int sess_update_st_cer(struct session *s, struct
stream_interface *si)
* SI_ST_EST state. It must only be called after switching from SI_ST_CON (or
* SI_ST_INI) to SI_ST_EST, but only when a ->connect function is defined.
*/
-void sess_establish(struct session *s, struct stream_interface *si)
+static void sess_establish(struct session *s, struct stream_interface *si)
{
struct buffer *req = si->ob;
struct buffer *rep = si->ib;
@@ -708,7 +708,7 @@ void sess_establish(struct session *s, struct
stream_interface *si)
* Possible output states are SI_ST_CLO, SI_ST_TAR, SI_ST_ASS, SI_ST_REQ,
SI_ST_CON.
* Flags must have previously been updated for timeouts and other conditions.
*/
-void sess_update_stream_int(struct session *s, struct stream_interface *si)
+static void sess_update_stream_int(struct session *s, struct stream_interface
*si)
{
struct server *srv = target_srv(&s->target);
@@ -867,6 +867,32 @@ void sess_update_stream_int(struct session *s, struct
stream_interface *si)
}
}
+/* Set correct session termination flags in case no analyser has done it. It
+ * also counts a failed request if the server state has not reached the request
+ * stage.
+ */
+static void sess_set_term_flags(struct session *s)
+{
+ if (!(s->flags & SN_FINST_MASK)) {
+ if (s->si[1].state < SI_ST_REQ) {
+
+ s->fe->fe_counters.failed_req++;
+ if (s->listener->counters)
+ s->listener->counters->failed_req++;
+
+ s->flags |= SN_FINST_R;
+ }
+ else if (s->si[1].state == SI_ST_QUE)
+ s->flags |= SN_FINST_Q;
+ else if (s->si[1].state < SI_ST_EST)
+ s->flags |= SN_FINST_C;
+ else if (s->si[1].state == SI_ST_EST || s->si[1].prev_state ==
SI_ST_EST)
+ s->flags |= SN_FINST_D;
+ else
+ s->flags |= SN_FINST_L;
+ }
+}
+
/* This function initiates a server connection request on a stream interface
* already in SI_ST_REQ state. Upon success, the state goes to SI_ST_ASS,
* indicating that a server has been assigned. It may also return SI_ST_QUE,
@@ -915,7 +941,7 @@ static void sess_prepare_conn_req(struct session *s, struct
stream_interface *si
* It returns 1 if the processing can continue on next analysers, or zero if it
* either needs more data or wants to immediately abort the request.
*/
-int process_switching_rules(struct session *s, struct b
[PATCH 3/4] [MINOR] Add active connection list to server
---
include/proto/session.h | 15 +++
include/types/server.h |1 +
include/types/session.h |1 +
src/cfgparse.c |1 +
src/peers.c |2 +-
src/proto_http.c|2 +-
src/queue.c |3 ++-
src/session.c |6 +++---
8 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/include/proto/session.h b/include/proto/session.h
index c9195f6..a7055bf 100644
--- a/include/proto/session.h
+++ b/include/proto/session.h
@@ -225,6 +225,21 @@ static void inline session_inc_http_err_ctr(struct session
*s)
}
}
+static void inline session_add_srv_conn(struct session *sess, struct server
*srv)
+{
+ sess->srv_conn = srv;
+ LIST_ADD(&srv->actconns, &sess->server);
+}
+
+static void inline session_del_srv_conn(struct session *sess)
+{
+ if (!sess->srv_conn)
+ return;
+
+ sess->srv_conn = NULL;
+ LIST_DEL(&sess->server);
+}
+
#endif /* _PROTO_SESSION_H */
/*
diff --git a/include/types/server.h b/include/types/server.h
index fb31215..cf0a0df 100644
--- a/include/types/server.h
+++ b/include/types/server.h
@@ -101,6 +101,7 @@ struct server {
struct srvcounters counters;/* statistics counters */
struct list pendconns; /* pending connections */
+ struct list actconns; /* active connections */
struct task *check; /* the task associated to the
health check processing */
struct sockaddr_storage addr; /* the address to connect to */
diff --git a/include/types/session.h b/include/types/session.h
index 2ac2232..07a897c 100644
--- a/include/types/session.h
+++ b/include/types/session.h
@@ -157,6 +157,7 @@ enum {
*/
struct session {
struct list list; /* position in global sessions
list */
+ struct list server; /* position in server session
list */
struct list back_refs; /* list of users tracking this
session */
struct task *task; /* the task associated with
this session */
/* application specific below */
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 40c46d5..9626e36 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -3921,6 +3921,7 @@ stats_error_parsing:
newsrv->conf.file = file;
newsrv->conf.line = linenum;
+ LIST_INIT(&newsrv->actconns);
LIST_INIT(&newsrv->pendconns);
do_check = 0;
newsrv->state = SRV_RUNNING; /* early server setup */
diff --git a/src/peers.c b/src/peers.c
index cdc8318..f253280 100644
--- a/src/peers.c
+++ b/src/peers.c
@@ -1185,7 +1185,7 @@ static struct session *peer_session_create(struct peer
*peer, struct peer_sessio
stream_sock_prepare_interface(&s->si[1]);
s->si[1].release = NULL;
- s->srv_conn = NULL;
+ session_del_srv_conn(s);
clear_target(&s->target);
s->pend_pos = NULL;
diff --git a/src/proto_http.c b/src/proto_http.c
index 69232f9..e4c80c1 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -7595,7 +7595,7 @@ void http_reset_txn(struct session *s)
s->be = s->fe;
s->logs.logwait = s->fe->to_log;
- s->srv_conn = NULL;
+ session_del_srv_conn(s);
clear_target(&s->target);
/* re-init store persistence */
s->store_count = 0;
diff --git a/src/queue.c b/src/queue.c
index 48380fc..ea0bfb8 100644
--- a/src/queue.c
+++ b/src/queue.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
@@ -122,7 +123,7 @@ struct session *pendconn_get_next_sess(struct server *srv,
struct proxy *px)
/* we want to note that the session has now been assigned a server */
sess->flags |= SN_ASSIGNED;
set_target_server(&sess->target, srv);
- sess->srv_conn = srv;
+ session_add_srv_conn(sess, srv);
srv->served++;
if (px->lbprm.server_take_conn)
px->lbprm.server_take_conn(srv);
diff --git a/src/session.c b/src/session.c
index f32ca9f..56d0c8f 100644
--- a/src/session.c
+++ b/src/session.c
@@ -201,7 +201,7 @@ int session_accept(struct listener *l, int cfd, struct
sockaddr_storage *addr)
if (likely(s->fe->options2 & PR_O2_INDEPSTR))
s->si[1].flags |= SI_FL_INDEP_STR;
- s->srv_conn = NULL;
+ session_del_srv_conn(s);
clear_target(&s->target);
s->pend_pos = NULL;
@@ -2140,14 +2140,14 @@ void sess_change_server(struct session *sess, struct
server *newsrv)
sess->srv_conn->served--;
if (sess->srv_conn->proxy->lbprm.server_drop_conn)
sess->srv_conn->proxy->lbprm.server_drop_conn(sess->srv_conn);
- sess->srv_conn = NULL;
+ session_del_srv_conn(sess);
}
if (newsrv)
[PATCH 4/4] [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() instead of FOR_ITEM_SAFE in
shutdown_sessions()
* Rather than shutting down both the read and write side of the response,
shut down the read side of the response and the write side of the request.
As suggested by Willy Tarreau
---
doc/configuration.txt |9 +
include/types/checks.h |6 ++
include/types/server.h |1 +
src/cfgparse.c | 14 +-
src/checks.c | 22 ++
5 files changed, 51 insertions(+), 1 deletions(-)
diff --git a/doc/configuration.txt b/doc/configuration.txt
index b22ac98..b788c13 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -6667,6 +6667,15 @@ on-error
See also the "check", "observe" and "error-limit".
+on-marked-down
+ Modify what occurs when a server is marked down.
+ Currently one action is available:
+ - shutdown-sessions: Shutdown peer sessions
+
+ Actions are disabled by default
+
+ Supported in default-server: Yes
+
port
Using the "port" parameter, it becomes possible to use a different port to
send health-checks. On some servers, it may be desirable to dedicate a port
diff --git a/include/types/checks.h b/include/types/checks.h
index 75e32b6..a414630 100644
--- a/include/types/checks.h
+++ b/include/types/checks.h
@@ -74,6 +74,12 @@ enum {
};
enum {
+ HANA_ONMARKEDDOWN_NONE = 0,
+
+ HANA_ONMARKEDDOWN_SHUTDOWNSESSIONS, /* Shutdown peer sessions */
+};
+
+enum {
HANA_OBS_NONE = 0,
HANA_OBS_LAYER4,/* Observe L4 - for example tcp */
diff --git a/include/types/server.h b/include/types/server.h
index cf0a0df..1a9d60d 100644
--- a/include/types/server.h
+++ b/include/types/server.h
@@ -125,6 +125,7 @@ struct server {
int rise, fall; /* time in iterations */
int consecutive_errors_limit; /* number of consecutive errors
that triggers an event */
short observe, onerror; /* observing mode: one of
HANA_OBS_*; what to do on error: on of ANA_ONERR_* */
+ short onmarkeddown; /* what to do when marked down:
on of HANA_ONMARKEDDOWN_* */
int inter, fastinter, downinter;/* checks: time in milliseconds
*/
int slowstart; /* slowstart time in seconds
(ms in the conf) */
int result; /* health-check result :
SRV_CHK_* */
diff --git a/src/cfgparse.c b/src/cfgparse.c
index 9626e36..c19f430 100644
--- a/src/cfgparse.c
+++ b/src/cfgparse.c
@@ -4250,6 +4250,18 @@ stats_error_parsing:
cur_arg += 2;
}
+ else if (!strcmp(args[cur_arg], "on-marked-down")) {
+ if (!strcmp(args[cur_arg + 1],
"shutdown-sessions"))
+ newsrv->onmarkeddown =
HANA_ONMARKEDDOWN_SHUTDOWNSESSIONS;
+ else {
+ Alert("parsing [%s:%d]: '%s' expects
'shutdown-sessions' but got '%s'\n",
+ file, linenum, args[cur_arg],
args[cur_arg + 1]);
+ err_code |= ERR_ALERT | ERR_FATAL;
+ goto out;
+ }
+
+ cur_arg += 2;
+ }
else if (!strcmp(args[cur_arg], "error-limit")) {
if (!*args[cur_arg + 1]) {
Alert("parsing [%s:%d]: '%s' expects an
integer argument.\n",
@@ -4429,7 +4441,7 @@ stats_error_parsing:
}
else {
if (!defsrv)
- Alert("parsing [%s:%d] : server %s only
supports options 'backup', 'cookie', 'redir', 'observer', 'on-error',
'error-limit', 'check', 'disabled', 'track', 'id', 'inter', 'fastinter',
'downinter', 'rise', 'fall', 'addr', 'port', 'source', 'send-proxy', 'minconn',
'maxconn', 'maxqueue', 'slowstart' and 'weight'.\n",
+ Alert("parsing [%s:%d] : server %s only
supports options 'backup', 'cookie', 'redir', 'observer', 'on-error',
'on-marked-down', 'error-limit', 'check', 'disabled', 'track', 'id', 'inter',
'fastinter', 'downinter', 'rise', 'fall', 'addr', 'port', 'source',
'send-proxy', 'minconn', 'maxconn', 'maxqueue', 'slowstart' and 'weight'.\n",
file, linenum, newsrv->id);
else
Alert("parsin
[RFC v2 0/4] Allow shutdown of sessions when a server becomes unavailable
Hi, I believed this addresses all of the issues raised with the previous version of this change. I have also verified that connections are shutdown a backend is placed in maintenance mode.
[PATCH 1/4] [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
---
include/proto/peers.h |3 +--
src/peers.c | 12 ++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/include/proto/peers.h b/include/proto/peers.h
index d188854..349fda5 100644
--- a/include/proto/peers.h
+++ b/include/proto/peers.h
@@ -28,8 +28,7 @@
#include
#include
-struct session * peer_session_create(struct peer *);
-struct session * peers_register_table(struct peers *, struct stktable *table);
+void peers_register_table(struct peers *, struct stktable *table);
int peer_accept(struct session *);
diff --git a/src/peers.c b/src/peers.c
index 0274483..cdc8318 100644
--- a/src/peers.c
+++ b/src/peers.c
@@ -125,14 +125,14 @@
#define PEER_SESSION_PROTO_NAME "HAProxyS"
struct peers *peers = NULL;
-void peer_session_forceshutdown(struct session * session);
+static void peer_session_forceshutdown(struct session * session);
/*
* This prepare the data update message of the stick session , is the
the peer session
* where the data going to be pushed, is a buffer of to recieve
data message content
*/
-int peer_prepare_datamsg(struct stksess *ts, struct peer_session *ps, char
*msg, size_t size)
+static int peer_prepare_datamsg(struct stksess *ts, struct peer_session *ps,
char *msg, size_t size)
{
uint32_t netinteger;
int len;
@@ -182,7 +182,7 @@ int peer_prepare_datamsg(struct stksess *ts, struct
peer_session *ps, char *msg,
/*
* Callback to release a session with a peer
*/
-void peer_session_release(struct stream_interface *si)
+static void peer_session_release(struct stream_interface *si)
{
struct task *t= (struct task *)si->owner;
struct session *s = (struct session *)t->context;
@@ -1049,7 +1049,7 @@ static struct si_applet peer_applet = {
/*
* Use this function to force a close of a peer session
*/
-void peer_session_forceshutdown(struct session * session)
+static void peer_session_forceshutdown(struct session * session)
{
struct stream_interface *oldsi;
@@ -1104,7 +1104,7 @@ int peer_accept(struct session *s)
/*
* Create a new peer session in assigned state (connect will start
automatically)
*/
-struct session *peer_session_create(struct peer *peer, struct peer_session *ps)
+static struct session *peer_session_create(struct peer *peer, struct
peer_session *ps)
{
struct listener *l = ((struct proxy *)peer->peers->peers_fe)->listen;
struct proxy *p = (struct proxy *)l->frontend; /* attached frontend */
@@ -1294,7 +1294,7 @@ struct session *peer_session_create(struct peer *peer,
struct peer_session *ps)
* Task processing function to manage re-connect and peer session
* tasks wakeup on local update.
*/
-struct task *process_peer_sync(struct task * task)
+static struct task *process_peer_sync(struct task * task)
{
struct shared_table *st = (struct shared_table *)task->context;
struct peer_session *ps;
--
1.7.4.4
Re: [PATCH] [MINOR] Allow shutdown of sessions when a server becomes unavailable
On Wed, Jun 15, 2011 at 10:03:17PM +0200, Willy Tarreau wrote:
> On Wed, Jun 15, 2011 at 05:01:32PM +0900, Simon Horman wrote:
> > On Wed, Jun 08, 2011 at 10:55:44AM +0200, Willy Tarreau wrote:
> >
> > [snip]
> >
> > > Not necessarily : currently, if you only close on the server side, the
> > > effect will be propagated to the client side, so it already does the right
> > > thing and at the same time will allow us to improve on this later.
> >
> > Hi Willy,
> >
> > I am a little confused about how to shut down sessions on the server side.
> >
> > Currently I have:
> >
> > if (session->srv_conn == srv &&
> > !(session->rep->flags & (BF_SHUTW|BF_SHUTW_NOW))) {
> > buffer_shutr_now(session->rep);
> > buffer_shutw_now(session->rep);
> > ...
> > }
> >
> > Is your suggestion to change rep to req? I did try that initially
> > without success. I assume that I am missing something.
>
> No, the idea is that we want to shut the write side of the request and
> the read side of the response in order to close everything connected
> to the server. Doing so should be enough :
>
> buffer_shutw_now(session->req);
> buffer_shutr_now(session->rep);
Thanks, got it.
Re: nice wiki doc of haproxy
Le 15/06/11 23:09, Willy Tarreau a écrit : > On Wed, Jun 15, 2011 at 04:37:16PM -0400, James Bardin wrote: >> Just throwing my $.02; how about converting the documentation to >> something more easily parse-able, like markdown? > > You mean the mainline doc ? If so, it's been discussed to great length in > the past, and the short answer is "no". The documentation is always what > lags behind code. Whatever barrier you put in front of doc contribs will > simply slow them down. I've experienced this a lot in the past with the > french doc version which was never updated in contribs. Here I already > see what will happen : "I've updated the doc but I'm not sure about the > end results as I don't have the tool to regenerate it". The current format > leaves no excuse for this. I want a human to be able to parse it and to > have to conform to very few rules. > > What I want is a *smart* converter which understands the doc format. Once > we spot the real issues (ambiguous situations where we cannot guess), then > we'll fix the format and add a few rules. > > Also, I regularly receive support from people who work on production > systems where they have no choice but reading the doc in the 80x25 text > console with vi or less. I absolutely want the doc to be optimally > usable there. This means no tags, no long lines, etc... Just plain > text formatted right and convertible to other formats for a nicer > experience when it's possible. > > BTW, a "man" output would be nice too ;-) > > I remember about asciidoc and such which were able to produce various > formats, and which could serve as an intermediary format later when > we're able to parse what we have. markdown and asciidoc pretty are similar, and human readable. That said I agree with everything you said. For instance, Mercurial documentation was migrated from standalone text file to simplified reStructuredText version (a popular format in python world) mostly embedded in source code and this has been a huge win. We are now able to generate documentation in different formats (console output, manpages, HTML), display the same documentation from the CLI or web interface and even generate documentation dynamically for features brought by third-parties plugins. -- Patrick Mézard
Re: Separated config file support
On Wed, Jun 15, 2011 at 11:21:57PM +0200, Mike Hoffs wrote: > Maybe it is possible to add an include conf.d in the main config, and after > that part all other config files will be automaticly included. Something like > apache can do ? Not convinced at all because I don't see how it solves all issues. And I'm even less convinced it adds any value beyond passing the conf.d as "-f" on the command line. Willy
Re: HAProxy for PostgreSQL Failover
Hello Alan, You can use the built-in health check for PostgreSQL servers (since 1.5-dev4). Regards, Rauf On Wed, Jun 15, 2011 at 10:54 AM, Alan Gutierrez wrote: > I'd like to use HAProxy to implement a simple proxy that can perform > failover for a pair of PostgreSQL configured as master/slave with PostgreSQL > 9.0 streaming replication to replicate the master to the slave. Only the > master is active for client connections, unless the master fails, then the > clients should connect to the slave while an administrator recovers the > master. > Thus, I need a setup in HAProxy, where all traffic goes to the master, until > the master fails, then all traffic goes to the slave. > I've studied the MySQL balancing setup described here: > http://www.alexwilliams.ca/blog/2009/08/10/using-haproxy-for-mysql-failover-and-redundancy/ > With this as a basis, I could create a daemon on the HAProxy machine that > tests the master and reports on the health of the master via HTTP. The HTTP > health check is used with an ACL in a frontend. If the master is up, the > master backend is used. If it is down the slave backend is used. > Or else, I could test for the health of the master, and when it fails I can > kill, reconfigure and restart HAProxy. It might be easier. > Sound like a good use of HAProxy? Are their any known issues with HAProxy > and PostgreSQL? > -- > Alan Gutierrez
Re: Separated config file support
On Wed, Jun 15, 2011 at 11:21:57PM +0200, Mike Hoffs wrote: > Maybe it is possible to add an include conf.d in the main config, and after > that part all other config files will be automaticly included. Something like > apache can do ? As I explained in another thread, includes are really nasty for configs which can have different meaning depending on the context. For instance, imagine how you would proceed with such a config : listen public bind :80 balance roundrobin default-server check inter 10 server sorry 10.10.10.10:80 backup include app01.conf option httpchk / with app01.conf containing that : server srv1 1.1.1.1:80 cookie A server srv2 1.1.1.2:80 cookie B server srv3 1.1.1.3:80 cookie C server srv4 1.1.1.4:80 cookie D First, you'll notice that when reading the included file alone, you have no idea about how the cookie's used, nor if the servers are checked, or how they are checked. It's already a mess. Now let's add a bit more of a mess. You're on holidays and someone decides to add a section to app01.conf : server srv1 1.1.1.1:80 cookie A server srv2 1.1.1.2:80 cookie B server srv3 1.1.1.3:80 cookie C server srv4 1.1.1.4:80 cookie D defaults app01_settings cookie JSESSIONID prefix Then this "defaults" section will in fact silently change the "defaults" semantics for all sections declared after the first one in the main file. It will disable "option httpchk /" for the first section, and enable it for all subsequent sections, as well as fixing the cookie name in prefix mode. Believe me I started with the include method in mind, but I finally stopped because there were too many caveats. It basically is impossible to track the effect of any declaration on other sections, and the config quickly becomes a nightmare to debug. Another issue was loop detection, though it can in general be covered by non-trivial algorithms which involve the file name and inode. Last, there are other caveats when using subdirectories, because while using paths relative to the file holding the "include" directive looks like the most intuitive approach for the user, it's also the one causing the most headaches when troubleshooting, and for loop detection. I really think that the multiple file solution is a good compromise. We might implement something such as loading all files from a directory, that could make sense, but quite frankly, given that many people more or less generate their files, the features only saves a simple command such as "cat $dir/*.conf | haproxy -f /dev/stdin" operation in a startup script, which is far from being the most complex issue to solve ! Regards, Willy
RE: Separated config file support
Maybe it is possible to add an include conf.d in the main config, and after that part all other config files will be automaticly included. Something like apache can do ? Met een vriendelijke groet, Mike Hoffs Mijn-Sleutel Peperstraat 33 6678 AL Oosterhout Tel: +31 (0)24 8200208 tijdens kantoor uren (09:00 - 17:00) Mail: m.ho...@mijn-sleutel.com Website: http://www.mijn-sleutel.com -Oorspronkelijk bericht- Van: Willy Tarreau [mailto:w...@1wt.eu] Verzonden: woensdag 15 juni 2011 22:08 Aan: Harvey Yau CC: haproxy@formilux.org Onderwerp: Re: Separated config file support On Wed, Jun 15, 2011 at 04:02:09PM -0400, Harvey Yau wrote: > On 6/15/11 3:59 PM, Igor wrote: > >Got a very long haproxy.conf, is there any way to separate config file > >by using any directive like include *.conf? > > > >Bests, > >-Igor > > > A config directory would be nice as well. Would make it nice and easy > to rsync config files around as well - pretty nice. You can already specify "-f" multiple times and all files will be merged in memory. Willy
Re: nice wiki doc of haproxy
On Wed, Jun 15, 2011 at 04:37:16PM -0400, James Bardin wrote: > Just throwing my $.02; how about converting the documentation to > something more easily parse-able, like markdown? You mean the mainline doc ? If so, it's been discussed to great length in the past, and the short answer is "no". The documentation is always what lags behind code. Whatever barrier you put in front of doc contribs will simply slow them down. I've experienced this a lot in the past with the french doc version which was never updated in contribs. Here I already see what will happen : "I've updated the doc but I'm not sure about the end results as I don't have the tool to regenerate it". The current format leaves no excuse for this. I want a human to be able to parse it and to have to conform to very few rules. What I want is a *smart* converter which understands the doc format. Once we spot the real issues (ambiguous situations where we cannot guess), then we'll fix the format and add a few rules. Also, I regularly receive support from people who work on production systems where they have no choice but reading the doc in the 80x25 text console with vi or less. I absolutely want the doc to be optimally usable there. This means no tags, no long lines, etc... Just plain text formatted right and convertible to other formats for a nicer experience when it's possible. BTW, a "man" output would be nice too ;-) I remember about asciidoc and such which were able to produce various formats, and which could serve as an intermediary format later when we're able to parse what we have. Regards, Willy
Re: nice wiki doc of haproxy
Hi Cyril, On Wed, Jun 15, 2011 at 10:21:21PM +0200, Cyril Bonté wrote: > > What we need is an automatic converter for various formats. Some very > > nice conversions were posted something like one year ago, which were > > almost automatic but unfortunately nobody had time to takeover the > > project and continue on this work. > > Yes, I still have this in my TODO list but couldn't find time to cleanup the > process : the code was really too awfull and unreadable to be published :-) > I'll try to restart this development as soon as possible and submit a minimal > version of the converter. Then it will be possible to enhance it > incrementally. Believe me, you should never ever feel ashamed of any work you find ugly, especially when there are people who are actively asking for it. If some users are that much waiting for seeing it, probably that as soon as it's published, a few ones will take it, review it, and perform the cleanup way before you find enough time to work on it. Maybe a few ones will totally fork it believing it's crap and they can do something much better. Maybe they'll be right, maybe they'll fail. It doesn't matter. I know how you feel about what it's like to publish ugly things (hint: there are a lot of even uglier things on 1wt.eu/tools/ that I accepted to publish because people were asking for them). But those ugly things are often useful to people who don't pay attention to the appearance, and who sometimes will be a lot less critical than you on your work. Haproxy was started as something ugly 10 years ago. Some would say that the ugliness has remained or even increased. Still, opening it has tremendously helped improving it. Git is another example of something that started ugly by one tech guy with strong requirements, quickly taken over by a team who made it much more user-friendly, promoting it to the success we know. I'd say that there could be three reasons for not publishing it too fast : - you did that work in a context of a paid job and you're not certain you have the right to publish it ; - you fear that you have sensitive info that you'd like not to disclose (eg: comments about one customer you started the work for, etc...) ; - you think that only you can understand how your code works and you fear that it will be much more work to explain someone else how to do the cleanup than doing it yourself. I remember having seen examples of what you managed to produce and was really impressed. I also remember about another older one which produced great results but I don't remember from whom. Anyway, that means to me that it's hard for everyone to find time to work on such a project, and this is another reason to ask for help. Just keep in mind that you must find the license that suits your expectations the most, and possibly emit strong opinions on some directions you want it to take. Best regards, Willy
Re: nice wiki doc of haproxy
Just throwing my $.02; how about converting the documentation to something more easily parse-able, like markdown? -- -jim
Re: nice wiki doc of haproxy
Looks trivial to fork this and turn the regex.txt into a script. I'm up for taking that once we have free cycles at work (couple days max). https://github.com/tmslnz/HAProxy_Markdown On Wed, Jun 15, 2011 at 1:12 PM, Willy Tarreau wrote: > On Wed, Jun 15, 2011 at 06:43:14PM +0530, shreyas pandya wrote: > > There is a nice wiki doc on haproxy configuration at > > http://code.google.com/p/haproxy-docs/ > > I m sharing this because i didn't see it's mention on main site > > http://haproxy.1wt.eu/ > > > > it's easy to read than original txt doc > > Yes, this one is really nice. However it seems it was converted by > hand, and as anything converted by hand, it eventually dies by lack > of time. > > What we need is an automatic converter for various formats. Some very > nice conversions were posted something like one year ago, which were > almost automatic but unfortunately nobody had time to takeover the > project and continue on this work. > > Regards, > Willy > > >
Re: nice wiki doc of haproxy
Hi all, Le mercredi 15 juin 2011 22:12:18, Willy Tarreau a écrit : > On Wed, Jun 15, 2011 at 06:43:14PM +0530, shreyas pandya wrote: > > There is a nice wiki doc on haproxy configuration at > > http://code.google.com/p/haproxy-docs/ > > I m sharing this because i didn't see it's mention on main site > > http://haproxy.1wt.eu/ > > > > it's easy to read than original txt doc > > Yes, this one is really nice. However it seems it was converted by > hand, and as anything converted by hand, it eventually dies by lack > of time. > > What we need is an automatic converter for various formats. Some very > nice conversions were posted something like one year ago, which were > almost automatic but unfortunately nobody had time to takeover the > project and continue on this work. Yes, I still have this in my TODO list but couldn't find time to cleanup the process : the code was really too awfull and unreadable to be published :-) I'll try to restart this development as soon as possible and submit a minimal version of the converter. Then it will be possible to enhance it incrementally. -- Cyril Bonté
Re: nice wiki doc of haproxy
On Wed, Jun 15, 2011 at 06:43:14PM +0530, shreyas pandya wrote: > There is a nice wiki doc on haproxy configuration at > http://code.google.com/p/haproxy-docs/ > I m sharing this because i didn't see it's mention on main site > http://haproxy.1wt.eu/ > > it's easy to read than original txt doc Yes, this one is really nice. However it seems it was converted by hand, and as anything converted by hand, it eventually dies by lack of time. What we need is an automatic converter for various formats. Some very nice conversions were posted something like one year ago, which were almost automatic but unfortunately nobody had time to takeover the project and continue on this work. Regards, Willy
Re: Separated config file support
On Wed, Jun 15, 2011 at 04:02:09PM -0400, Harvey Yau wrote: > On 6/15/11 3:59 PM, Igor wrote: > >Got a very long haproxy.conf, is there any way to separate config file > >by using any directive like include *.conf? > > > >Bests, > >-Igor > > > A config directory would be nice as well. Would make it nice and easy > to rsync config files around as well - pretty nice. You can already specify "-f" multiple times and all files will be merged in memory. Willy
Re: [PATCH] [MINOR] Allow shutdown of sessions when a server becomes unavailable
On Wed, Jun 15, 2011 at 05:01:32PM +0900, Simon Horman wrote:
> On Wed, Jun 08, 2011 at 10:55:44AM +0200, Willy Tarreau wrote:
>
> [snip]
>
> > Not necessarily : currently, if you only close on the server side, the
> > effect will be propagated to the client side, so it already does the right
> > thing and at the same time will allow us to improve on this later.
>
> Hi Willy,
>
> I am a little confused about how to shut down sessions on the server side.
>
> Currently I have:
>
> if (session->srv_conn == srv &&
> !(session->rep->flags & (BF_SHUTW|BF_SHUTW_NOW))) {
> buffer_shutr_now(session->rep);
> buffer_shutw_now(session->rep);
> ...
> }
>
> Is your suggestion to change rep to req? I did try that initially
> without success. I assume that I am missing something.
No, the idea is that we want to shut the write side of the request and
the read side of the response in order to close everything connected
to the server. Doing so should be enough :
buffer_shutw_now(session->req);
buffer_shutr_now(session->rep);
Regards,
Willy
Re: Separated config file support
On 6/15/11 3:59 PM, Igor wrote: Got a very long haproxy.conf, is there any way to separate config file by using any directive like include *.conf? Bests, -Igor A config directory would be nice as well. Would make it nice and easy to rsync config files around as well - pretty nice. -- Harvey
Separated config file support
Got a very long haproxy.conf, is there any way to separate config file by using any directive like include *.conf? Bests, -Igor
Re: Are lots of small back-end pools handled efficiently?
Hello, On Wed, Jun 15, 2011 at 12:16:57PM +0100, Chris Allen wrote: > Hello, > > The architecture of our application is such that we are running haproxy > with a large number (perhaps 700-800) > of back-end pools, each containing a single server. Is this something > that haproxy can handle efficiently? Are > there any caveats as the number of pools increases? Perhaps memory or > CPU load? This is something I'm used to seeing where haproxy is used as a plain simple relay to enforce timeouts or as a NAT box. There is no particular issue doing this. What you should consider however is how you will select which backend will process a request. If you're evaluating thousands of regex-based rules in order to finally decide the right backend, then it can be expensive in terms of CPU load. And even there it depends on the regex lib used and the request rate, of course. But in general it's not much an issue. Ah, another minor issue you'll notice is that the stats page is huge ;-) Regards, Willy
Re: Handling errors "502 Bad Gateway"
Hi Willy Tarreau! On Thu, Jun 09, 2011 at 10:36:14PM +0200, Willy Tarreau wrote: > > Here, actually, I've found the description of the same problem. At > > Apache falling/restart, haproxy returns to users 502 error. > > > http://www.formilux.org/archives/haproxy/0812/1575.html > > > > Here I give the example of how it looks: > It's more complex than just black-or-white. First, there's a solution so > that you never have any error at all, but let me first explain what is > happening and why it's behaving that way. > ... Thank you for such a comprehensive answer. -- BRGDS. Alexey Vlasov.
HAProxy for PostgreSQL Failover
I'd like to use HAProxy to implement a simple proxy that can perform failover for a pair of PostgreSQL configured as master/slave with PostgreSQL 9.0 streaming replication to replicate the master to the slave. Only the master is active for client connections, unless the master fails, then the clients should connect to the slave while an administrator recovers the master. Thus, I need a setup in HAProxy, where all traffic goes to the master, until the master fails, then all traffic goes to the slave. I've studied the MySQL balancing setup described here: http://www.alexwilliams.ca/blog/2009/08/10/using-haproxy-for-mysql-failover-and-redundancy/ With this as a basis, I could create a daemon on the HAProxy machine that tests the master and reports on the health of the master via HTTP. The HTTP health check is used with an ACL in a frontend. If the master is up, the master backend is used. If it is down the slave backend is used. Or else, I could test for the health of the master, and when it fails I can kill, reconfigure and restart HAProxy. It might be easier. Sound like a good use of HAProxy? Are their any known issues with HAProxy and PostgreSQL? -- Alan Gutierrez
Re: Are lots of small back-end pools handled efficiently?
2011/6/15 Chris Allen > Hello, > > The architecture of our application is such that we are running haproxy > with a large number (perhaps 700-800) > of back-end pools, each containing a single server. Is this something that > haproxy can handle efficiently? Are > there any caveats as the number of pools increases? Perhaps memory or CPU > load? > > Many thanks, > > Hello, I'm using haproxy with 1700 backends (each backends with 3 servers) and it seems to work well on a Intel(R) Celeron(R) CPU 2.66GHz. Haproxy uses 10% of cpu time and 70m of RAM. Regards, Aurélien
nice wiki doc of haproxy
There is a nice wiki doc on haproxy configuration at http://code.google.com/p/haproxy-docs/ I m sharing this because i didn't see it's mention on main site http://haproxy.1wt.eu/ it's easy to read than original txt doc
RE: Apache translates 500 to 502 from haproxy
tried with option http-server-close instead of option httpclose - no luck it does not work. The only way I can get it to work is without either. Thanks Sachin -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Wednesday, June 15, 2011 12:40 PM To: Sachin Shetty Cc: 'Cassidy, Bryan'; haproxy@formilux.org Subject: Re: Apache translates 500 to 502 from haproxy On Wed, Jun 15, 2011 at 12:11:58PM +0530, Sachin Shetty wrote: > I also think apache is the issue. I think we have a few mischievous modules > like mod_rpaf that I need to disable and test. I will keep you posted. > > For now do you see any severe problem if I disabe httpclose as a workaround? As I said, in theory no, unless you need haproxy to analyse more than one request per connection. But please do make a test with http-server-close. While there is little chance that it helps, it's not completely impossible because it is able to reinforce keep-alive on the client side even if it is disable on the server side. Willy
Are lots of small back-end pools handled efficiently?
Hello, The architecture of our application is such that we are running haproxy with a large number (perhaps 700-800) of back-end pools, each containing a single server. Is this something that haproxy can handle efficiently? Are there any caveats as the number of pools increases? Perhaps memory or CPU load? Many thanks, Chris Allen.
unsubscribe
Re: Apache translates 500 to 502 from haproxy
On Wed, Jun 15, 2011 at 01:09:13PM +0530, Sachin Shetty wrote: > Does disabling httpclose also mean that haproxy will not even log subsequent > requests on the same connection? Exactly. But that's only an issue if that ever happens. Willy
Re: error with ipv6 backend www server
+1 cent 2011/6/15 Brane F. Gračnar : > On Wednesday 15 of June 2011 09:12:00 Willy Tarreau wrote: >> The server address syntax is : >> >> server : >> >> So you should have a colon and not a space before '80' : >> >> 3ffe::21da:7:3c06:7c4c:8215:2:80 >> >> Note that the syntax is non-ambiguous because the last colon is mandatory >> before the port, so anything which is before the last colon is the address > > > Willy, i have a suggestion; what if server declaration would be changed to: > > server []: > server [host.example.com]:port > > That would be new, "preferred" format, while "old" one would be supported, but > deprecated. > > I think it would be trivial to implement and configuration would be much more > readable. > > The same with logs. > > What do you think? > > Best regards, Brane > >
Re: error with ipv6 backend www server
On Wednesday 15 of June 2011 09:12:00 Willy Tarreau wrote: > The server address syntax is : > > server : > > So you should have a colon and not a space before '80' : > > 3ffe::21da:7:3c06:7c4c:8215:2:80 > > Note that the syntax is non-ambiguous because the last colon is mandatory > before the port, so anything which is before the last colon is the address Willy, i have a suggestion; what if server declaration would be changed to: server []: server [host.example.com]:port That would be new, "preferred" format, while "old" one would be supported, but deprecated. I think it would be trivial to implement and configuration would be much more readable. The same with logs. What do you think? Best regards, Brane
Re: url_beg
Hi Willy, got your mail but was ill :( Sorry I checked the haproxys logfile and there I found the right backend. So before I will report an error I will check my application twice ... Thank you Gerd On 14.06.2011 07:12, Willy Tarreau wrote: > Gerd, I'm not sure you got this mail since you did not respond > to it. If there's a reproducible bug, I'd prefer to fix it before > releasing 1.4.16, but as I said, it worked perfectly here so I > need more info. > > Willy > > On Fri, Jun 10, 2011 at 02:15:12PM +0200, Willy Tarreau wrote: >> On Fri, Jun 10, 2011 at 01:53:35PM +0200, Gerd Müller wrote: >>> Hi list, >>> >>> I have a problem with url_beg. I am using it the following way: >>> >>> acl aclDEV url_beg /devel/ >>> use_backend DEV if aclDEV >>> >>> The strange thing ist that it works for >>> >>> http://my.domain.com/devel/2011/ >>> >>> but not for >>> >>> http://my.domain.com/devel/2011 >>> >>> It does not work without the trailing slash. Any ideas? >> For me it does always work. What version are you running ? And are you >> sure that you're not matching another earlier rule ? >> >> Willy >>
Re: [PATCH] [MINOR] Allow shutdown of sessions when a server becomes unavailable
On Wed, Jun 08, 2011 at 10:55:44AM +0200, Willy Tarreau wrote:
[snip]
> Not necessarily : currently, if you only close on the server side, the
> effect will be propagated to the client side, so it already does the right
> thing and at the same time will allow us to improve on this later.
Hi Willy,
I am a little confused about how to shut down sessions on the server side.
Currently I have:
if (session->srv_conn == srv &&
!(session->rep->flags & (BF_SHUTW|BF_SHUTW_NOW))) {
buffer_shutr_now(session->rep);
buffer_shutw_now(session->rep);
...
}
Is your suggestion to change rep to req? I did try that initially
without success. I assume that I am missing something.
RE: Apache translates 500 to 502 from haproxy
Does disabling httpclose also mean that haproxy will not even log subsequent requests on the same connection? Thanks Sachin -Original Message- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Wednesday, June 15, 2011 12:40 PM To: Sachin Shetty Cc: 'Cassidy, Bryan'; haproxy@formilux.org Subject: Re: Apache translates 500 to 502 from haproxy On Wed, Jun 15, 2011 at 12:11:58PM +0530, Sachin Shetty wrote: > I also think apache is the issue. I think we have a few mischievous modules > like mod_rpaf that I need to disable and test. I will keep you posted. > > For now do you see any severe problem if I disabe httpclose as a workaround? As I said, in theory no, unless you need haproxy to analyse more than one request per connection. But please do make a test with http-server-close. While there is little chance that it helps, it's not completely impossible because it is able to reinforce keep-alive on the client side even if it is disable on the server side. Willy
Re: error with ipv6 backend www server
Hi, On Wed, Jun 15, 2011 at 02:42:58PM +0800, Delta Yeh wrote: > Hi, > I run into error when I try to proxy http request to an ipv6 www > server, the error is : > debian:~/v6# ./haproxy -f v6.cfg > [ALERT] 165/142945 (23488) : parsing [v6.cfg:28] : Unknown host in > '3ffe::21da:7:3c06:7c4c:8215:2' > [ALERT] 165/142945 (23488) : Error(s) found in configuration file : v6.cfg > [ALERT] 165/142946 (23488) : Fatal errors found in configuration. (...) > server 2008 3ffe::21da:7:3c06:7c4c:8215:2 80 The server address syntax is : server : So you should have a colon and not a space before '80' : 3ffe::21da:7:3c06:7c4c:8215:2:80 Note that the syntax is non-ambiguous because the last colon is mandatory before the port, so anything which is before the last colon is the address. Willy
Re: Apache translates 500 to 502 from haproxy
On Wed, Jun 15, 2011 at 12:11:58PM +0530, Sachin Shetty wrote: > I also think apache is the issue. I think we have a few mischievous modules > like mod_rpaf that I need to disable and test. I will keep you posted. > > For now do you see any severe problem if I disabe httpclose as a workaround? As I said, in theory no, unless you need haproxy to analyse more than one request per connection. But please do make a test with http-server-close. While there is little chance that it helps, it's not completely impossible because it is able to reinforce keep-alive on the client side even if it is disable on the server side. Willy
