On Mon, 17 Dec 2001, Kevin Seguin wrote: > > Tomcat 4.0.x support ajp13 protocol, used in mod_jk > > but still miss a subtil feature (jvmroute) to be > > able to keep the route to the good JVM in > > session mode (SessionAfinity). > > how does the connector set/use jvmroute? i assume there is some sort of > cookie magic going on, but after a brief tour of the code, it's not obvious > to me how this jvmroute stuff works.
That's quite simple. Each session generated by tomcat has a prefix containing the 'worker id'. mod_jk will look at all incoming sessions, and if it detects the prefix it'll quickly send the request directly to the right worker ( the 'afinity' ). Now the only 'trick' is to get the tomcat session manager to generate the session id including the 'worker id' ( i.e. ajp13, or ajp13_9009, or whatever you set in your workers.properties ). mod_jk will send the worker id on each request, so tomcat will know how it was received and pass this info to the session manager when it generates the session id. With 4.0, the Manager doesn't have access to the Request object, so the only solution I found so far is to add a property that is set from server.xml settings ( that's quite trivial to add ). The user will have to keep workers.properties and server.xml in sync, i.e. use the same worker name ( and workerId property ). > it seems to me that tomcat (any version) shouldn't have to have anything to > do with setting jvmroute. couldn't the connector be solely responsible for > this? the connector could add a cookie to the response, then read this That's another solution ( I tryed to do this ), but it'll not work. The 'session id' is visible to servlets, etc. A servlet may expect a cookie ( or url ) with the session id. URL rewriting may generate urls with the session id in it. Mod_jk could rewrite the cookie on the fly, but can't go into html and change the urls. So whoever generates the session id must include the route ( == worker id). I don't think there's any other way - mod_jk doesn't have control over that ( well, it has in 3.3, using the new session hook, but it's too confusing to be a good solution ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
