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
