Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v733)
In-Reply-To: <42FA1C13.4040407@apache.org>
References: <CF9DAD66-0910-44E5-B1CC-3B02BFF94A7E@jaguNET.com>
 <42FA1C13.4040407@apache.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <4EE0E554-53DE-4212-BA3D-93975EB7F652@jaguNET.com>
Content-Transfer-Encoding: 7bit
From: Jim Jagielski <jim@jaguNET.com>
Subject: Re: proxy balancer rework
Date: Wed, 10 Aug 2005 11:48:44 -0400
To: dev@httpd.apache.org


On Aug 10, 2005, at 11:24 AM, Mladen Turk wrote:

> Jim Jagielski wrote:
>
>> I've never been all that happy with the current setup in having
>> load balance methods be so hard coded into the proxy module. Adding
>> another method requires too many changes.
>>
>
> Right, but mod_proxy_balancer was not meant to be a generic
> placeholder for 'anything-you-may-ever-wish-to-balance', but
> rather just a module that can be used as reference for additional
> user specific balancer modules.
>
> Of course we can change the point of view, but I'm not sure if
> that would make sense. Perhaps some 'generic, fit-all' functions
> could be copied over to the util.c, as well as management things,
> but OTOH different load balancer may require different balancer
> management functionality.
>

I don't know what you mean... If I am using mod_proxy
with the balancer and I wish to add in a different
lb method, because the 2 bundled with Apache aren't
sufficient, then certainly providing a mechanism
to allow them to easily add such without requiring
code changes to the proxy and balancer modules make
sense. This is what the patch does.

Yeah, some could require substantial changes (proxy_worker_stat
might be too restrictive) but I can envision several that
would fit in quite nicely here. Heck, you could have
one that externally queries cpu utilization, and uses
that to determine the lbfactor, and this patch would
provide a nice framework with little or no impact.
Maybe adding some opaque structs to the worker and
balancer structs may be required later on...