Costin Manolache wrote:
Httpd already has some support for that - .htaccess for example
The trouble with .htaccess is that it only applies for data on the local filesystem. Url space created by other content handlers (such as proxy or ajp) is not covered.
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.
You keep coming back to "stored in a file". This file is stored where? On the httpd server? On the tomcat server?
If it's on the httpd server, then you're back to editing a file on the webserver, and here there is no point - if you're already on the httpd server editing files, then you already probably have the power to issue a graceful restart anyway, which reloads the httpd service gracefully without breaking connections or otherwise inconveniencing users.
If it's on the tomcat server, then how does httpd access the file? In band using either http or ajp? Out of band using SMB or NFS?
Then there is the issue of securing that file - obviously you don't want just anybody accessing it or changing it.
And then what if the httpd server is an appliance such as an SSL accelerator? No chance for a file there.
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.
This is easily solved by specifying multiple possible bootstrap servers in the httpd.conf file, and then making sure that at least one of those servers is available.
Big sites might even have a dedicated backend non-load-bearing tomcat server for this very purpose.
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.
100% true - which is why that info should probably be best kept within tomcat itself, and queried by httpd.
The tomcat server.xml file already contains a lot of info about load balancing. Duplicating it in a new external file just adds new complications that could most probably be solved using what we already have.
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.
Why wouldn't it be?
Remember a cluster and an httpd frontend will be connected to each other via a high speed network (typically). If tomcat says "I am part of a cluster, here have the DNS names of 1000 of my closest friends in the cluster" I see no reason why httpd would not be able to handle it gracefully.
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.
It adds the question of where this file lives, who will control access to it, etc. It doesn't sound like an elegant solution to me at all.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
