tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Date Thu, 10 May 2001 20:06:36 GMT

I'll try to implement the Java side as you go with the C changes,
unless someone else volunteers ( jasper is taking more than 
I expected, and xalan has a release planned in few weeks ).

BTW, we'll need to discuss about the Java side - so
optimizations on the "lower" level would work on any container. 

At minimum we need MessageBytes or equivalent, MimeHeaders or equivalent 
( i.e. recyclable, low overhead, etc ), and a simple Request object that
can be easily adapted to TC3.3 and TC4.0.

This is not the "easiest" solution - from my point of view the easisest
would be to just write the Ajp14Interceptor and use the existing and
optimized 3.3 infrastructure. ( and use a reimplementation of the protocol
for 4.0 - using their low-level objects ). 


On Thu, 10 May 2001, GOMEZ Henri wrote:

> Find attached the modified AJP14 proposal which include 
> the remarks and request from the list.
> Nota :
> The launch of Tomcat JVM by the mod_jk/jakarta-connector 
> is not covered since we speak here only about protocol.
> That feature is something asked by many JServ users and
> may be added later in the native part, at least in 
> Apache 1.3/2.0 mode. I'm not sure how it can be done
> when using IIS or NES.
> The automatic context update was an interesting subject 
> and how we can have these kind of admin informations raised
> more questions than answers.
> Opening alternate sockets (control socket) we'll load more
> the web-server with more opened sockets :
> on forked environnement (ie Apache 1.3), 2 x forked (1 data + 1 admin)
> on threaded environnement (ie Apache 2.0), 1 x forked (x threaded data + 1
> admin)
> A solution could be to use the URGENT DATA mode of TCP/IP socket but I'm not
> sure it's supported now in JDK 1.1/1.2/1.3....
> Another solution is to delay the automatic update mode.
> AJP14 have provision on NEGOCIATION phase to disactivate this feature.
> But we still need to know when a context is DOWN and later UP.
> * A lazy solution could be to have the servlet engine drop all 
>   AJP connections at each update of context (UP/DOWN). 
>   The web servlet will have then to re-open the connection and
>   will received the UPDATED context list.
> * Another solution will be having the servlet engine sending
>   a 'Context XXX Down' reply when the user send a request against
>   a DOWN context. The servlet engine could then route the 
>   request to another engine (in LB mode), or to indicate 
>   the failure (in simple servlet engine mode). 
>   And when a context is marked DOWN, we need to know when it's UP again.
>   Brute mode : 
>   the web-server continue to forward the requests to the servlet engine,
>   and if it receive the 'Context XXX Down', it try another route.
>   Clean mode :
>   the web-server send a 'Context XXX Status' request, check if the reply is
>   'Context XXX Up', and if still down, try another route. This mode could be
>   tuned. ie for a down context, ask for status each 10 or 50 requests.
> The context UP/DOWN is really a rare case, and we mustn't spend to much time
> in handling this type of event. The protocol must keep its speed.
> Another feature I'd like to have in mod_jk/jakarta-connector and present in
> mod_jserv
> is the backup mode :
> - In standard mode, a request is routed to only one servlet-engine (using a
> know worker).
> - In load balancing mode, a request is sent to a pool of servlet-engine,
> using a load
>   factor.
> - We miss a backup mode, where all requests goes allways to the same servlet
> engine 
>   until the connection is broken (maybe the remote engine is down or network
> link 
>   closed). We define then one (or more) alternate engines to handle
> requests. 
>   In that mode, the web-servlet will try to detect later if the principal
> servlet
>   engine is up each N requests (or after M seconds...)
> -
> Henri Gomez                 ___[_]____
> EMAIL :        (. .)                     
> PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

View raw message