Re: modproxy load balancer

Theo E. Schlossnagle wrote:

> I am not sure how you invision the hooks being loaded at runtime.  If 
> they are their own modules, and just place themselves in the mod_proxy 
> chain, then I can piggyback on the the builtin module inititalization 
> functions.  Otherwise, I need someway to initialize my module.

Use the exact same model as is used now for proxy_http, proxy_ftp and 
proxy_connect. All three of these modules depend on hooks defined inside 
mod_proxy.

mod_dns, mod_sticky, mod_backhand, etc would simply be the 4th, 5th and 
6th module dependant on mod_proxy.

> I don't think the hook should be responsible for making the connection.  
> I think the hook should be solely responsible for listing, in order of 
> preference, where connections should be established.  In perl syntax:
> 
> [
>   { 'protocol' => 'http',
>     'IP' => '10.2.3.4',
>     'port' => '80' },
>   { 'protocol' => 'http',
>     'IP' => '10.2.3.8',
>     'port' => '8080' },
> ]
> 
> then mod_proxy should be responsible for taking that list and making 
> real and usable connections out of them.

Ok... my thinking was that it would simplify the notification to the 
backend of connection success or failure, but then doing it your way 
simplifies the backend module.

What we could do is have two hooks - the first gets given an 
URL/hostname/port, and returns a list of IPs to try.

Proxy then tries those IPs in turn.

Then a second hook is run saying "oh by the way, that IP address you 
gave me is down with status whatever, or it worked fine thanks".

If a connection failed, all the backend modules get to find out and can 
blacklist that server, whatever. If the connection succeeded, the time 
difference between the first and second hook would be the total time of 
connection, which could be used for loading stats.

Regards,
Graham
-- 
-----------------------------------------
[email protected]		"There's a moon
					over Bourbon Street
						tonight..."