Hello,
I just experienced that maxconn can easily not work as expected and lead
to unavailable services. Take this example backend configuration of a
2.8.3 haproxy setup:
backend bk_example
balance first
server server1 192.168.4.1:8000 id 1 maxconn 10
server server2 192.168.4.2:8000 id 2 maxconn 10
server server3 192.168.4.3:8000 id 3 maxconn 10
...
Each server here is only able to handle 10 requests, if it receives more
requests it will just return an error. So usually the above
configuration works fine, server1 receives up to 10 connections, after
that connections are sent to server2, if also that has the maxconn limit
reached, server3 receives requests and so on.
So far so good. If haproxy however receives a SIGHUP because of some
reconfiguration, then all the connections to the backend servers are
kept alive but haproxy thinks that the servers have 0 connections and it
will send up to 10 new connections to backend servers, even if they
already had 10 connections, which are still active and still correctly
processed by haproxy. So each server receives up to 20 connections and
the backend servers just return errors in this case.
This is very unexpected and it looks like unintended behavior actually.
I also never heard about this and never read a warning note for such a
side effect when a haproxy reload is being done. Maybe a
server-state-file configuration might work around this problem but it
was not obvious till now that this is a requirement if maxconn is being
used. Can someone shed some light on this?
Thank you
Björn
