On Wed, Jun 30, 2010 at 1:05 PM, Mark Watts <[email protected]> wrote: > A restart of httpd (graceful or otherwise) has no understanding that the > running config can be any different from that on disk. > > Indeed, how would httpd differentiate between a restart to reconfigure a > given balancer (which may itself have a different in-memory loadfactor) > or some other part of the server?
I believe that a graceful restart attempts to do this - it certainly applies BalancerMember state from before the restart to BalancerMembers after the restart. The problem is that it doesn't alway apply the state to the right member, eg adding additional members can result in the state of member b being applied to b'. Having said all that, it may not be trying to do that, and it is just coincidence that state is incorrectly applied post graceful restart, I have not looked at the code. > > One 'solution' may be to change the way you disable a balancer member > such that you change it in httpd.conf and do a graceful restart, > combined with the quiescence changes mentioned earlier so that balancer > members are withdrawn nicely. This then brings you into the problems with graceful restart when combined with balancer members. It isn't fun to be woken up in the middle of the night because a sysadmin has restarted the proxy, and all your balancer members have been set to disabled, because of incorrect state being applied to the member. > > I'd guess that the only true way to handle this problem is to somehow > compare the balancer configuration on disk with that in memory, and > restore each BalancerMember's loadfactor on restart if the > configurations match. If it is a graceful restart, > > I suspect, but have no proof, that other load balancer software has this > same issue. > Yes, this is the issue. In an ideal world, we want a balancer that allows these kinds of features: Add/configure vhosts without interrupting current sessions Disable/enable balancers dynamically Have state persisted across restarts Internal redirection: reproxying requests, controlled from the backend, eg send header 'X-Location: http://otherappserver/some_resource' - just a nice to have tbh. Apache falls short of those criteria (but only just!), and is a maintenance nightmare to do simple things like adding an additional vhost, since we must do a full restart, disrupting user sessions. Cheers Tom
