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.
