truncated responses

From: Adam Fritzler <mid#bittorrent.com>
Date: Thu, 10 Jan 2008 15:29:46 -0600 (CST)

Hi guys,

I've been running haproxy in production for several months, and it's been great. However, recently I discovered a problem with responses of a certain size being truncated.

curl -sfv 'http://xxx/x'

* About to connect() to xxx port nnnn
*   Trying n.n.n.n... connected
* Connected to xxx port nnnn

> GET /x HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5
> Host: xxx:nnnn
> Accept: */*
>

< HTTP/1.0 200 OK
< Content-Length: 6104
< Content-Type: text/plain
< Connection: close

transfer closed with 1876 bytes remaining to read * Closing connection #0

Note the warning from curl about "transfer closed with 1876 bytes remaining to be read". Indeed, The output file ends up being only 4228 bytes. This happens reliably for responses 6-8kb in size, but not for small responses or responses significantly larger. (I assume this is some sort of timing issue and that's just happens to be where the boundary falls, not anything related to that number of bytes specifically.)

tcpdump shows that the backend is sending the complete response, but haproxy is sending RST to the backend, and FIN to the client. The haproxy log shows a successful "- - ----" in the logs.

Has anyone seen this before?

I can seemingly reliably 'fix' it by recompiling without epoll support and using traditional poll. I'm running 1.3.13.1 in production, but I just tried with 1.3.14.1, and the behavior is the same -- works with poll, fails with epoll (sepoll). However, with 1.3.14.1 I did not use USE_MY_EPOLL, as that did not compile on my test box.

Thanks!
asf. Received on 2008/01/10 22:29