why are we so focused on dynamic this dynamic that, there is nothing about mod_proxy that is dynamic, and instead of delaying the stability and release of a working mod_proxy with a load balancer, make it work, make it work well, then add fancy features. mod_jk2 became way to cluttered this exact way, and never got to the point of workability to the point where any user could configure it
just my $0.02 Filip -----Original Message----- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: Monday, July 26, 2004 11:30 AM To: [EMAIL PROTECTED] Subject: Re: Dynamic updates and Apache v2.0 First, by "dynamic updates" I mean changes to apache2 config that don't require a restart. For example, .htaccess files provide such a thing ( for a different area ). What updates ? There are several forms: 1. - add a new worker to a pool ( for example - expect big load, you buy more hardware, etc ). - gracefully remove a worker ( for upgrade for example ) - the implication is that sticky sessions will still go, no new sessions. - change parameters of a worker ( like balancing factors ). That may include advanced balancing. Note that for all this you don't actually need too much change on apache/mod_proxy - as long as you treat the "pool" as one entity, and maybe use a separate config file for the list of workers ( so you don't have to regenerate httpd.conf - which is quite difficult ). There are many ways to implement the communication between httpd processes and between apache and tomcat. 2. - add more webapps and virtual servers - for example in the case of an ISP. - reload webapps - that means some mappings and auth changes, in the case of tight integration you may want to have apache handle auth and mapping Costin Graham Leggett wrote: > Hi all, > > I am starting a new thread for this, as it seems to be an important > killer-app feature for any httpd v2.0 integration. > > People have said the config should be dynamically configurable - which > part of the config should be dynamically configurable? > > In other words, would any of these senarios make sense: > > - A potential pool of servers (IP address/port combinations) is defined, > and httpd gracefully handles the case where a server is "missing". > Adding a new server is as simple as starting it up on one of the > predefined ip/ports combinations. An admin might configure an entire > subnet as "tomcat servers", and then add and remove backend servers at > will. Easy to do, but a bit limiting. > > - httpd is informed via a special URL of updates to the servers on the > backend, a bit like the management app in tomcat. This functionality > might grow to being available to the whole httpd config. Being a URL, it > would be pretected by standard mechanisms like SSL and basic > authentication. Powerful, but a big change that will likely only appear > in httpd v2.1 or v2.2. > > - httpd polls the backend servers using the OPTIONS method (as was > recommended recently). In the info returned, httpd learns of the > intended weighting of the servers, whether a server needs to be removed > gracefully from the pool, or whether other servers have been added to > the pool and should be included in the config. Here httpd needs only to > be told about just one backend server, which will "seed" httpd with info > about all the other servers. > > Out of the above three the third option seems to make the most sense. > It's not very obtrusive, it can be used with backends other than tomcat. > Actually updating the server list and weightings can be done via the > tomcat management app, which already exists now (as opposed to a > theoritical management app for httpd). > > Thoughts? > > Regards, > Graham > -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
