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]
