> On Feb 2, 2018, at 9:42 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > >> Am 02.02.2018 um 15:25 schrieb Plüm, Rüdiger, Vodafone Group >> <ruediger.pl...@vodafone.com>: >> >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Jim Jagielski [mailto:j...@jagunet.com] >>> Gesendet: Freitag, 2. Februar 2018 15:15 >>> An: httpd <dev@httpd.apache.org> >>> Betreff: Re: New ServerUID directive >>> >>> Why? If it is designed to not change between restarts then >>> there are much easier ways to be unique, which it kinda >>> already is, considering the actual structs being used. >>> >>> Also, this seems like unnecessary admin overhead for the >>> webmaster... if there is a need for such an ID, httpd should >>> provide for it automagically and not require users to have >>> to config one. It seems like config-file fluff to me, IMO. >> >> +1. If the current ID used is not meeting our requirements, my first thought >> would be if we could improve it >> to meet them. > > Totally agree that inventing a new Directive is the last resort if we cannot > find a better solution. > > If I understand then concrete case here correctly, the admin makes frequent > config changes and *wants* the shared memory id to stay the same, so the shm > is re-used and not cleaned up or re-initialized. And our current > implementation generates new identifiers much to frequently bc the > line-number cheat was made to detect config changes?
I think that is correct, which implies, to me, the solution would be some mod_proxy_balancer Directive like "IgnoreConfigFileChanges" or something specific like that. But I am still confused if the above is actually what the issue is, hence my "resistance" for any modifications at all until the problem is crystal clear. If we can check, in a one-off test, that removing that line-number hack solves the "problem" then that is more easily handled by a specific use-case for balancer/slotmem. My 2c
