From: Willy Tarreau Date: Sun, 23 Dec 2018 19:43:58 +0000 (+0100) Subject: BUG/MEDIUM: mux-h2: mark that we have too many CS once we have more than the max X-Git-Tag: v2.0-dev1~330 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a87546624369ef94546907d90a17da9c985399fd;p=thirdparty%2Fhaproxy.git BUG/MEDIUM: mux-h2: mark that we have too many CS once we have more than the max Since commit f210191 ("BUG/MEDIUM: h2: don't accept new streams if conn_streams are still in excess") we're refraining from reading input frames if we've reached the limit of number of CS. The problem is that it prevents such situations from working fine. The initial purpose was in fact to prevent from reading new HEADERS frames when this happens, and causes some occasional transfer hiccups and pauses with large concurrencies. Given that we now properly reject extraneous streams before checking this value, we can be sure never to have too many streams, and that any higher value is only caused by a scheduling reason and will go down after the scheduler calls the code. This fix must be backported to 1.9 and possibly to 1.8. It may be tested using h2spec this way with an h2spec config : while :; do h2spec -o 5 -v -t -S -k -h 127.0.0.1 -p 4443 http2/5.1.2 done --- diff --git a/src/mux_h2.c b/src/mux_h2.c index 03c900da10..6ae04f4a39 100644 --- a/src/mux_h2.c +++ b/src/mux_h2.c @@ -299,7 +299,7 @@ static inline void h2c_restart_reading(const struct h2c *h2c) /* returns true if the connection has too many conn_streams attached */ static inline int h2_has_too_many_cs(const struct h2c *h2c) { - return h2c->nb_cs >= h2_settings_max_concurrent_streams; + return h2c->nb_cs > h2_settings_max_concurrent_streams; } /* Tries to grab a buffer and to re-enable processing on mux . The h2c