Paul Querna wrote:
On Thu, May 7, 2009 at 3:50 AM, jean-frederic clere <jfcl...@gmail.com> wrote:
Paul Querna wrote:
Hi,
There is lots of discussion about fixing mod_proxy and
mod_proxy_balancer, to try to make it do things that the APIs are just
broken for, and right now, it seems from the outside to be turning
into a ball of mud.
I think the right way to frame the discussion is, how should the API
optimally be structured -- then change the existing one to be closer
to it, rather than the barrage of incremental changes that seem to be
creating lots of cruft, and ending up with something that still
doesn't do what we want.
I think mod_proxy's decisions on what to proxy to, and where, should
be designed as a series of hooks/providers, specifically:
1) Provider for a list of backends -- This provider does nothing with
balancing, just provides a list of Backend Definition (preferably just
keep it apr_sockaddr_t?) that a Connection is able to use. -- Backend
status via multicast or other methods go here.
2) Provider that _sorts_ the list of backends. Input is a list,
output is a new ordered list. -- Sticky sesions go here, along with
any load based balancing.
3) Provider that given a Backend Definition, returns a connection.
(pools connections, or open new one, whatever) -- Some of the
proxy_util and massive worker objects go here.
So we have to store the whatever in order to reuse it, no?
How to we handle the removable of a backend? We need to query the first
provider from time to time and clean up our storage, no?
No reason to, just have a timeout on the connection pooler, after
awhile it drops to zero connections.
Do you plan to use a reslist for that? - If yes you need something more
to clean it : the timeout handling is called in apr_reslist_acquire() -
Cheers
Jean-Frederic
