> On Feb 2, 2018, at 9:42 AM, Stefan Eissing <stefan.eiss...@greenbytes.de>
>> Am 02.02.2018 um 15:25 schrieb Plüm, Rüdiger, Vodafone Group
>>> -----Ursprüngliche Nachricht-----
>>> Von: Jim Jagielski [mailto:j...@jagunet.com]
>>> Gesendet: Freitag, 2. Februar 2018 15:15
>>> An: httpd <email@example.com>
>>> 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