]> git.ipfire.org Git - thirdparty/haproxy.git/commit
[BUG] fix random pauses on last segment of a series
authorWilly Tarreau <w@1wt.eu>
Mon, 27 Jul 2009 18:08:06 +0000 (20:08 +0200)
committerWilly Tarreau <w@1wt.eu>
Mon, 27 Jul 2009 18:20:36 +0000 (20:20 +0200)
commitd28022b89415371dd7954656f33a13add283ea11
treec560c29385f2f6d30959557db462dc6ec3ede38d
parent9d4108b390dad70fae1456fac7cc8cd6de38e324
[BUG] fix random pauses on last segment of a series

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.
(cherry picked from commit c54aef3180c00abc5abe33136f4cfbaa1328bdb1)
src/stream_sock.c