Costin Manolache wrote:
1.
- add a new worker to a pool ( for example - expect big load, you buy more hardware, etc ).
- gracefully remove a worker ( for upgrade for example ) - the implication is that sticky sessions will still go, no new sessions.
- change parameters of a worker ( like balancing factors ). That may include advanced balancing.
Note that for all this you don't actually need too much change on apache/mod_proxy - as long as you treat the "pool" as one entity, and maybe use a separate config file for the list of workers ( so you don't have to regenerate httpd.conf - which is quite difficult ). There are many ways to implement the communication between httpd processes and between apache and tomcat.
Don't forget that in many cases Apache will be running on a machine entirely outside of your direct control - a good example would be a network appliance.
There are many options for httpd to connect to the backend, and for the backend to connect to httpd, but there are limitations imposed by the environment where httpd will be running. Reading a file on disk is one example (you mentioned .htaccess files) - changing the file on disk does not mean httpd is necessarily going to pick up the changes straight away, and this assumes the admin has disk access at all.
Whatever solution we start with needs to keep these limitations in mind.
2. - add more webapps and virtual servers - for example in the case of an ISP.
- reload webapps - that means some mappings and auth changes, in the case of tight integration you may want to have apache handle auth and mapping
Adding virtual servers requires an httpd config reload, this moves into the territory of having an httpd management app along the lines of the tomcat management app. Not a bad idea in itself, but a big project for httpd.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
