Thanks for the reply guys,
after investigating the source code, it looks like this behavior is wanted.

I've been able to "fix it" by removing these two lines:

diff --git a/src/proto_http.c b/src/proto_http.c
index 2dcac06..d33b4a1 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -6125,8 +6125,6 @@ int http_wait_for_response(struct stream *s, struct
channel *rep, int an_bit)
                else if (rep->flags & CF_READ_TIMEOUT) {
                        if (msg->err_pos >= 0)

http_capture_bad_message(&s->be->invalid_rep, s, msg, msg->msg_state,
sess->fe);
-                       else if (txn->flags & TX_NOT_FIRST)
-                               goto abort_keep_alive;

                        s->be->be_counters.failed_resp++;
                        if (objt_server(s->target)) {

I traced back that change to:
http://git.haproxy.org/?p=haproxy-1.6.git;a=commit;h=6b726adb35d998eb55671c0d98ef889cb9fd64ab

I don't understand why it's saner to kill the connection and hide the 504
instead of clearly stating the error and let the application handle the
timeout.



On Wed, Nov 11, 2015 at 3:11 AM Tait Clarridge <t...@clarridge.ca> wrote:

> On Tue, Nov 10, 2015 at 7:32 PM, Bryan Talbot <bryan.tal...@ijji.com>
> wrote:
> > On Tue, Nov 10, 2015 at 12:04 PM, Laurent Senta <laurent.se...@gmail.com
> >
> > 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 believe this is the same behaviour that I submitted a patch (without
> a lot of context in the description) for in
> https://www.marc.info/?l=haproxy&m=141822428718492&w=4
>
> We have been running a patched version of 1.5.x with this applied in
> our environment for almost a year, which although it has a very
> specific use case and does not touch all the features of the project,
> has had zero issues with leaking sockets/memory (or segfaults).
>
>

Reply via email to