Costin Manolache wrote:
Well, you may keep the discussion separated, but the code will eventually be mixed.
Eventually, but keeping each thing logically separate makes it easy to see where one feature might impact another. The devil with this is in the details, and I don't want to see important points getting lost amidst the volume.
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. :)
If you look at tomcat5, jboss, etc - for dynamic configuration you need to design the software in a certain way. It's ok if the first versions will not have this feature, but every time you use pull to get config data, or set up some data structure - you need to think a bit how it will work with dynamic updates.
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.
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".
Tomcat might add special hop-by-hop X- headers, or the OPTIONS idea might work. httpd would then update the scoreboard with info about the current pool of servers dynamically.
Config of httpd would be as simple as
ProxyPass /myWebapp ajp://seedserver/myWebapp
The server seedserver could then tell httpd about all the other servers in the cluster dynamically. "seedserver" could resolve to one machine, or more than one machine.
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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
