> Am 25.08.2021 um 16:16 schrieb Yann Ylavic <ylavic....@gmail.com>:
>
> On Wed, Aug 25, 2021 at 4:04 PM Yann Ylavic <ylavic....@gmail.com> wrote:
>>
>> On Wed, Aug 25, 2021 at 3:56 PM ste...@eissing.org <ste...@eissing.org>
>> wrote:
>>>
>>> I could add that in the test config as header to a certain location.
>>>
>>> However, will all new connections get to new gen children once the
>>> new number has been spotted?
>>
>> Yes, that's guaranteed by the MPM which increases the gen number just
>> before creating new children (after having asked the old ones to
>> stop), no old child will ever be created with a new generation number.
>> ap_mpm_query(AP_MPMQ_GENERATION, &generation) within a child will
>> always return the one that was forked.
>
> Hmm, you asked for a different question actually, the new
> *connections* done after the gen bump are not guaranteed to be handled
> by a new gen child, because it may take some (short) time before the
> old gen listeners stop listening.
> There is no way to guarantee where connections will go in the first
> times of a restart I'm afraid.
> At least your test client can know whether it's handled by an old or
> new gen and drop the connection in the former case..
Thanks for confirming what I suspected. Concurrency is a bitch.
Hmm, hate to add timed waits here, as who knows how Travis will
work with those. Will experiment a bit.
