tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: mod_jk2 config
Date Tue, 05 Mar 2002 20:54:56 GMT
On Tue, 5 Mar 2002, GOMEZ Henri wrote:

> >We should get these from web.xml - either extracted directly or
> >by extracting the info from tomcat. 
> 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. 

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.

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. 

> >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.

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. 

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

> >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 :-). 

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.

> 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 unavailable,
try later". Plus complexity, not sure what to do for lb/multiple
tomcats, etc.

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

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. 

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


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

View raw message