Re: [Bug 60956] Event MPM listener thread may get blocked by SSL shutdowns

[Luca Toscano <to...@gmail.com>]

Hi Yann and Ruediger,

2c from a mpm-event newbie inline:

2017-06-30 13:33 GMT+02:00 Yann Ylavic <yl...@gmail.com>:

> On Fri, Jun 30, 2017 at 1:20 PM, Ruediger Pluem <rp...@apache.org> wrote:
> >
> > On 06/30/2017 12:18 PM, Yann Ylavic wrote:
> >>
> >> IMHO mod_ssl shoudn't (BIO_)flush unconditionally in
> >> modssl_smart_shutdown(), only in the "abortive" mode of
> >> ssl_filter_io_shutdown().
> >
> > I think the issue starts before that.
> > ap_prep_lingering_close calls the pre_close_connection hook and modules
> that are registered
> > to this hook can perform all sort of long lasting blocking operations
> there.
> > While it can be argued that this would be a bug in the module I think
> the only safe way
> > is to have the whole start_lingering_close_nonblocking being executed
> by a worker thread.
>

This makes a lot of sense and I agree, but at the same time I feel that it
would be really great not to move lingering close responsibilities away
from the listener. As far as we know mod_ssl is the only one that shows
this "buggy" behavior, would it make sense to attempt to "fix it" now and
postpone the decision about pushing start_lingering_close_nonblocking to a
worker thread?


> Correct, that'd be much simpler/safer indeed.
> We need a new SHUTDOWN state then, right?
>

IIUC in each case that the listener calls start_lingering_close_nonblocking
we'd need to set the connection to SHUTDOWN, check if there is a free
worker and push2worker the connection to it right?

Thanks!

Luca