>> >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 :-)
Did there is plan to put the init stuff in shared area to avoid multithreaded web-server do the full stage of autoconf. The idea will be that each child/thread will do the login/auth phase and then check if autoconf is allready available to skip this stage. The shared data should be unique by VirtualHost in such case, since each Virtual could have it's own version of uriMaps. See my previous question about ajp14 and discovery for more comments and questions about this, particulary the DEFAULT webapps and webapplist >> 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. ok >The state can be only maintained on tomcat side, we don't need any >complexity on the C side. In that case, tomcat will be the master of connexion and so will turn Apache/IIS/iPlanet into a slave state engine ? >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. No, but the main idea is to be sure that the handler have a minimum knowledge of the current state to have them reply accordingly. In currently known states there is no such need but we make reserve for the future. >What if tomcat wants a different auth mechanism ? For a unix >domain socket >we probably don't need md5 auth. Sure ;) >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. I agree, but I'd like to have a knowledge of state also in Apache, even if we never use it. Something to be added in protocol, maybe only one byte. Also tomcat could indicate that uriMaps is available for that Virtual by sending the corresponding uriMaps Id, which will be simply fetched by C part in any shared area... >> 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. Yes and that's a question for Apache gurus, did we have a kind of watchdog task in Apache 1.3/2.0 to handle such task ? >Non-multi-threaded env is more problematic, and getting all >processes to update. Clear, but any tomcat sending specific HTTP request to Apache (even 1.3) could help in it, definitivly a good idea :) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
