probably be in the hundreds or thousands to be effective without affecting
slightly bogus servers. It is also possible to only kill connections when the
CPU usage crosses a certain level, by using "tune.glitches.kill.cpu-usage".
+ Note that a graceful close is attempted at 75% of the configured threshold by
+ advertising a GOAWAY for a future stream. This ensures that a slightly faulty
+ connection will stop being used after some time without risking to interrupt
+ ongoing transfers.
See also: tune.h1.fe.glitches-threshold, bc_glitches, and
tune.glitches.kill.cpu-usage
probably be in the hundreds or thousands to be effective without affecting
slightly bogus clients. It is also possible to only kill connections when the
CPU usage crosses a certain level, by using "tune.glitches.kill.cpu-usage".
+ Note that a graceful close is attempted at 75% of the configured threshold by
+ advertising a GOAWAY for a future stream. This ensures that a slightly non-
+ compliant client will have the opportunity to create a new connection and
+ continue to work unaffected without ever triggering the hard close thus
+ risking to interrupt ongoing transfers.
See also: tune.h1.be.glitches-threshold, fc_glitches, and
tune.glitches.kill.cpu-usage
h1_be_glitches_threshold : h1_fe_glitches_threshold;
h1c->glitches += increment;
- if (thres && h1c->glitches >= thres &&
- (th_ctx->idle_pct <= global.tune.glitch_kill_maxidle)) {
- h1c->flags |= H1C_F_ERROR;
- return 1;
+ if (unlikely(thres && h1c->glitches >= (thres * 3 + 1) / 4)) {
+ /* at 75% of the threshold, we switch to close mode
+ * to force clients to periodically reconnect.
+ */
+ h1c->h1s->flags = (h1c->h1s->flags & ~H1S_F_WANT_MSK) | H1S_F_WANT_CLO;
+
+ /* at 100% of the threshold and excess of CPU usage we also
+ * actively kill the connection.
+ */
+ if (h1c->glitches >= thres &&
+ (th_ctx->idle_pct <= global.tune.glitch_kill_maxidle)) {
+ h1c->flags |= H1C_F_ERROR;
+ return 1;
+ }
}
return 0;
}