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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
|