> Am 25.08.2021 um 16:04 schrieb Yann Ylavic <ylavic....@gmail.com>:
>
> On Wed, Aug 25, 2021 at 3:56 PM ste...@eissing.org <ste...@eissing.org> wrote:
>>
>>
>>
>>> Am 25.08.2021 um 15:54 schrieb Yann Ylavic <ylavic....@gmail.com>:
>>>
>>> On Wed, Aug 25, 2021 at 3:37 PM ste...@eissing.org <ste...@eissing.org>
>>> wrote:
>>>>
>>>> Follow up: if I do a "time.sleep(2)" after each "apachectl" in my
>>>> test suite, it works fine.
>>>>
>>>> Speculating: my test suite does commonly a GET after a reload to
>>>> see if the reloaded server is responding. And then fires requests
>>>> against the new configuration.
>>>>
>>>> Now, if the server is always responding, the test sill get - sometimes -
>>>> send request to an old gen child which then answers incorrectly. So
>>>> I see 404 responses where a 200 should be as the config does not match.
>>>>
>>>> In this new world of always responding servers, when is a test suite
>>>> supposed to know that now the server will respond with the newly laoded
>>>> config?
>>>
>>> Maybe we could have access to the generation number
>>> (AP_MPMQ_GENERATION) in a variable like "MPM_GENERATION" which
>>> mod_headers could use to set in a response header?
>>> Or a test only module which does that specifically could be compiled
>>> by the framework and LoadModule'd?
>>
>> 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.
Thanks, I'll give this a shot.
Joe: as long as that is not solved, the tests will not be reliable, I'm afraid.
- Stefan
