On Tue, 8 May 2001, Dan Milstein wrote:
> The only thing we really lose is the ability for the servlet engine to send
> a message to TC in between requests. And the main messages, as I see it,
> are:
>
> a) the entire engine is shutting down
>
> b) certain contexts are shutting down
>
> c) certain contexts are now live
All of those are "low-frequency" events, equivalent with a configuration
change in the web server ( like you edit the apache.conf and add a new
virtual host, same thing for NES or IIS ).
All servers have mechanisms to deal with such things - like a signal or
some other thing, and that can be abstracted.
( in fact, this shouldn't even be part of mod_jk - but a different
component )
For multithreaded servers ( or multi-process servers that maintain a
communication chain between servers - like the scoreboard ) this can also
be implemented as a normal server module, that would handle a special
request, and tomcat can do a simple "reconfigure" request using HTTP.
Yet another solution: mod_jk can send a "ping" ( let's say after every 100
requests - or before the first request if a certain timeout ).
There are many solutions for this - without adding complexity to the
"common" case.
> [Socket trivia -- will this written-but-unread data cause any trouble during
> the TC shutdown process?]
Just an exception ( unless you read before closing the socket ), and of
course only on some platforms ( that implement corectly the TCP spec ).
> That part makes sense. However, you're also suggesting using that status
> command to send over config information via AJP_CONTEXT_(DOWN|UP|OK). I
> *do* like the idea of the engine sending over some control information at
> the end of every request-handling cycle, but I have two suggestions:
Let's first solve the first "90%" of the problem: tomcat sending config
at the beginning. That resolves most of the configuration problems ( most
users will not have to touch any server config files ).
The other 10% ( contexts added/removed/changed at runtime ) is identical
with the problem of "web server config changed" - we shouldn't try to be
smarter than the server ( for now ). Just using the normal server restart
should be enough and clean.
With Apache2.0 and most multithreaded servers we can do a normal HTTP
request from tomcat to apache and make a config change ( the config can be
changed at runtime ), with apache1.3 there is no better solution than a
restart ( if we want to let apache do the mappings - the mapping tree is
created at startup time AFAIK ).
> BTW, currently, ajp13 sends over a single byte of status, which determines
> whether or not the connection should be reused. We'd basically just be
> expanding that. I like that idea a lot.
+1
> (so that it can tack it onto the end of the request cycle). Questions: what
> if multiple instances of Apache are forwarding requests to a single TC
> instance? How can TC "know" that? It has a single master socket, and then
> it hands off live sockets to individual threads, which hang onto them over
> many requests. If some of those threads are serving Apache 1, and some are
> serving Apache 2, then we have to make sure that the context change info
> goes into one thread from each group. And then on the Apache side, we have
> to bubble that config information up so that all the separate child
> processes change their config setup. (Is this true? Does Apache work
> differently than this somehow?)
On connection open we need to pass some more info, and we'll have to save
and organize this information. But I think this is orthogonal on the
communication problem.
For Apache1.3 we could use a signal or the scoreboard to signal to all
processes.
Costin
