Hi, motivated by a bug report I had a look at the handling of the optional route attribute in the AJP protocol.
I noticed, that mod_jk never seems to actuall set the attribute, and that the AJP connectors on the Tomcat side extract it but never use it. I don't know about the history, but does the following sound reasonable: - Setting the route attribute in the AJP request to the route value configured for the AJP worker chosen in mod_jk (simple) - When a new session in Tomcat gets created, and the Engine does not have a jvmRoute set, and the request came in via AJP, setting the jvmRoute of the session to the jvmRoute returned by the AJP request. That way one can inject the stickyness tag from the frontend and there's no need for duplicate jvmRoute configuration (mod_jk and Tomcat) any more. Because of compatibility the default jvmRoute would still be the one configured in server.xml, even when there's another one coming in via the rquest. Optional enhancement: add the same logic the the valve which rewrites the session id when the backend changes, i.e. use the Tomcat configured jvmRoute when available, but if not also check whether it's an AJP request and use the jvmRoute in this request instead. Does that make sense? Or was it tried before and produced problems? Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
