tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOMEZ Henri" <hgo...@slib.fr>
Subject RE: mod_jk2 config
Date Tue, 05 Mar 2002 19:23:35 GMT
>> >uri.servletName:/my.host.com:8080/examples/HelloW=HelloWorldServlet
>> 
>> Could we get these translation from web.xml forwarded by Ajp14 
>> autoconf feature ?
>
>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.

>The information can be passed to jk via ajp14 ( wire ), or 
>properties, or other methods.
>
>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 ?

>> >With this jk will pass the servlet name to tomcat and eliminate the
>> >second mapping, like mod_jserv did.
>> 
>> Why not just use :
>> 
>> JkAutoMount webapp worker
>> 
>> => get all mapping for a particular webapp for a worker
>
>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.

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

JkAutoMount examples worker without autoconf information should be 
seen like :

JkSet /examples/* worker

In first approach everything under /examples will be forwarded to
worker and autoconf will specify (reduce) which URI/MIME will be 
handled really.

>We'll add (back) this after we stabilize the code and release
>the first version ( and figure out how to do it ).

Ok

>BTW, I was thinking of separating the config protocol from 
>normal ajp - the config is clearly not perf. critical ( no need 
>for a binary protocol ). Instead of extending ajp13, we 
>can have a simple ajp13 request to 
>
>   /jk2/servlet/autoConf?webapp=/examples
>
>( done by a jk2 autoConfig worker ). That would return a 
>normal response, with the body beeing a properties file
>in the same format as the one generated.

Yes, may be easier to implement (what do you think about
TC3/TC4 developpers ?)

>The implementation is very simple ( most of the code
>already exists ), and would allow much easier programming,
>regular servlets - maybe with some container-specific code,
>for java ( like the manager or admin ), very little
>change in the C side. 

A big plus.

>> What about jk-status which should present state of jk connections
>> and informations ? 
>
>It's 'work in progress'. I want to get at least the basic things 
>we had in jserv - especially for lb and worker status, plus
>some of the 'stop sending requests to this lb worker', 
>'add/remove a lb worker to the pool'. 

good

>> Also are we agree in adding a REQUEST flag to LogLevel to be able 
>> to track the query/reply timestamp ?
>
>+1

And these informations could be also make available to jk-status,
which make it a perfect control-desk.

>In addition some mgmt info in all objects - how many requests
>were served with each worker ( a simple ++ ), total/average
>time, number of errors, etc. Some may be enabled by 
>default ( counters have minimal impact on perf. ), some
>with config ( if it requires calling system methods,
>like get time, etc ). 
>
>getProperty() in each jk2 object is supposed to allow 
>easy access to this information from the status worker
>or other means.

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

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


Mime
View raw message