Hi! 2016-07-19 11:26 GMT+02:00 Kay Fuchs <kabef...@gmail.com>: > i'm using a stick-table with HAProxy 1.6.7 on an active/standby > configuration like this: > > stick-table type ipv6 size 500k expire 60s peers hacluster store > gpc0,conn_cur,http_req_rate(10s),http_err_rate(10s) > http-request track-sc0 > > On the standby peer the table obviously shows wrong http_err_rates: > > 0xe6ce10: key=xxx use=0 exp=59598 gpc0=0 conn_cur=1 > http_req_rate(10000)=1 http_err_rate(10000)=346 > 0xe3ed80: key=xxx use=0 exp=58440 gpc0=0 conn_cur=1 > http_req_rate(10000)=27 http_err_rate(10000)=38841809 > > The active peer seems to behave as expected and shows very low error rates. > > I'm no programmer, but i think it has to do with "frqp->curr_tick" in > "peers.c" which seems to have the value "0" if the very first error > appears. This leads to sending "now_ms" to the peer. If i check > "frqp->curr_tick" before the encoding like > > if (frqp->curr_tick == 0) > frqp->curr_tick = now_ms; > > the error rates seems reasonable on the standby peer.
I think either the function "intencode" or "intdecode" in "peers.c" seems not to return the expected values. I've made a simple loop to compare the input for "intencode" with the outputs of "intdecode" for the encoded message. The first wrong encoded/decoded range of integers are 4336-4351. That might explain http://thread.gmane.org/gmane.comp.web.haproxy/27168 in combination with the sending of large integer "now_ms" reported above. Kay Fuchs
