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.
I know - it was just an example, showing that apache is not completely statically configured, and there are use cases they considered important enough to support. Unfortunately this doesn't extend to url space.
You keep coming back to "stored in a file". This file is stored where? On the httpd server? On the tomcat server?
on httpd server. Right now the proposal ( or what I've seen ) is to define the workers in httpd.conf. I'm suggesting to have a separate file for workers, similar with htpasswd.
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.
Again, if you have 100s load-balanced servers - and multithreaded apache servers - gracefull restart is not a convenient option.
Just like you don't do a gracefull restart when you add a user in htpasswd or change a .htaccess file.
Then there is the issue of securing that file - obviously you don't want just anybody accessing it or changing it.
Same as htpasswd :-).
And then what if the httpd server is an appliance such as an SSL accelerator? No chance for a file there.
Well, that's an interesting case - so no httpd.conf either.
Most appliances do have some file system emulation BTW.
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.
I'm not sure I understand what you want to prove.
What is the problem with having the workers defined in a separate file ? Supporting the common case where no file system is available ?
Yes, you can keep a dedicated tomcat server to maintain the list and pass it to apache. It will still be in some file, and it will still need to be dynamically updated and maintained - you just multiply the points of failure ( but move the hard problems to someone else :).
It is true - it has the benefit of keeping apache side dumb and moving all logic to java - which actually makes sense.
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.
You're probably right. I'm starting to see your point.
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.
So basically you want to use tomcat as a config server for apache -
all cluster config handled on java side, and apache just pulls the list of workers and updates from the config server instead of having it in it's own config.
Fine - as long as we're not storing the cluster info in httpd.conf itself. I still think it may be easier to have it in a htpasswd-like file instead of getting it from a config server ( well, it is possible to use LDAP servers or similar stuff for config - the solution is proven, but it usually is more complicated than just a plain file ).
To wrap this up - my concern was mosly about storing the cluster info in httpd.conf directives. If people feel having it in a separate file is more difficult than getting it from a tomcat config server - it's fine.
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.
The question obviously remains, plus the network aspects of it :-)
I just hope you agree that having cluster info in httpd.conf is the worst possible solution - you have all the control access problems, you need to gracefully restart often, it is very hard to automate and use tools to manage it, etc.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
