>I'm getting close with jk2, there are just few more details I need to >resolve ( and then test, update the other server adapters, test again, >etc). > >One change I'm making to get the things cleaner refers to the login and >discovery protocol. > >Instead of a RPC-style, where Apache sends a command and read the >response, I would use the same 'style' as for requests, where >apache sends >a messages and then listen and dispatch other messages.
>A single message 'PING' will be used. This message will give control to >tomcat ( like SEND_REQUEST does ). Tomcat can then decide what >it wants - >if it wants auth, it'll send LOGIN_SEED message and expect the result ( >like it sends GET_CHUNK when reading post data ). >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. >The same code will also handle config/status messages comming during >normal operations. Why not. >This will make the code extremely simple and clear ( at least IMHO ), >and we'll gain a lot of flexibility ( and that just by >_removing_ code ). > >I'll commit the code after some more testing, I'm pretty sure >it's a good >idea, but I want some feedback ( especially from Henri, who >wrote most of >the discovery and login code ). 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 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) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
