+1
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 ).
Costin
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 : [EMAIL PROTECTED] (. .)
> PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
