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 --
smime.p7s
Description: S/MIME Cryptographic Signature
