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 complex. 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. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
