]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: peers: also limit the number of incoming updates
authorWilly Tarreau <w@1wt.eu>
Thu, 15 May 2025 13:41:50 +0000 (15:41 +0200)
committerWilly Tarreau <w@1wt.eu>
Thu, 15 May 2025 14:57:21 +0000 (16:57 +0200)
commitf2d7aa8406912ee20dab4deba83c184bcdde5056
treef578474d71ec0baeda4dc730a804204d08b2f6a9
parent098a5e5c0b9e6821c03945295dd1350e5d834eb3
BUG/MEDIUM: peers: also limit the number of incoming updates

There's a configurable limit to the number of messages sent to a
peer (tune.peers.max-updates-at-once), but this one is not applied to
the receive side. While it can usually be OK with default settings,
setups involving a large tune.bufsize (1MB and above) regularly
experience high latencies and even watchdogs during reloads because
the full learning process sends a lot of data that manages to fill
the entire buffer, and due to the compactness of the protocol, 1MB
of buffer can contain more than 100k updates, meaning taking locks
etc during this time, which is not workable.

Let's make sure the receiving side also respects the max-updates-at-once
setting. For this it counts incoming updates, and refrains from
continuing once the limit is reached. It's a bit tricky to do because
after receiving updates we still have to send ours (and possibly some
ACKs) so we cannot just leave the loop.

This issue was reported on 3.1 but it should progressively be backported
to all versions having the max-updates-at-once option available.
src/peers.c