Am 29.06.2021 um 14:31 schrieb Stefan Eissing:
Can comment really on the diff, but totally agree on the goal to minimize the 
unresponsive time and make graceful less disruptive.

So +1 for that.

+1 on the intention as well.

Not sure, whether that means people would need more headroom in the scoreboard (which would probably warrant a sentence in CHANGES or docs about that) or whether it just means the duration during which that headroom is used changes (which I wouldn't care about).

Thanks and regards,

Rainer

Am 28.06.2021 um 16:25 schrieb Yann Ylavic <ylavic....@gmail.com>:

When the MPM event/worker is restarting, it first signals the
children's processes to stop (via POD), then reload the configuration,
and finally start the new generation.

This may be problematic when the reload takes some time to complete
because incoming connections are no longer processed.
A module at day $job is loading quite some regexes and JSON schemas
for each vhost, and I have seen restarts take tens of seconds to
complete with a large number of vhosts. I suppose this can happen with
many RewriteRules too.

How about we wait for the reload to complete before stopping the old
generation, like in the attached patch (MPM event only for now,
changes in worker would be quite similar)?

This is achieved by creating the PODs and listeners buckets from a
generation pool (gen_pool), with a different lifetime than pconf.
gen_pool survives restarts and is created/cleared after the old
generation is stopped, entirely in the run_mpm hook, so the stop and
PODs and buckets handling is moved there (most changes are cut/paste).

WDYT?

Regards;
Yann.
<late_children_stop.diff>

Reply via email to