>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
one.
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
level...)
<- LOGOK / LOGKO
3) Add mount/umount messages between Tomcat and Apache when contexts are
started/stopped. In production environement with many VirtualHost, you
can't
just stop a Tomcat to update one of the Virtual's context. Admins must be
able
to updates contexts (shutdown context, updates stuff, restart context)
and
be sure that request to specific that 'moving' context will be routed to
another
tomcat during the update.
Apache
/ \
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 :)
* WHICH MOUNTED ? ->
* <- MOUNTED/test, MOUNTED/examples,
MOUNTED/admin....
...
* 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 ?)
* wait REPLY <- REPLY DATA / OKTOSEND / NOTOKTOSEND .....
*
* <- 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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
