tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject [PROPOSAL AJP14] AJP13 Evolution - Second Pass
Date Thu, 10 May 2001 19:32:34 GMT
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 : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 


Mime
View raw message