Bug 58934 - mod_proxy initial BalancerMember settings not applied to just that Proxy Balancer on startup
Summary: mod_proxy initial BalancerMember settings not applied to just that Proxy Bala...
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_balancer (show other bugs)
Version: 2.2.31
Hardware: Other Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2016-01-29 01:16 UTC by Earle Ake
Modified: 2018-11-07 21:08 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Earle Ake 2016-01-29 01:16:44 UTC
We have multiple Proxy Balancers setup using the same BalancerMembers but different URLs in the ProxyPass statements.  On initial startup, if mod_proxy finds one BalancerMember with some initial settings, those carry over to all BalancerMembers regardless of the Proxy Balancer as long as the host:port match.  If you hit the status page, you can adjust individual BalancerMembers accordingly.

Here is an example:

<Location /a>
        Order allow,deny
        Allow from all
        <LimitExcept GET POST>
                Deny from all
        </LimitExcept>
        ProxyPass balancer://a_Cluster/some_url
        ProxyPassReverse balancer://a_Cluster/some_url
</Location>

<Proxy balancer://a_Cluster>
  BalancerMember http://node1.com loadfactor=1 status=D
  BalancerMember http://node2.com loadfactor=1
  ProxySet lbmethod=byrequests
</Proxy>

<Location /b>
        Order allow,deny
        Allow from all
        <LimitExcept GET POST>
                Deny from all
        </LimitExcept>
        ProxyPass balancer://b_Cluster/some_other_url
        ProxyPassReverse balancer://b_Cluster/some_other_url
</Location>

<Proxy balancer://b_Cluster>
  BalancerMember http://node1.com loadfactor=1
  BalancerMember http://node2.com loadfactor=1
  ProxySet lbmethod=byrequests
</Proxy>

<Location /c>
        Order allow,deny
        Allow from all
        <LimitExcept GET POST>
                Deny from all
        </LimitExcept>
        ProxyPass balancer://c_Cluster/yet_another_url
        ProxyPassReverse balancer://c_Cluster/yet_another_url
</Location>

<Proxy balancer://c_Cluster>
  BalancerMember http://node1.com loadfactor=1
  ProxySet lbmethod=byrequests
</Proxy>

We would like to have the first BalancerMember in 'a_Cluster' come up disabled but the others using the same host and port to be enabled in the other LoadBalancers.

When Apache starts, you get the following:

LoadBalancer Status for balancer://a_cluster
Worker URL	Route	RouteRedir	Factor	Set	Status	Elected	To	From
http://node1.com			1	0	Dis	0	0	0
http://node2.com			1	0	Ok	0	0	0

LoadBalancer Status for balancer://b_cluster
Worker URL	Route	RouteRedir	Factor	Set	Status	Elected	To	From
http://node1.com			1	0	Dis	0	0	0
http://node2.com			1	0	Ok	0	0	0

LoadBalancer Status for balancer://c_cluster
Worker URL	Route	RouteRedir	Factor	Set	Status	Elected	To	From
http://node1.com			1	0	Dis	0	0	0


So even though only the first LoadBalancer had the first Worker URL set for disabled, all that match the host:port are all set disabled.  This does the same thing if you try and use status=H as well.

This also happens if you use 'ibset'.

Using 'factor' only sets the one for that LoadBalancer as I would expect.
Comment 1 Jim Jagielski 2016-07-07 17:57:22 UTC
Mixing balancer and members can be problematic. We do provide the *Inherit commands to make better sense of it all, but this mostly devolves into a configuration issue.
Comment 2 William A. Rowe Jr. 2018-11-07 21:08:48 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.