Hi Henri, you can find a dev snapshot at:
http://people.apache.org/~rjung/mod_jk-dev/source/jk-1.2.38-dev/ You know those are not releases. The updated documentation is at: http://people.apache.org/~rjung/mod_jk-dev/docs/jk-1.2.38-dev/reference/workers.html look for "set_session_cookie". I did some basic tests. If it doesn't seem to work: - turn debug logging on (JkLogLevel debug) on a not to busy system - use a client (browser) for which you can trace outgoing and incoming headers, e.g. firefox with firebug or similar tools If mod_jk crashes please try to get a core dump and from that a stack. Basic configuration in your case: worker.balancer.type=lb ... normal lb setup ... worker.balancer.set_session_cookie=true worker.balancer.session_cookie=HENRICOOKIE worker.balancer.session_cookie_path=/nexus The name of the cookie ("HENRICOOKIE") is arbitrary but it should differ from any other cookie used, especially don't choose "JSESSIONID". The session cookie path "/nexus" must be chosen to fit your application URI. If the balancer serves multiple applications and you want mod_jk cookies for all of them, you could use "/". In that case the client will use the same node for all applications. On the first request mod_jk should send back a cookie containing a dot (".") and the name (route) of the chosen target worker. As long as the client presents the cookie during follow up requests, the cookie will no longer be sent by the server. If the cookie is missing, or the server needs to do a request failover to another worker, a new cookie will be send to the client. As usual you can log an incoming cookie in the access log using %{HENRICOOKIE}C (adjust name) and the outgoing Cookie using %{Set-Cookie}o (Set-Cookie is the header name). Finally: don't recommend this as a general setup. Built in Tomcat session management and jvmRoute handling works very well and is generally understood. Letting mod_jk handle the cookie is just a workaround if a web framework or webapp breaks Tomcat's session ID generation. Have fun and let me know whether this already works for you. BTW: I'm pretty busy on Thursday, so quite possible I can not react immediately. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
