On Tue, Nov 10, 2015 at 12:04 PM, Laurent Senta <[email protected]>
wrote:
> Hi there,
> I think there's a bug in how HAProxy handles timeout, that'd be great if
> you can confirm or help me figure out what I do wrong:
>
> Basically: if a server timeout happens on a keep-alive connection, haproxy
> does not write a 504 response before closing the socket.
>
I am able to reproduce this behavior too. I tried a few versions of haproxy
all the way back to 1.4.0 and they all did this.
The general way to reproduce is:
1) open tcp connection
2) make request that completes before 'timeout server' / 'timeout client'
3) make request that does NOT complete before 'timeout server' on same tcp
connection
The second request gets no response and the connection is just closed. If
the same request (#3) is made on a new tcp connection that did not have a
previously successful response, the response is a 504 and not the silently
closed connection.
The haproxy.cfg I'm using is
global
maxconn 4096
defaults
mode http
timeout connect 5s
timeout client 450ms
timeout server 450ms
listen http
bind :8000
server slowserv 127.0.0.1:8002
And 'slowserv' simply sleeps for the amount of time requested through a
query string parameter.
Note that curl and httpclient it seems is not good to test in this
situation because both do retry the request that receives an empty response
-- even if that request was a POST.
I'm able to see the successful and empty-responses using wget like this by
forcing wget to not retry (only try once). In these cases, the backend will
take 0.4 seconds and 0.5 seconds to respond (respectively). The timeout
server is configured to strike at 0.45 seconds.
$> wget --tries 1 -O /dev/null "http://127.0.0.1:8000/?0.4"; "
http://127.0.0.1:8000/?0.5";
>
> This leads python to fail with a serious BadStatusLineError instead of a
> simple http error.
> And Ruby to retry potentially non-idempotent methods.
>
> Here's a basic setup to reproduce the error:
> https://gist.github.com/lsenta/1d33c6a01c07b32ac18a
>
> I've also had some help by meineerde on irc, here's the haproxy logs with
> a ruby client doing the same request:
> https://gist.github.com/meineerde/87a571c57369d322dae0#gistcomment-1617687
>
>
In case there is some confusion, the comment about "6 gets instead of 5" is
due to the ruby httpclient or curl retrying on that end and is not being
re-tried by haproxy.
> I've seen this behavior with v.1.6.2, 1.5.15 and 1.6.0
>
and several 1.5.x, 1.4.26, 1.4.6, and 1.4.0 all the same.
-Bryan
