BUG/MINOR: peers: local entries updates may not be advertised after r…

…esync

Since commit 864ac31 ("OPTIM: stick-tables: check the stksess without
taking the read lock"), when entries for a local table are learned from
another peer upon resynchro, and this is the only peer haproxy speaks to,
local updates on such entries are not advertised to the peer anymore,
until they eventually expire and can be recreated upon local updates.

This is due to the fact that ts->seen is always set to 0 when creating
new entry, and also when touch_remote is performed on the entry.

Indeed, while 864ac31 attempts to avoid useless updates, it didn't
consider entries learned from a remote peer. Such entries are exclusively
learned in peer_treat_updatemsg(): once the entry is created (or updated)
with new data, touch_remote is used to commit the change. However, unlike
touch_local, entries committed using touch_remote will not be advertised
to the peer from which the entry was just learned (otherwise we would
enter a looping situation). Due to the above patch, once an entry is
learned from the (unique) remote peer, 'seen' will be stuck to 0 so it
will never be advertised for its whole lifetime.

Instead, when entries are learned from a peer, we should consider that
the peer that taught us the entry has seen it.

To do this, let's set seen=1 in peer_treat_updatemsg() after calling
touch_remote(). This way, if we happen to perform updates on this entry,
it will be properly advertized to relevant peers. This patch should not
affect the performance gain documented in 864ac31 given that the test
scenario didn't involved entries learned by remote peers, but solely
locally created entries advertised to remote peers upon updates.

This should be backported in 3.0 with 864ac31.

src/peers.c

@@ -2062,6 +2062,12 @@ static int peer_treat_updatemsg(struct appctx *appctx, struct peer *p, int updt,
 	HA_RWLOCK_WRUNLOCK(STK_SESS_LOCK, &ts->lock);
 	stktable_touch_remote(table, ts, 1);
 
+	/* Entry was just learned from a peer, we want to notify this peer
+	 * if we happen to modify it. Thus let's consider at least one
+	 * peer has seen the update (ie: the peer that sent us the update)
+	 */
+	HA_ATOMIC_STORE(&ts->seen, 1);
+
 	if (wts) {
 		/* Start over the message decoding for wts as we got a valid stksess
 		 * for write_to table, so we need to refresh the entry with supported