Hi, This issue is reproduced in this environment( frontend(http-keep-alive), backend(http-server-close) ). In this environment(frontend(http-server-close), backend(http-server-close)), this works well.
Regards, Seri -----Original Message----- From: "Willy Tarreau"<w...@1wt.eu> To: "Cyril Bonté"<cyril.bo...@free.fr>; Cc: "Seri"<seri0...@naver.com>; "Lukas Tribus"<luky...@hotmail.com>; "HAProxy"<haproxy@formilux.org>; Sent: 2014-04-30 (수) 18:10:04 Subject: Re: in uri balance, http-keep-alive broken Hi again, On Wed, Apr 30, 2014 at 07:59:11AM +0200, Willy Tarreau wrote: > > OK, this time I think I could understand your issue and reproduce it. > > The minimal setup I've used : > > defaults > > mode http > > > > listen test :80 > > balance url_param q > > hash-type consistent > > > > server s demo.1wt.eu:80 > > > > This was introduced between 1.5-dev22 and 1.5-dev23 with this commit : > > BUG/MEDIUM: http: don't start to forward request data before the connect > > http://haproxy.1wt.eu/git?p=haproxy.git;a=commit;h=80a92c02f478dc1b836e0c97c891875437fc54da > > > > Moreover, during my tests haproxy took 100% cpu after the second request > > was sent to the persistent connection. > > Ah that's very interesting. I remember another report of 100% CPU one or > two weeks ago that I don't think we could diagnose. > > > It's late now so I can't analyze it more precisely tonight but I think > > it can be easily fixed now. > > Yes, I'm taking care of this now. Thanks for the bisect! Unfortunately, I found no way to reproduce the issue, either with master nor with Seri's version (a631fc8). Cyril, could you please add a printf() inside the if MSGF_WAIT_CONN in http_request_forward_body() : printf("ra=%d req=%s res=%s reqf=%08x repf=%08x, reqb=%08x resb=%08x\n", !!(s->rep->flags & CF_READ_ATTACHED), http_msg_state_str(txn->req.msg_state), http_msg_state_str(txn->rsp.msg_state), txn->req.flags, txn->rsp.flags, s->req->flags, s->rep->flags); I suspect that some error condition is not properly handled when going to the missing_data block, but I can't imagine which one. Initially I thought it would be something like the READ_ATTACHED flag not being set on reused connections, but it is properly set, so I remain a bit confused. Willy
