tree aa04c4743a6703743b745759a4f32053f9599638
parent d4f7e083aa984336151529b35bb97cecd53f71eb
author Christopher Faulet <cfaulet@haproxy.com> 1697436890 +0200
committer Amaury Denoyelle <adenoyelle@haproxy.com> 1698334209 +0200

BUG/MEDIUM: peers: Fix synchro for huge number of tables

The number of updates sent at once was limited to not loop too long to emit
updates when the buffer size is huge or when the number of sync tables is
huge. The limit can be configured and is set to 200 by default. However,
this fix introduced a bug. It is impossible to syncrhonize two peers if the
number of tables is higher than this limit. Thus by default, it is not
possible to sync two peers if there are more than 200 tables to sync.

Technically speacking, a teaching process is finished if we loop on all tables
with no new update messages sent. Because we are limited at each call, the loop
is splitted on several calls. However the restart point for the next loop is
always the last table for which we emitted an update message. Thus with more
tables than the limit, the loop never reachs the end point.

Worse, in conjunction with the bug fixed by "BUG/MEDIUM: peers: Be sure to
always refresh recconnect timer in sync task", it is possible to trigger the
watchdog because the applets may be woken up in loop and leave requesting
more room while its buffer is empty.

To fix the issue, restart conditions for a teaching loop were changed. If
the teach process is interrupted, we now save the restart point, called
stop_local_table. It is the last evaluated table on the previous loop. This
restart point is reset when the teach process is finished.

In additionn, the updates_sent variable in peer_send_msgs() was renamed to
updates to avoid ambiguities. Indeed, the variable is incremented, whether
messages were sent or not.

This patch must be backported as far as 2.6.

(cherry picked from commit 60e7116be0d01edc5117bb2c514c363e5cee7def)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>