On Wed, Jun 30, 2010 at 3:47 AM, Daniel Ruggeri <[email protected]> wrote:
> On 6/29/2010 9:17 PM, William A. Rowe Jr. wrote:
>>
>> Yet again, in class another student pointed out that the Enabled/Disabled
>> choice in mod_proxy_balancer totally ignores the concept of quiescing,
>> where we are taking a server offline, but continuing to serve those
>> requests targeted by session to that server.  Once the number of sessions
>> settles on something quite low, the user then takes that server offline
>> entirely and the remaining users are subjected to 'expired session'
>> results.
>>
>> A boolean Enabled/Disabled flag doesn't address this need.
>>
>> Does anyone feel like working on this feature, since those I had
>> previously approached didn't have all that much interest, or got
>> busy with other things?
>>
>>
>>
>
> William;
>   I actually wrote a patch in response to a submitted bug (48841) in April
> that will set the load factor to zero for a member. With a zero lbfactor,
> only items coming through with a sticky session are sent to that back end. I
> was hoping for comments from other devs about the method used, though,
> because I had to resort to a const (aka magic number) because of compiler
> oddness. In one specific case I can recall with the SUN C compiler, when
> lbfactor was not set, a check for lbfactor being equal to zero would return
> true... gcc did not replicate the same bug (null/undef is NOT 0 after all).
> This was only used during the configuration stage and the initialization of
> the balancer.
>
>   I hope this helps suit your needs and that I understood the question. If
> I'm on the right track, but there are qualms with the implementation, I'll
> happily adjust the work.
>
> Thanks
> --
> Daniel Ruggeri
>
>

As a reasonably heavy user of mod_proxy - all our web sites are
proxied through a pair of reverse proxies - would you be interested in
the problems we have encountered using it?

In particular, bug 45950 is symptomatic of our issues. We can't
adjust/tune our reverse proxy servers and gracefully restart, because
the proxy worker state is utterly mangled following a graceful
restart.
This means we must do a full restart to avoid mangling state, which in
turn means any balancer that has had its configuration dynamically
changed via balancer_manager will have its configuration reset to the
config on disk.

The usual result of this is that sysadmin A will restart the proxies,
unaware that sysadmin B has configured site S to be reverse proxied to
application server app2 rather than app1, as app1 is undergoing
maintenance and is down => we just broke one of our sites.

The other net result is that we are now loath to adjust/restart apache
on the proxy servers, since we must do a hard restart, disrupting any
sessions on that server. This is so onerous that we are now discussing
moving away from apache as a reverse proxy, and instead looking at
things like pound, varnish, perlbal.

This is a shame, as mod_proxy has many plus points - particularly that
it's apache underneath, with all the flexibility that allows, and the
mindshare that apache has already.

Cheers

Tom

Reply via email to