mirror of
http://git.haproxy.org/git/haproxy.git
synced 2026-02-23 03:33:35 +02:00
c54aef3180
During a direct data transfer from the server to the client, if the system did not have enough buffers anymore, haproxy would not enable write polling again if it could write at least one data chunk. Under normal conditions, this would remain undetected because the remaining data would be pushed by next data chunks. However, when this happens on the last chunk of a session, or the last in a series in an interactive bidirectional TCP transfer, haproxy would only start sending again when the read timeout was reached on the side it stopped writing, causing long pauses on some protocols such as SQL. This bug was reported by an Exceliance customer who generously offered to help us by sending large amounts of traces and running various tests on production systems. It is quite hard to trigger it but it becomes easier with a ping-pong TCP service which transfers random data sizes, with a modified version of send() able to send packets smaller than the average transfer size. A cleaner fix would imply only updating the write timeout when data transfers are *attempted*, not succeeded, but that requires more sensible code changes without fixing the result. It is a candidate for a later patch though.