On Fri, Mar 25, 2016 at 01:53:50PM +0100, Willy Tarreau wrote:
> I think it's even different (but could be wrong) since Christian spoke
> about counters suddenly doubling. The issue you faced Sylvain which I
> still have no idea how to fix unfortunately is that the peers applet
> is not always woken up when a connection establishes on the other side
> and it may simply miss an event, resulting in everything remaining
> stable and appear frozen until the connection closes. Here it seems
> data are exchanged but incorrect. This one could be easier to reproduce
> however, we'll check.
OK I found it. Indeed it was easy to reproduce. The frequency counters
are sent as "now - freq.date", which is a positive age compared to the
current date. But on receipt, this age was *added* to the current date
instead of subtracted. So since the date was always in the future, they
were always expired if the activity changed side in less than the
counter's measuring period (eg: 10s).
I'm commiting this simple fix that you can apply to your tree for now.
Cheers,
Willy
diff --git a/src/peers.c b/src/peers.c
index c29ea73..9918dac 100644
--- a/src/peers.c
+++ b/src/peers.c
@@ -1153,7 +1153,7 @@ switchstate:
case
STD_T_FRQP: {
struct freq_ctr_period data;
-
data.curr_tick = tick_add(now_ms, intdecode(&msg_cur, msg_end));
+
data.curr_tick = tick_add(now_ms, -intdecode(&msg_cur, msg_end));
if (!msg_cur) {
/* malformed message */
appctx->st0 = PEER_SESS_ST_ERRPROTO;
