On Wed, Aug 26, 2015 at 3:32 AM, Daniel Ruggeri <drugg...@primary.net> wrote: > On 8/25/2015 10:11 AM, Jim Jagielski wrote: >> Again, if the slotmem exists and is persisted, the assumption >> is that THAT is what the admin wants, and when Apache restarts, >> THAT is the running config they desire. If there are changes >> to the reverse proxy setup, the assumption must be we are >> starting from scratch; There are, iirc, a number of places where >> these kinds of checks are done. Trying to somehow "merge" a just-changed >> file config and a running config (based on an older file config >> with dynamic changes) is nasty and tough to do correctly. > > This is a common problem with serialization. The persisted config is > serialized data of what is in memory. It can only represent the > "version" of the conf file that created it. If you change the conf, > deserialization should fail because there could be other material > changes that might get in the way. > > I'm +1 on the idea that using bgrowth space to add stuff via > conf+graceful restart should be avoided.
Just to be precise ( and maybe give this change a very last chance :p ), this commit does not use arbitrary bgrowth (or growth) space for conf+graceful restarts. The reused slots are still strictly checked against the item_size (unchanged), such that they are garanteed to contain balancers (or members) of the vhost, not any other slot-able object. That's only the check on item_num which is relaxed to verify that it is *greater or equal* to the number of newly loaded balancers (or members), whereas the original check was *strictly equal* here too. My point is that this commit doesn't introduce any issue wrt arbitrary/unrelated/corrupted slots' reuse on restart, we are really talking about free space available strictly for balancers (or members) via the balancer-manager (and the config-file, hopefully). This means that an admin using the balancer-manager (UI) sees the changes, is able to manage all the original or reloaded balancers (or members), and can still add new ones if the slots are not full. IOW, this commit looks compatible (and useful), to me... OTOH, forbidding "compatible" changes via the config-file looks quite unusual (most people configure httpd via the config-file only, I guess). But hey, I'm not the community :)
