Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Sender: jfclere@vtxrm2.bcn.fsc.net
Message-ID: <3C8755D6.FF9E2ACF@fujitsu-siemens.com>
Date: Thu, 07 Mar 2002 12:58:14 +0100
From: jean-frederic clere <jfrederic.clere@fujitsu-siemens.com>
Reply-To: jfrederic.clere@fujitsu-siemens.com
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: mod_jk2 config
References: <BBDCA5B56D25F843A025AE850BA70F0636FA93@css8.slib.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

GOMEZ Henri wrote:
> 
> >> 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.
> 
> Ok
> 
> >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 ::)

I will try to help but the structure allows to add features easly.
I think it is better to make a release with only normal sockets and go for
unix-socket, jni... in a later step.
I need a little time for jakarta-commons-sandbox/daemon and mod_webapp ;-)

> 
> >> >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 jkurimap.properties ( I assume we'll not invent another format).
> 
> yes
> 
> >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
> >unavailable,
> >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 ?

A quick look in APR shows apr_time_now() is the APR call for time() and it calls
gettimeofday().

> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>