Graham Leggett wrote:
The reason I want to focus on dynamic cluster is that it does have a direct impact on the config format and code.
But only after you've chosen how this dynamic config is going to work.
Right now httpd does not have a concept of dynamic config, and although adding such a capability would be nice in the future it's a big change with a (likely) long timeframe. I don't think people want to wait that long :)
So the alternative in the mean time is to make the communication between httpd and tomcat dynamic, so as to get the httpd people used to the idea that dynamic config is a good thing. :)
Httpd already has some support for that - .htaccess for example - and there are quite a few efforts to provide nice UI for apache config.
That's the other side of "dynamic configuration" - it's not only about
large cluster support, but also about beeing friendly to automatic config tools. Programatically editing httpd.conf ( with all the Includes and tricks ) is not trivial.
One example - it would be better to use a syntax where the actual list of hosts in a cluster is stored in a separate file, that can be rewritten independently of httpd.conf ( like htpasswd ).
You're assuming that the tomcat admin has access to this config file, which is often not going to be the case. If you have to update a file on the httpd server, it's virtually no different to updating a file on the httpd server and issuing a graceful restart, and we already have that now.
Well, this is an excelent point that I forgot to make :-)
Yes, one of the most important benefits of having this dynamic config is that you _don't_ need direct access and editing of the httpd.conf. If the data about the cluster is by default stored in a file ( and without the Include tricks ), then it becomes possible to have the changes made using some program - either as a result of negotiation and tomcat JMX pushing new settings, or using config scripts, etc.
What dynamic updates need to do is to auto-learn about the environment that it is in. And to do this, there is no better place to find out the info about a server cluster than from a member of that server cluster.
Ideally tomcat should be able to pass to httpd info like "hey, there is a new server in the pool, and it's called foo" or "do me a favour, I'm being taken out of the pool, so don't send me any new requests".
That's a good solution. It assumes tomcat handles all configuration.
It also assumes the "master" tomcat instances ( those that apache knows about when it starts up ) are up most of the time, so apache will allways be able to bootstrap.
Regardless of how the config info is communicated - negotiation, out of band, etc - it does help to have the cluster info outside of httpd.conf, in an easy to parse and generate file, and keep it updated.
If you can sometimes rewrite the code - the config format is very hard to change after people get used to. A lot in httpd.conf is from ncsa days. So for the stuff we add to mod_proxy - I think it is very important to think twice about where we want to go.
The idea of the static config in httpd.conf is firmly entrenched, and will take a while to dislodge. If we minimise the config in httpd, and put relevant dynamic config inside server.xml and/or the tomcat management app instead (and have httpd autodetect the status as it goes) we would have a really powerful dynamic system.
Ok, I can live with that :-).
httpd.conf is great because so many people are familiar with it. But in those google days, you can have 1000s of servers in a cluster. I don't know how this bootstraping mechanism can scale and if it is flexible enough.
Again - it can't hurt too much to keep cluster info in a separate simple file. It opens the way to a lot of scripting, tool support, config pushes, etc.
BTW - even tomcat, with all the JMX, still has some problems supporting persistence for the dynamic changes. I know Remy made a lot of improvements on saving server.xml, but I don't think it is as smooth as it can be. And IMO part of the problem is the config file format ( and
all the features and complexity that are part of it).
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
