tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <>
Subject [AJP14l] Start reflexions on ajp14
Date Mon, 12 Mar 2001 12:35:19 GMT
>The jk_ajp13_worker objects hold onto a cache of endpoints -- 
>ep_cache.  It
>would be relatively simple to loop through this cache and close all the
>connections in case of ECONNRESET (you do have to call a macro 
>to enter a
>critical section -- take a look at reuse_connection()).

>However, this cache only holds onto endpoints which are *not* 
>being used. 
>When an endpoint is checked out of the cache (by 
>get_endpoint), or if the
>open socket descriptor is transfered to another endpoint (in
>reuse_connection), that connection is replaced by NULL in the cache.

>So if we shut down all the connections in the cache, we won't 
>shut down the
>other connections which are handling requests at that moment.  
>My only fear
>then is that, when those connections get their own ECONNRESET 
>errors, they,
>too, will try to shutdown all the connections in the cache.  
>If TC hasn't
>come back up yet, this won't be a problem, because there won't be any
>connections in the cache.  But it does make me a bit nervous.

Since the failure is a rare case, I suggest to just let individual task 
close failed connections and try to reuse another

Code will be simpler and we will avoid dreaded condition in
multi-threaded env.

I've started thinking about ajp13++ (ajp14 ?) :

1) ajp12/ajp13 can't handle failure (even in load balancing config)
   in upload mode. What happen if a connection is broken between Apache 
   and Tomcat during the upload since data are transmitted in chunk of 8k ?
   We loose the allready sent 8k chunks and will send to the backup Tomcat
   the rest of 8k.

2) What about adding more control/validation at connect time in ajp13 ?
	Apache 				Tomcat

	CONNECT TIME connect() + -> LOGINFO (ie secretword/protocol
				     <- LOGOK / LOGKO 

3) Add mount/umount messages between Tomcat and Apache when contexts are 
   started/stopped. In production environement with many VirtualHost, you
   just stop a Tomcat to update one of the Virtual's context. Admins must be
   to updates contexts (shutdown context, updates stuff, restart context)
   be sure that request to specific that 'moving' context will be routed to
   tomcat during the update. 

			/   \

		    TC1    TC2
	I shutdown context test on TC1, Apache receive a message from TC1 
	that 'test context is no more available' and will route test 
	requests to TC2.

	I restart the updated context test on TC1, Apache receive a 
	message from TC1 that 'test context is available' and update
	its status informations to route 'test requests' also to TC1.

	I could now shutdown TC2, to do the context update.

4) To be sure Tomcat is ready to serv next request why not adding a command
   from Tomcat to Apache is OKTOSERV / NOTOKTOSERV. We could before sending 
   the query from Apache to Tomcat do the read() for the OKTOSERV :

	- We receive OKTOSERV, fine we could send the request (nota OKTOSERV
could pre present by Tomcat, just
         after endofservice JK message)

	- We got an error (ie ECONNRESET or something related, just close
and try with another endpoint)

	- We receive UMOUNTED/xxx (the context xxx was shutdowned in Tomcat
by admin, try with another endpoint)

	- We receive NOTOKTOSERV, Tomcat may be in starting / stopping
phase, just try another endpoint

	OKTOSERV/UMOUNTED/NOTOKTOSERV could be sent in Out-Of-Band messages
but which JVM supports OOB ?
5) Add some kind of HeartBeat messages between Tomcat and Apache, to be sure
the connection
   is still valid. In case of a brutal server shutdown or router failure,
the connection will
   be unavailable and won't be detected before the next read(). If Tomcat
didn't send HeartBeat
   for 1/2 minutes consider it to be dead ;-(

Typicall ajp14 protocol

	Apache	-> Tomcat
	Apache <- Tomcat

*  CONNECT TIME connect() + -> LOGINFO (ie secretword) 
*                           <- LOGOK / LOGKO 
*                           <- OKTOSEND / NOTOKTOSEND (not ready state could
be also handled via OutOfBand messages :)

*				<- MOUNTED/test, MOUNTED/examples,


*  At QUERY TIME read() for OKTOSEND/NOTOKTOSEND (if connection reset /
closed => apache close socket and search for another worker
*                                              if got NOTOKTOSEND => apache
just search for another worker
*  SEND QUERY via chunked part -> (but what about retry from origin if
Tomcat fail between ?)

*				<- UNMOUNTED/test, UNMOUNTED/examples


*				<- (RE)MOUNTED/test, (RE)MOUNTED/examples

*				<- HEARTBEAT (I'm alive)

PS: I send a proposal to jakarta general list about a new subproject
    web connector 


[PROPOSAL] The Commons - web connector

Hi to all,

What about a new sub-project, web connector, where all
the developpement on mod_jserv and mod_jk 
(and why not mod_webapp) could live.

Apache 1.3 and 2.0 are allready supported by mod_jk but also
IIS, AOL, and NES (iPlanet) even JNI.

Tomcat's 3.x and 4.x provide interfaces (modules,
interceptor or whatever) that these connectors will implement :)

A project which could be in The Commons even if there is 
still C code inside but also many java part (TC mod/interceptor).

We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use
mod_webapp from Apache 2.0...

Comments ?


To unsubscribe, e-mail:
For additional commands, email:

View raw message