[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haproxy
Subject:    =?UTF-8?B?UmU6IGluIHVyaSBiYWxhbmNlLCBo?= =?UTF-8?B?dHRwLWtlZXAtYWxpdmUgYnJva2Vu?=
From:       Seri <seri0528 () naver ! com>
Date:       2014-04-30 9:21:40
Message-ID: 5ad8d4279e82111738cebf6ed1cd3f1 () cweb11 ! nm ! nhnsystem ! com
[Download RAW message or body]

[Attachment #2 (text/plain)]

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.bonte@free.fr>; 
Cc: "Seri"<seri0528@naver.com>; "Lukas Tribus"<luky-37@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






[prev in list] [next in list] [prev in thread] [next in thread]