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.
