On Tue, Dec 18, 2018 at 11:43:44AM +0100, Christopher Faulet wrote:
> Le 18/12/2018 à 00:32, PiBa-NL a écrit :
> > Hi List, Christopher,
> >
> > Seems like d94f877 causes timeout in a pretty 'basic' connection test
> > that transfers a little bit of data .?
> > Or at least attached test fails to complete for me..
> >
> > # top TEST ./PB-TEST/basic_connection.vtc TIMED OUT (kill -9)
> > # top TEST ./PB-TEST/basic_connection.vtc FAILED (120.236) signal=9
> >
> > Please can you take a look :) Thanks in advance.
> >
>
> Hi Pieter,
>
> I've run your reg-test and everything works find for me. But I'll try to do
> more test to reproduce your problem.
Sorry guys, we found it last evening with Olivier and I fixed it this
morning, but I forgot to mention it, it's normally fixed with this one :
commit 7ab99a302d37d3d39ee6c8094e3a0c154ce5896b
Author: Willy Tarreau <w...@1wt.eu>
Date: Tue Dec 18 09:15:43 2018 +0100
BUG/MEDIUM: stream-int: always clear CS_FL_WANT_ROOM before receiving
Commit d94f877cd ("BUG/MINOR: mux_pt: Set CS_FL_WANT_ROOM when count is
zero in rcv_buf() callback") triggered a pending issue with this flag,
which is that it's cleared too late and sometimes causes some Rx
transfers to stall. We need to clear it before attempting to receive
otherwise we may risk to see an earlier copy of the flag.
Note that it should probably be defined that this flag could be purged
on each invocation of mux->rcv_buf(), which would make sense.
No backport is needed.
Please note that a few other issues affecting the H2 mux have been fixed
recently so it makes sense to rebase on the latest master right now.
On another note, aside the occasional HTTP 400 that were reported on
haproxy.org, we've had no single crash nor memory leak since saturday.
I've updated to dev11 this morning after 2 full more days, so I'm much
more confident in what we have right now and I'm planning on releasing
tomorrow after the last polishing (and my last minute bugs of course).
Cheers,
Willy
