tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Jk2: discovery and updates
Date Thu, 13 Dec 2001 17:07:44 GMT
On Thu, 13 Dec 2001, GOMEZ Henri wrote:

> >Tomcat could also decide to push config data, or context status, etc.
> Ok, we could have a little overhead (network latency) during this init
> phase but it's not a big problem since it's not too common. Which make
> me think that in multithreaded env like Apache 2.0 we could avoid to
> redo the full logging and discovery each time since we may allready
> know the list of webapps and related URIs.

Init happens only the first time, or when an error happens ( like tomcat
was restarted and we lost the connection ). In the second case, it's
possible ( even likely ) that tomcat has other settings/apps.
( XXX todo: detect webapp reload in aprconnector :-)

> Having a common code which will monitor for incoming message
> from tomcat is not a bad idea but we'll need in that case a
> state-machine, just to avoid handling illegal messages
> WebServer could be in state:
> a) physically connected (login to be sent)
> b) logically connected (login sent and granted)
> c) waiting for autoconf stuff (discovery request sent)
> d) waiting replies

After the first 'ping' message tomcat has 'control' - it can send any
message it wants. Apache doesn't need any state, it'll just receive
messaes from tomcat and execute them.

It tomcat wants md5 auth - it'll request it. If it fails - it'll send
a 'notok' message that would close the endpoint.

The state can be only maintained on tomcat side, we don't need any
complexity on the C side.

We could have tomcat set a 'state' field in endpoint if we need to,
and check it - but I think right now is not needed and would make things

What if tomcat wants a different auth mechanism ? For a unix domain socket
we probably don't need md5 auth.

Regarding discovery, tomcat is the one that knows what changed - it should
push the data. It may also use different message formats.

The benefit of this logic is flexibility and simplicity. Instead of a
state machine and RPC-style calls we have just messages.

> In multi-threaded env we could also reuse the socket
> to have a thread monitoring the tomcat state by sending
> heart-beat messages (usefull in out-process, uneeded in in-process)

That could be handled by jkctl and ping messages. It can also be
done periodically, but that can be controled by external logic.

Non-multi-threaded env is more problematic, and getting all
processes to update.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message