On Tue, May 28, 2024 at 4:06 PM Stefan Eissing via dev
<dev@httpd.apache.org> wrote:
>
>
>
> > Am 28.05.2024 um 15:45 schrieb Yann Ylavic <ylavic....@gmail.com>:
> >
> > On Tue, May 28, 2024 at 12:47 PM Stefan Eissing via dev
> > <dev@httpd.apache.org> wrote:
> >>
> >>> Am 27.05.2024 um 14:08 schrieb Yann Ylavic <ylavic....@gmail.com>:
> >>>
> >>> Per our discussion the other day, if you want to avoid c1 connections
> >>> to be killed by mpm_event on high load in this case, I think you can
> >>> do this here:
> >>>
> >>> Index: modules/http2/h2_c1.c
> >>> ===================================================================
> >>> --- modules/http2/h2_c1.c (revision 1918003)
> >>> +++ modules/http2/h2_c1.c (working copy)
> >>> @@ -147,6 +147,7 @@ apr_status_t h2_c1_run(conn_rec *c)
> >>> && mpm_state != AP_MPMQ_STOPPING);
> >>>
> >>> if (c->cs) {
> >>> + c->clogging_input_filters = 0;
> >>> switch (conn_ctx->session->state) {
> >>> case H2_SESSION_ST_INIT:
> >>> case H2_SESSION_ST_IDLE:
> >>> @@ -159,6 +160,7 @@ apr_status_t h2_c1_run(conn_rec *c)
> >>> * See PR 63534.
> >>> */
> >>> c->cs->sense = CONN_SENSE_WANT_READ;
> >>> + c->clogging_input_filters = 1;
> >>> 03465}
> >>> break;
> >>> case H2_SESSION_ST_CLEANUP:
> >>> --
> >>>
> >>> c->clogging_input_filters = 1 will tell the MPM to always call
> >>> process_connection() hooks after the WRITE_COMPLETION state did the
> >>> poll(), rather than entering the (killable) keepalive state.
> >>>
> >>> Looks like the correct workaround with current mpm_event..
> >>
> >> Just so I get this right. It will return to processing after the
> >> write is done or after a POLLIN happened? In the first case, it
> >> will not have really a positive effect on worker allocations,
> >> seems to me.
> >
> > Yes, it will return to processing after POLLIN happens thanks to
> > CONN_SENSE_WANT_READ, even if there are pending output data.
> > But it's a really convoluted handling of POLLIN/POLLOUT in mpm_event,
> > with the need of that obscure c->clogging_input_filters..
> > So I just created https://github.com/apache/httpd/pull/448 to do that
> > better (and it includes the changes to h2_c1_run() too).
> > The plan could be to merge that to trunk and include it in your
> > backport proposal (if it works for you)?
> >
>
> Great!
Backport PR in https://github.com/apache/httpd/pull/449 ;)
Regards;
Yann.
