On Fri, 14 Dec 2001, GOMEZ Henri wrote: > Did there is plan to put the init stuff in shared area to avoid > multithreaded web-server do the full stage of autoconf.
We need to first figure out how to exchange info between apache processes. The config will be saved in the workerEnv, uriMap, etc - and will be used by all workers in the process. On the other hand, since we reuse the connections it is not very expensive to get the config info every time we connect. It is very likely we'll get the duplicated info, but it's very possible we'll get usefull updates. One thing we can do is add a timestamp, and have the handler for the autoconfig send a response 'no config needed' if 2 connects are too close to each other. ( later ) > 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. It's possible, but I think we should focus on getting jk2 out :-) After we have jk2 stable, we can start adding any features we want. ( I still have to make sure the java side has the same flexibility ) > >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 ? No, both sides will be 'stateless' from the point of view of the ajp1x protocol. The only 'state' for the endpoint is if it is connected or not. If it is not, it'll try to connect - and tomcat can accept or refuse the connection. At any particular time, one side is waiting for messages and the other is processing ( a single 'virtual' thread ). Apache is the only one that can initiate requests - ping is a way to give tomcat a chance to send it's own requests to apache ( like login ). BTW, tocmat can also send it's requests during normal request processing -nothing in the protocol prevents tomcat from sending config info instead of SEND_CHUNK in a normal request ! ( it can be coded in the message handler ). > 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. Both sides will have plenty of state, and the handlers will use this - I'm talking here about the protocol that exchanges messages. We should really find a better name - AJP is confusingly used for both protocol and API. The wire protocol ( let's call it ajp13 ) is stateless, the API - let's call it jk13, jk14, jni, etc ( i.e. the collection of messages and handlers ) will have state. ( actually, there is one bit of state in the protocl - each side can either listen for requests or send requests, what I mean is that the protocol doesn't 'care' about the API state and the higher layer ) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
