Re: HTTP Request still gets response from the server with weight 0 and src persistence

2013-05-29 Thread Godbach

Hi Baptiste

Thanks for your replying.

I am using the balance roundrobin algorithm and sticking on src, not the 
the balance source algorithm. The configuration has been presented in my 
first mail as below:


  backend pool
  balance roundrobin.
  stick-table type ip size 200k expire 600s
  stick on src
  server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
 slowstart 0s
  server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
 slowstart 0s


Best Regards,
Godbach

On 2013/5/29 13:35, Baptiste wrote:

Hi Godbach,

Before reading HAProxy source code, it worths reading its
configuration guide for the options you use.
IE, the balance source algorithm would tell you that:

  This algorithm is static by default, which means that changing a
server's weight on the fly will have no effect, but this can be
changed using hash-type.

Please update your configuration following the recommandation above
and let us know your feedback.

Baptiste



On Wed, May 29, 2013 at 5:22 AM, Godbach nylzhao...@gmail.com wrote:

Hi, all

It is expected that new http request will not get response from the
server of which weight was changed to 0. It cannot work well with
persistence on src but work well without the persistence in lastest
snapshot.

There are two servers in my backend, and persistence on src ip has been
enabled in backend. The configuration in backend as below:

 backend pool
 balance roundrobin.
 stick-table type ip size 200k expire 600s
 stick on src
 server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
slowstart 0s
 server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
slowstart 0s

During continuous http requset with the same client, the stick table as
below:
 # table: pool, type: ip, size:204800, used:1
 0x17d2284: key=172.22.16.250 use=0 exp=599095 server_id=1
Then I set weight of server 1 to 0 use command as below:
 set weight pool/1 0
And I get the weight of server 1 with command:
 get weight pool/1
The result is
 0 (initial 1)
So I think I have set the weight of sever1 to 0 successfully. But the
response still comes from server 1 which server 2 is expected. And the
stick table keeps the same.

I review the code of process_sticking_rules() in session.c. The codes
when server is found as below:

1403 ptr = stktable_data_ptr(rule-table.t, ts,
STKTABLE_DT_SERVER_ID);
1404 node =
eb32_lookup(px-conf.used_server_id, stktable_data_cast(ptr, server_id));
1405 if (node) {
1406 struct server *srv;
1407
1408 srv = container_of(node, struct server,
conf.id);
1409 if ((srv-state  SRV_RUNNING) ||
1410 (px-options  PR_O_PERSIST) ||
1411 (s-flags  SN_FORCE_PRST)) {
1412 s-flags |= SN_DIRECT | SN_ASSIGNED;
1413 s-target = srv-obj_type;
1414 }
1415 }
1416 }
1417 stktable_touch(rule-table.t, ts, 1);

Line 1409 used (srv-state  SRV_RUNNING) to check the server status.
If I used srv_is_usable() to instead such as below:
-if ((srv-state  SRV_RUNNING) ||
+if (srv_is_usable(srv-state, srv-eweight) ||

The new request will get response from server 2 once the weight of
server 1 is set to 0. But it seems to be just a workaround.

Since the manual of haproxy about 'set weight' says that:
A typical usage of this command is to disable a server during an update
by setting its weight to zero.

I am wondering that whether the flag SRV_RUNNING of server should be
cleared or not when its weight is set to 0.

--
Best Regards,
Godbach






--
Best Regards,
Godbach



Re: HTTP Request still gets response from the server with weight 0 and src persistence

2013-05-29 Thread Baptiste
AH, sorry, my mistake.
I read your mail too quickly.

Baptiste

On Wed, May 29, 2013 at 9:18 AM, Godbach nylzhao...@gmail.com wrote:
 Hi Baptiste

 Thanks for your replying.

 I am using the balance roundrobin algorithm and sticking on src, not the the
 balance source algorithm. The configuration has been presented in my first
 mail as below:


  backend pool
  balance roundrobin.
  stick-table type ip size 200k expire 600s
  stick on src
  server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
 slowstart 0s
  server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
 slowstart 0s


 Best Regards,
 Godbach


 On 2013/5/29 13:35, Baptiste wrote:

 Hi Godbach,

 Before reading HAProxy source code, it worths reading its
 configuration guide for the options you use.
 IE, the balance source algorithm would tell you that:

   This algorithm is static by default, which means that changing a
 server's weight on the fly will have no effect, but this can be
 changed using hash-type.

 Please update your configuration following the recommandation above
 and let us know your feedback.

 Baptiste



 On Wed, May 29, 2013 at 5:22 AM, Godbach nylzhao...@gmail.com wrote:

 Hi, all

 It is expected that new http request will not get response from the
 server of which weight was changed to 0. It cannot work well with
 persistence on src but work well without the persistence in lastest
 snapshot.

 There are two servers in my backend, and persistence on src ip has been
 enabled in backend. The configuration in backend as below:

  backend pool
  balance roundrobin.
  stick-table type ip size 200k expire 600s
  stick on src
  server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
 slowstart 0s
  server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
 slowstart 0s

 During continuous http requset with the same client, the stick table as
 below:
  # table: pool, type: ip, size:204800, used:1
  0x17d2284: key=172.22.16.250 use=0 exp=599095 server_id=1
 Then I set weight of server 1 to 0 use command as below:
  set weight pool/1 0
 And I get the weight of server 1 with command:
  get weight pool/1
 The result is
  0 (initial 1)
 So I think I have set the weight of sever1 to 0 successfully. But the
 response still comes from server 1 which server 2 is expected. And the
 stick table keeps the same.

 I review the code of process_sticking_rules() in session.c. The codes
 when server is found as below:

 1403 ptr = stktable_data_ptr(rule-table.t, ts,
 STKTABLE_DT_SERVER_ID);
 1404 node =
 eb32_lookup(px-conf.used_server_id, stktable_data_cast(ptr,
 server_id));
 1405 if (node) {
 1406 struct server *srv;
 1407
 1408 srv = container_of(node, struct server,
 conf.id);
 1409 if ((srv-state  SRV_RUNNING) ||
 1410 (px-options  PR_O_PERSIST) ||
 1411 (s-flags  SN_FORCE_PRST)) {
 1412 s-flags |= SN_DIRECT | SN_ASSIGNED;
 1413 s-target = srv-obj_type;
 1414 }
 1415 }
 1416 }
 1417 stktable_touch(rule-table.t, ts, 1);

 Line 1409 used (srv-state  SRV_RUNNING) to check the server status.
 If I used srv_is_usable() to instead such as below:
 -if ((srv-state  SRV_RUNNING) ||
 +if (srv_is_usable(srv-state, srv-eweight) ||

 The new request will get response from server 2 once the weight of
 server 1 is set to 0. But it seems to be just a workaround.

 Since the manual of haproxy about 'set weight' says that:
 A typical usage of this command is to disable a server during an update
 by setting its weight to zero.

 I am wondering that whether the flag SRV_RUNNING of server should be
 cleared or not when its weight is set to 0.

 --
 Best Regards,
 Godbach




 --
 Best Regards,
 Godbach



Re: HTTP Request still gets response from the server with weight 0 and src persistence

2013-05-29 Thread Godbach

Hi Baptiste

It doesn't matter. :-)

When the weight of server is set to 0 with the balance roundrobin 
algorithm,  srv-eweight is update  to 0 and

fwrr_update_server_weight() (lb_fwrr.c) will be called  as below:

static void fwrr_update_server_weight(struct server *srv)
{
...
old_state = srv_is_usable(srv-prev_state, srv-prev_eweight);
new_state = srv_is_usable(srv-state, srv-eweight);

if (!old_state  !new_state) {
srv-prev_state = srv-state;
srv-prev_eweight = srv-eweight;
return;
}
else if (!old_state  new_state) {
fwrr_set_server_status_up(srv);
return;
}
else if (old_state  !new_state) {
fwrr_set_server_status_down(srv);
return;
}
...
}

Since srv-eweight is 0, new_state should be also 0, then 
fwrr_set_server_status_down() will be called.
At the end the server will be remove from weight tree by 
fwrr_dequeue_srv() and lb_tree by fwrr_remove_from_tree().
But the srv-state has not been updated, still keeps in SRV_RUNNING. As 
a result, when the same server is selected by

sticking rules, it will be used again.



AH, sorry, my mistake.
I read your mail too quickly.

Baptiste

On Wed, May 29, 2013 at 9:18 AM, Godbach nylzhao...@gmail.com wrote:

Hi Baptiste

Thanks for your replying.

I am using the balance roundrobin algorithm and sticking on src, not the the
balance source algorithm. The configuration has been presented in my first
mail as below:



  backend pool
  balance roundrobin.
  stick-table type ip size 200k expire 600s
  stick on src
  server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
slowstart 0s
  server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
slowstart 0s


Best Regards,
Godbach


On 2013/5/29 13:35, Baptiste wrote:

Hi Godbach,

Before reading HAProxy source code, it worths reading its
configuration guide for the options you use.
IE, the balance source algorithm would tell you that:

   This algorithm is static by default, which means that changing a
server's weight on the fly will have no effect, but this can be
changed using hash-type.

Please update your configuration following the recommandation above
and let us know your feedback.

Baptiste



On Wed, May 29, 2013 at 5:22 AM, Godbach nylzhao...@gmail.com wrote:

Hi, all

It is expected that new http request will not get response from the
server of which weight was changed to 0. It cannot work well with
persistence on src but work well without the persistence in lastest
snapshot.

There are two servers in my backend, and persistence on src ip has been
enabled in backend. The configuration in backend as below:

  backend pool
  balance roundrobin.
  stick-table type ip size 200k expire 600s
  stick on src
  server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
slowstart 0s
  server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
slowstart 0s

During continuous http requset with the same client, the stick table as
below:
  # table: pool, type: ip, size:204800, used:1
  0x17d2284: key=172.22.16.250 use=0 exp=599095 server_id=1
Then I set weight of server 1 to 0 use command as below:
  set weight pool/1 0
And I get the weight of server 1 with command:
  get weight pool/1
The result is
  0 (initial 1)
So I think I have set the weight of sever1 to 0 successfully. But the
response still comes from server 1 which server 2 is expected. And the
stick table keeps the same.

I review the code of process_sticking_rules() in session.c. The codes
when server is found as below:

1403 ptr = stktable_data_ptr(rule-table.t, ts,
STKTABLE_DT_SERVER_ID);
1404 node =
eb32_lookup(px-conf.used_server_id, stktable_data_cast(ptr,
server_id));
1405 if (node) {
1406 struct server *srv;
1407
1408 srv = container_of(node, struct server,
conf.id);
1409 if ((srv-state  SRV_RUNNING) ||
1410 (px-options  PR_O_PERSIST) ||
1411 (s-flags  SN_FORCE_PRST)) {
1412 s-flags |= SN_DIRECT | SN_ASSIGNED;
1413 s-target = srv-obj_type;
1414 }
1415 }
1416 }
1417 stktable_touch(rule-table.t, ts, 1);

Line 1409 used (srv-state  SRV_RUNNING) to check the server status.
If I used srv_is_usable() to instead such as below:
-if ((srv-state  SRV_RUNNING) ||
+if (srv_is_usable(srv-state, srv-eweight) ||

The new request will get response from server 2 once the weight of
server 1 is set to 0. But it seems to be just a workaround.

Since the manual of haproxy about 'set weight' says that:
A typical usage of this command is to disable 

Re: HTTP Request still gets response from the server with weight 0 and src persistence

2013-05-29 Thread Baptiste
Actually, this is the purpose of dropping a weight to 0: being able to
maintain sticky sessions.
If you want to shutdown rudely your server, preventing everybody to
access it, use the disable keyword.

Baptiste


On Wed, May 29, 2013 at 5:55 PM, Godbach nylzhao...@gmail.com wrote:
 Hi Baptiste

 It doesn't matter. :-)

 When the weight of server is set to 0 with the balance roundrobin algorithm,
 srv-eweight is update  to 0 and
 fwrr_update_server_weight() (lb_fwrr.c) will be called  as below:

 static void fwrr_update_server_weight(struct server *srv)
 {
 ...
 old_state = srv_is_usable(srv-prev_state, srv-prev_eweight);
 new_state = srv_is_usable(srv-state, srv-eweight);

 if (!old_state  !new_state) {
 srv-prev_state = srv-state;
 srv-prev_eweight = srv-eweight;
 return;
 }
 else if (!old_state  new_state) {
 fwrr_set_server_status_up(srv);
 return;
 }
 else if (old_state  !new_state) {
 fwrr_set_server_status_down(srv);
 return;
 }
 ...
 }

 Since srv-eweight is 0, new_state should be also 0, then
 fwrr_set_server_status_down() will be called.
 At the end the server will be remove from weight tree by fwrr_dequeue_srv()
 and lb_tree by fwrr_remove_from_tree().
 But the srv-state has not been updated, still keeps in SRV_RUNNING. As a
 result, when the same server is selected by
 sticking rules, it will be used again.



 AH, sorry, my mistake.
 I read your mail too quickly.

 Baptiste

 On Wed, May 29, 2013 at 9:18 AM, Godbach nylzhao...@gmail.com wrote:

 Hi Baptiste

 Thanks for your replying.

 I am using the balance roundrobin algorithm and sticking on src, not the
 the
 balance source algorithm. The configuration has been presented in my
 first
 mail as below:


   backend pool
   balance roundrobin.
   stick-table type ip size 200k expire 600s
   stick on src
   server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn
 0
 slowstart 0s
   server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn
 0
 slowstart 0s

 Best Regards,
 Godbach


 On 2013/5/29 13:35, Baptiste wrote:

 Hi Godbach,

 Before reading HAProxy source code, it worths reading its
 configuration guide for the options you use.
 IE, the balance source algorithm would tell you that:

This algorithm is static by default, which means that changing a
 server's weight on the fly will have no effect, but this can be
 changed using hash-type.

 Please update your configuration following the recommandation above
 and let us know your feedback.

 Baptiste



 On Wed, May 29, 2013 at 5:22 AM, Godbach nylzhao...@gmail.com wrote:

 Hi, all

 It is expected that new http request will not get response from the
 server of which weight was changed to 0. It cannot work well with
 persistence on src but work well without the persistence in lastest
 snapshot.

 There are two servers in my backend, and persistence on src ip has been
 enabled in backend. The configuration in backend as below:

   backend pool
   balance roundrobin.
   stick-table type ip size 200k expire 600s
   stick on src
   server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn
 0
 slowstart 0s
   server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn
 0
 slowstart 0s

 During continuous http requset with the same client, the stick table as
 below:
   # table: pool, type: ip, size:204800, used:1
   0x17d2284: key=172.22.16.250 use=0 exp=599095 server_id=1
 Then I set weight of server 1 to 0 use command as below:
   set weight pool/1 0
 And I get the weight of server 1 with command:
   get weight pool/1
 The result is
   0 (initial 1)
 So I think I have set the weight of sever1 to 0 successfully. But the
 response still comes from server 1 which server 2 is expected. And the
 stick table keeps the same.

 I review the code of process_sticking_rules() in session.c. The codes
 when server is found as below:

 1403 ptr = stktable_data_ptr(rule-table.t, ts,
 STKTABLE_DT_SERVER_ID);
 1404 node =
 eb32_lookup(px-conf.used_server_id, stktable_data_cast(ptr,
 server_id));
 1405 if (node) {
 1406 struct server *srv;
 1407
 1408 srv = container_of(node, struct
 server,
 conf.id);
 1409 if ((srv-state  SRV_RUNNING) ||
 1410 (px-options  PR_O_PERSIST) ||
 1411 (s-flags  SN_FORCE_PRST)) {
 1412 s-flags |= SN_DIRECT |
 SN_ASSIGNED;
 1413 s-target = srv-obj_type;
 1414 }
 1415 }
 1416 }
 1417 stktable_touch(rule-table.t, ts, 1);

 Line 1409 used (srv-state  SRV_RUNNING) to check the 

Re: HTTP Request still gets response from the server with weight 0 and src persistence

2013-05-29 Thread Godbach

Hi Baptiste

Yeah, I got it. Thank you very much for your explanation.

Best Regards,
Godbach


Actually, this is the purpose of dropping a weight to 0: being able to
maintain sticky sessions.
If you want to shutdown rudely your server, preventing everybody to
access it, use the disable keyword.

Baptiste





HTTP Request still gets response from the server with weight 0 and src persistence

2013-05-28 Thread Godbach
Hi, all

It is expected that new http request will not get response from the
server of which weight was changed to 0. It cannot work well with
persistence on src but work well without the persistence in lastest
snapshot.

There are two servers in my backend, and persistence on src ip has been
enabled in backend. The configuration in backend as below:

backend pool
balance roundrobin.
stick-table type ip size 200k expire 600s
stick on src
server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
slowstart 0s
server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
slowstart 0s

During continuous http requset with the same client, the stick table as
below:
# table: pool, type: ip, size:204800, used:1
0x17d2284: key=172.22.16.250 use=0 exp=599095 server_id=1
Then I set weight of server 1 to 0 use command as below:
set weight pool/1 0
And I get the weight of server 1 with command:
get weight pool/1
The result is
0 (initial 1)
So I think I have set the weight of sever1 to 0 successfully. But the
response still comes from server 1 which server 2 is expected. And the
stick table keeps the same.

I review the code of process_sticking_rules() in session.c. The codes
when server is found as below:

1403 ptr = stktable_data_ptr(rule-table.t, ts,
STKTABLE_DT_SERVER_ID);
1404 node =
eb32_lookup(px-conf.used_server_id, stktable_data_cast(ptr, server_id));
1405 if (node) {
1406 struct server *srv;
1407
1408 srv = container_of(node, struct server,
conf.id);
1409 if ((srv-state  SRV_RUNNING) ||
1410 (px-options  PR_O_PERSIST) ||
1411 (s-flags  SN_FORCE_PRST)) {
1412 s-flags |= SN_DIRECT | SN_ASSIGNED;
1413 s-target = srv-obj_type;
1414 }
1415 }
1416 }
1417 stktable_touch(rule-table.t, ts, 1);

Line 1409 used (srv-state  SRV_RUNNING) to check the server status.
If I used srv_is_usable() to instead such as below:
-if ((srv-state  SRV_RUNNING) ||
+if (srv_is_usable(srv-state, srv-eweight) ||

The new request will get response from server 2 once the weight of
server 1 is set to 0. But it seems to be just a workaround.

Since the manual of haproxy about 'set weight' says that:
A typical usage of this command is to disable a server during an update
by setting its weight to zero.

I am wondering that whether the flag SRV_RUNNING of server should be
cleared or not when its weight is set to 0.

-- 
Best Regards,
Godbach



Re: HTTP Request still gets response from the server with weight 0 and src persistence

2013-05-28 Thread Baptiste
Hi Godbach,

Before reading HAProxy source code, it worths reading its
configuration guide for the options you use.
IE, the balance source algorithm would tell you that:

 This algorithm is static by default, which means that changing a
server's weight on the fly will have no effect, but this can be
changed using hash-type.

Please update your configuration following the recommandation above
and let us know your feedback.

Baptiste



On Wed, May 29, 2013 at 5:22 AM, Godbach nylzhao...@gmail.com wrote:
 Hi, all

 It is expected that new http request will not get response from the
 server of which weight was changed to 0. It cannot work well with
 persistence on src but work well without the persistence in lastest
 snapshot.

 There are two servers in my backend, and persistence on src ip has been
 enabled in backend. The configuration in backend as below:

 backend pool
 balance roundrobin.
 stick-table type ip size 200k expire 600s
 stick on src
 server 1 10.128.7.1:80 id 1 cookie srv1 weight 1 maxconn 0
 slowstart 0s
 server 2 10.128.7.2:80 id 2 cookie srv2 weight 1 maxconn 0
 slowstart 0s

 During continuous http requset with the same client, the stick table as
 below:
 # table: pool, type: ip, size:204800, used:1
 0x17d2284: key=172.22.16.250 use=0 exp=599095 server_id=1
 Then I set weight of server 1 to 0 use command as below:
 set weight pool/1 0
 And I get the weight of server 1 with command:
 get weight pool/1
 The result is
 0 (initial 1)
 So I think I have set the weight of sever1 to 0 successfully. But the
 response still comes from server 1 which server 2 is expected. And the
 stick table keeps the same.

 I review the code of process_sticking_rules() in session.c. The codes
 when server is found as below:

 1403 ptr = stktable_data_ptr(rule-table.t, ts,
 STKTABLE_DT_SERVER_ID);
 1404 node =
 eb32_lookup(px-conf.used_server_id, stktable_data_cast(ptr, server_id));
 1405 if (node) {
 1406 struct server *srv;
 1407
 1408 srv = container_of(node, struct server,
 conf.id);
 1409 if ((srv-state  SRV_RUNNING) ||
 1410 (px-options  PR_O_PERSIST) ||
 1411 (s-flags  SN_FORCE_PRST)) {
 1412 s-flags |= SN_DIRECT | SN_ASSIGNED;
 1413 s-target = srv-obj_type;
 1414 }
 1415 }
 1416 }
 1417 stktable_touch(rule-table.t, ts, 1);

 Line 1409 used (srv-state  SRV_RUNNING) to check the server status.
 If I used srv_is_usable() to instead such as below:
 -if ((srv-state  SRV_RUNNING) ||
 +if (srv_is_usable(srv-state, srv-eweight) ||

 The new request will get response from server 2 once the weight of
 server 1 is set to 0. But it seems to be just a workaround.

 Since the manual of haproxy about 'set weight' says that:
 A typical usage of this command is to disable a server during an update
 by setting its weight to zero.

 I am wondering that whether the flag SRV_RUNNING of server should be
 cleared or not when its weight is set to 0.

 --
 Best Regards,
 Godbach