On Tue, 30 Apr 2002, GOMEZ Henri wrote: > >I think the current solution of generating configs on tomcat startup, > >or having tomcat send it's config to apache is wrong. > > when tomcats and httpd servers run on differents machines you need > to have a form of link between them, and that's why I proposed > autoconf to be added to ajp13 (I don't tell ajp14 to avoid confusion).
I know. However ( see my previous answer on this topic ) we should get apache to serve the static files - for performance, etc - and that would require the webapp to be on the apache machine anyway. And in the case you want one extra round-trip for each static page, it is still possible to install one small file for each app. The 'ctl' or 'status' workers are supposed to do exactly what you say - get status updates 'over the wire' ( but using HTTP - it's not performance critical and easier ) and eventually change and save the new conf ( save is implemented already in jk_config, but not used yet ). > I agree we have a sort of chicken and eggs problems here since httpd > servers need to know which tomcat are available to try to connect to > them to get the configuration. No chicken and egg here if the config is persistent. Similar with how JMX works - you change/add configs at any time during runtime, it saves the config, and next time you have what you configured, without requiring the JMX manager to be up and re-do the config. > httpd server should have a thread (or fork in AP 1.3) to listen > to incoming broadcast notification and determine if there is a > new tomcat in (or out) and contact newcomer to get its config > informations. In case of tomcat caming out, it should remove > references to the old tomcat. That would be the ctl handler, and the shm will allow each apache instances to get the message. I know there are other, more sophisticated solutions - but I prefer ( at least for the short term ) a plain HTTP and plain config file. Later we can implement 'broadcast' or other advanced solutions ( like using an LDAP server ?) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
