]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: queues: Do not use pendconn_grab_from_px().
authorOlivier Houchard <ohouchard@haproxy.com>
Tue, 17 Dec 2024 14:39:21 +0000 (15:39 +0100)
committerOlivier Houchard <cognet@ci0.org>
Tue, 17 Dec 2024 15:05:44 +0000 (16:05 +0100)
commit111ea83ed4e13ac3ab028ed5e95201a1b4aa82b8
tree86a0a5e0af24ae006c02617451efb28a574a9f08
parentdc9ce9c26469e00ab71fe6387dbd13010d4930f0
BUG/MEDIUM: queues: Do not use pendconn_grab_from_px().

pendconn_grab_from_px() was called when a server was brought back up, to
get some streams waiting in the proxy's queue and get them to run on the
newly available server. It is very similar to process_srv_queue(),
except it only goes through the proxy's queue, which can be a problem,
because there is a small race condition that could lead us to add more
streams to the server queue just as it's going down. If that happens,
the server would just be ignored when back up by new streams, as its
queue is not empty, and it would never try to process its queue.
The other problem with pendconn_grab_from_px() is that it is very
liberal with how it dequeues streams, and it is not very good at
enforcing maxconn, it could lead to having 3*maxconn connections.
For both those reasons, just get rid of pendconn_grab_from_px(), and
just use process_srv_queue().
Both problems are easy to reproduce, especially on a 64 threads machine,
set a maxconn to 100, inject in H2 with 1000 concurrent connections
containing up to 100 streams each, and after a few seconds/minutes the
max number of concurrent output streams will be much higher than
maxconn, and eventually the server will stop processing connections.

It may be related to github issue #2744. Note that it doesn't totally
fix the problem, we can occasionally see a few more connections than
maxconn, but the max that have been observed is 4 more connections, we
no longer get multiple times maxconn.

have more outgoing connections than maxconn,
This should be backported up to 2.6.
src/server.c