tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOMEZ Henri" <>
Subject RE: mod_jk2 config
Date Thu, 07 Mar 2002 09:22:56 GMT
>> tomcat allready decode the information and could send them in
>> a simpler form to jk.
>Yes, but that creates some strange dependencies between configuring
>apache ( or the web server ) and running tomcat. 

The recurrent chicken&eggs problem :)

>Tomcat must be run first, and some magic must happen in complex
>cases when you have a pool of workers or want some tomcat instances
>to serve some applications, etc.

I agree and in case where only some tomcat instances serve some 
applications you have no others way that using vi/emacs to tune
your config :)

>It's quite complex and hard to control. I'm not saying we should
>do it, but I want to keep the 'config file' around because
>it's much easier to understand what's going on and fine tune it.
>In addition, it should be possible to generate the config
>from web.xml without having to run tomcat in a special mode,
>with a deploy tool. 

Or maybe, we could see if server.xml/web.xml could be merged in
a simple XML file which could be read and decoded by Webservers,
expat could do the works for Apache 1.3/2.0, I don't know for 
IIS/IPlanet. We could have to fallback in a properties like files,
which is sad in these XML days ;(

>> >I don't think we can support ajp14 for the first release of
>> >jk2, the goal is to replace the old connector with one
>> >with the same features, but better interfaces ( and easier 
>> >config, faster, etc ). We can add ajp14 later.
>> so ajp14 will be out of scope in jk2 initial release ?
>I think so. The refactoring is a big enough changes. If you want
>to work on it, I'm ok with having it - but I really don't think
>it's a good idea for the first release.

Let me say that I won't add features which may break initial release,
I'm the first users on productions servers of mod_jk and I don't want
client calls at 2 or 3 AM about problems :)

>I think mod_jk2 and mod_jk1 should be inter-changeable ( i.e. 
>same ajp13 protocol ) for easy transition, and the same
>on the java side. 
>In future versions we can add anything - the code is now
>much more modular and easier to extend. 

Yes, and we had all to relearn it :-)

>But see my previous mails on config - I think it would make
>sense to decouple the config from request forwarding even
>in ajp14 - i.e. leave the protocol unchanged, and use some
>handlers/servlets for ajp14-like autoconfig.


>BTW, I think unix-socket, jni, etc are also too much for the
>first release - if we want to have it this year :-)

Yep, but with JF help if should be more easy ... And may be 
some TC4 hackers like Remy ::)

>> >There are 2 problems:
>> >- it requires tomcat to be started before apache
>> He he, not necessary. 
>> 1) We could keep a copy on jk side of previously received autoconf 
>>    information and keep it till the tomcat came back to live.
>>    This information will be marked 'not verified' and at the 
>>    first request for a webapp, ie /examples/servlet/Hello, we 
>>    should first ask for autoconf refresh.
>Too complex. It can be done - the 'copy on the jk side' can be 
>the ( I assume we'll not invent another format).


>But with this, it may be better to have a separate protocol
>for updating the config on apache ( could be even WebDAV, we
>have a good client and server :-). 

WebDav on TC 3.3/4.0 ? Do you think we should add them to both
release ? Make sense, Remy, Craig, Larry, Bill, what's your opinion ?

>For refresh - again, I would prefer an explicit control, maybe
>using the status worker ( or a config worker ) - you can deploy a 
>new app on a dozen of workers, and then refresh the apache config.

Arg, you'll see we'll have to create a nice WEB interface for this.
IBM does a superb job in their AS/400 implementation with a cool
UI creating workers/in-process/out-process tomcats, something I'd like
to see in jk2 and may be via a new jkconfig worker....

>> 2) Did we have a in Apache/IIS/iPlanet a way to do the autoconf 
>>    query retry at a later time ? In Apache 1.3 (not sure for 2.0)
>>    each module is called when a request arrive, and we could retry
>>    at this time (delaying it a little), ie make a retry each 5/10s.
>And some users will see a "not found" instead of "temporary 
>try later". Plus complexity, not sure what to do for lb/multiple
>tomcats, etc.

Ok, let make it simple

>> >- it's very tricky to even describe how this would work in a 
>> >complex configuration ( multiple tomcats, multiple apache servers,
>> >etc). 
>> That's an interesting issue, and may be not so hard that we could
>> imagine. JkAutoMount examples worker just tell web-server that 
>> all request to webapp examples should be forwarded to a particular
>> worker. This worker could be a single tomcat or a cluster of tomcat
>> in lb mode (and in that case they should all have the same settings).
>Yes, but what if you add a webapp ? Which worker in the pool will
>be queried ? When ? 

If you have a pool of worker in a lb configuration, all tomcat have
the same configuration (clones). We may have to add the notion of 
master tomcat (jkconfig worker) in a tomcat pool. 

Let's imagine that this master tomcat is the one where new webapps
or webapp updates occurs. jk2 known all the companions tomcats in the
lb pool. We could use the jkconfig worker to grab the new/updated WAR,
maybe via WebDav, and then send the new/updated webapp to all 
tomcat in the pool. Each tomcat receiving the new/updated webapp will
then dynamically add/reload received webapp. I think everything is
ready on TC 3.3, what's about TC 4.x ?

Something to be added in ajp14 protocol ?

>Explicit control ( maybe with some helpers ) is far easier to do
>and describe for the first release, and as we get smarter we can
>automate more. 

Ok, one step for now.

>> Which make me think that time() call is a consuming task 
>> and I wonder if there is provision to a faster replacement
>> in Apache 1.3 / 2.0 (via APR) ?
>I think Apache has some time() function called ( so it can log the 
>total time ). We can use it, and call the system if we want to 
>tune our stuff ( but not in the default config, only if enabled 
>and maybe per uri )

I was thinking about a faster time() alternative, there was hacks
in Apache 1.3 done by a MIPS employee sometimes ago, hacks never
really reintroduced in Apache 1.3, but many where incorporated in
Apache 2.0. May be JF could told us more about this ?

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

View raw message