Hello!
If haproxy can't send a request to the backend server, it will retry the same
backend 'retries' times waiting 1 second between retries, and if 'option
redispatch' is used, the last retry will go to another backend.
There is (I think very common) usage scenario when
1) all requests are independent of each other and all backends are equal, so
there is no need to try to route requests to the same backend (if it failed, we
will try dead one again and again while another backend could serve the request
right now)
2) there is response time policy for requests and 1 second wait time is just
too long (all requests are handled faster than 500ms and client software will
not wait any longer).
I propose to introduce new parameters in config file:
1) "redispatch always": when set, haproxy will always retry different backend
after connection to the first one fails.
2) Allow to override 1 second wait time between redispatches in config file
(including the value of 0 == immediate).
Right now I use the attached patch to overcome these restrictions. It is ugly
hack right now, but if you could include it into distribution in better form
with tuning via config file I think everyone would benefit from it.
Thanks.
--- session.c.orig 2012-11-22 04:11:33.000000000 +0400
+++ session.c 2012-11-22 16:15:04.000000000 +0400
@@ -877,7 +877,7 @@ static int sess_update_st_cer(struct ses
* bit to ignore any persistence cookie. We won't count a retry nor a
* redispatch yet, because this will depend on what server is selected.
*/
- if (objt_server(s->target) && si->conn_retries == 0 &&
+ if (objt_server(s->target) &&
s->be->options & PR_O_REDISP && !(s->flags & SN_FORCE_PRST)) {
sess_change_server(s, NULL);
if (may_dequeue_tasks(objt_server(s->target), s->be))
@@ -903,7 +903,7 @@ static int sess_update_st_cer(struct ses
si->err_type = SI_ET_CONN_ERR;
si->state = SI_ST_TAR;
- si->exp = tick_add(now_ms, MS_TO_TICKS(1000));
+ si->exp = tick_add(now_ms, MS_TO_TICKS(0));
return 0;
}
return 0;
