Yeah, ever since we started moving many of these params to shared memory, this has been broken. As such, even without the persist, using the balancer-manager to change params causes some unknown and un-seen interactions.
I propose that we close this bug in 2.4.x. On Sep 19, 2012, at 11:45 AM, Jim Jagielski <[email protected]> wrote: > The issue is that muddies the waters as far as "whose balancer > is this"... For example, let's assume you define balancer://foo > at the top level and it is inherited by vhost1 and vhost2. > > If you change a balancer setting in vhost1, should that change > be automatically made to the one in vhost2? Or is it specific > to vhost1? > > Personally, I feel that the inheritance is majorly wrong and a > major bug. Now that we are allowing realtime changes to these > params, we need to restrict them to per-server, which means > no inheritance. > > On Sep 19, 2012, at 10:45 AM, Tom Evans <[email protected]> wrote: > >> On Wed, Sep 19, 2012 at 3:34 PM, Jim Jagielski <[email protected]> wrote: >>> I cannot think of one good reason why we've been doing the below... >>> I any case, I think vhosts inheriting these structs is a pretty >>> nasty bug, as well as memory hog... >> >> Hi Jim >> >> Is one possible use case for this defining balancers outside of >> vhosts, and then using them in multiple vhosts? (Personally, I hate >> this feature, it clutters up unrelated balancer sets on >> balancer-manager). >> >> >> Cheers >> >> Tom >> >
