dd9b366919
As seen in GH issue #1770, peers synchronization do not cope well with
very large buffers because by default the only two reasons for stopping
the processing of updates is either that the end was reached or that
the buffer is full. This can cause high latencies, and even rightfully
trigger the watchdog when the operations are numerous and slowed down
by competition on the stick-table lock.
This patch introduces a limit to the number of messages one may send
at once, which now defaults to 200, regardless of the buffer size. This
means taking and releasing the lock up to 400 times in a row, which is
costly enough to let some other parts work.
After some observation this could be backported to 2.6. If so, however,
previous commits "BUG/MEDIUM: applet: fix incorrect check for abnormal
return condition from handler" and "BUG/MINOR: applet: make the call_rate
only count the no-progress calls" must be backported otherwise the call
rate might trigger the looping protection.
(cherry picked from commit
|
||
---|---|---|
.. | ||
design-thoughts | ||
internals | ||
lua-api | ||
51Degrees-device-detection.txt | ||
acl.fig | ||
architecture.txt | ||
close-options.txt | ||
coding-style.txt | ||
configuration.txt | ||
cookie-options.txt | ||
DeviceAtlas-device-detection.txt | ||
gpl.txt | ||
haproxy.1 | ||
intro.txt | ||
lgpl.txt | ||
linux-syn-cookies.txt | ||
lua.txt | ||
management.txt | ||
netscaler-client-ip-insertion-protocol.txt | ||
network-namespaces.txt | ||
peers-v2.0.txt | ||
peers.txt | ||
proxy-protocol.txt | ||
queuing.fig | ||
regression-testing.txt | ||
seamless_reload.txt | ||
SOCKS4.protocol.txt | ||
SPOE.txt | ||
WURFL-device-detection.txt |