Ok, brute-forced it a bit. The test suite now always does a stop/start cycle on config changes as reload now longer works reliably. Takes a bit more time, but not overly so on my machine.
Cheers, Stefan > Am 25.08.2021 um 16:22 schrieb ste...@eissing.org: > > > >> 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.
