On Mon, Apr 15, 2019 at 12:46:05PM -0400, Richard Russo wrote:
> After the weekend, the test machine looks fine. Thanks!
Thank you for this positive feedback, Richard, much appreciated!
Willy
After the weekend, the test machine looks fine. Thanks!
--
Richard Russo
to...@enslaves.us
On Fri, Apr 12, 2019, at 10:33 AM, Richard Russo wrote:
> Thank you; I had missed the context from 1.9.6. I've updated my test
> machine and will report back on Monday (or earlier, if it runs into
>
Thank you; I had missed the context from 1.9.6. I've updated my test machine
and will report back on Monday (or earlier, if it runs into trouble)
--
Richard Russo
to...@enslaves.us
On Fri, Apr 12, 2019, at 4:17 AM, Olivier Houchard wrote:
> Hi,
>
> On Fri, Apr 12, 2019 at 08:37:10AM +0200
Hi,
On Fri, Apr 12, 2019 at 08:37:10AM +0200, Maciej Zdeb wrote:
> Hi Richard,
>
> Those patches from Olivier (in streams) are related to my report from
> thread "[1.9.6] One of haproxy processes using 100% CPU", but as it turned
> out it wasn't a single bug and issue is not entirely fixed yet.
>
Hi Richard,
Those patches from Olivier (in streams) are related to my report from
thread "[1.9.6] One of haproxy processes using 100% CPU", but as it turned
out it wasn't a single bug and issue is not entirely fixed yet.
Currently I'm testing some additional patches from Olivier which hopefully
f
It seems that after applying 39cc020af, if a stream gets the SI_FL_ERR flag,
process_stream can keep going back to redo around stream.c:line 2503:
if (si_f->state == SI_ST_DIS || si_f->state != si_f_prev_state ||
si_b->state == SI_ST_DIS || si_b->state != si_b_prev_state ||
((si_f->flags
6 matches
Mail list logo
