BUG/MEDIUM: log: Properly handle client aborts in syslog applet
In the syslog applet, when there is no output data, nothing is performed and
the applet leaves by requesting more data. But it is an issue because a
client abort is only handled if it reported with the last bytes of the
message. If the abort occurs after the message was handled, it is ignored.
The session remains opened and inactive until the client timeout is being
triggered. It no such timeout is configured, given that the default maxconn
is 10, all slots can be quickly busy and make the applet unresponsive.
To fix the issue, the best is to always try to read a message when the I/O
handle is called. This way, the abort can be handled. And if there is no
data, we leave as usual.
This patch should fix the issue #2112. It must be backported as far as 2.4.
(cherry picked from commit 285aa40d352ae03e245c48333220b6f37ec74631)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 05c1eaf5fb92a750fead2fd77525c825da2d8f44)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit cc1d509cb1d9a7a3e8c7122f3ff46444a794f73c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 91a88866a1fcd853478c8797b9e4cc4f984984d4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
1 file changed