tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: PROPOSAL: mod_jk2 autoconfig
Date Tue, 30 Apr 2002 14:53:52 GMT
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

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

> 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 ?) 


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message