On 15.08.2011 17:09, Lataxes, Karl wrote: > Yes, the space before "servlet" is a copy/paste error. > > I made the LogFormat additions to httpd.conf, set the mod_jk logging level to > "debug" and ran some additional tests. > > The session id did appear in the access_log I generated: > > 2000-1-200-ap-1313413815567
So the session ID is wrong, it does not contain the trailing ".tomcat7A" to allow sticky routing. Whatever generates the session id doesn't generate a correct one which supports stickyness. The session id doesn't look like a normal Tomcat session id, so it seems something else is setting the JSESSIONID cookie, like a custom sesion manager. You need to find that piece of code and fix it (to append the jvmRoute to the id). Regards, Rainer > In the mod_jk.log, I also noted several references to the session id, which > are included below. Please note that the original client request went to > worker tomcat7A, but subsequent requests were routed to tomcat7C > > [Mon Aug 15 09:10:15.614 2011] [3275:1] [debug] > ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [Set-Cookie] = > [JSESSIONID=2000-1-200-ap-1313413815567] > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] service::jk_lb_worker.c > (1118): service sticky_session=1 id='2000-1-200-ap-1313413815567' > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] > get_most_suitable_worker::jk_lb_worker.c (946): searching worker for partial > sessionid 2000-1-200-ap-1313413815567 > [Mon Aug 15 09:10:18.495 2011] [3275:1] [debug] > get_most_suitable_worker::jk_lb_worker.c (1001): found best worker tomcat7C > (tomcat7C) using method 'Request' > > You can see from the log snippets that ".<worker_name>" is not being appended > to the session as expected. > > -----Original Message----- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Saturday, August 13, 2011 8:11 AM > To: users@tomcat.apache.org > Subject: Re: Sticky Session Not Working With Apache 2.0.54 and Tomcat 7.0.8 > > On 12.08.2011 15:30, Lataxes, Karl wrote: >> The jvmRoute's for both server.xmls are properly set to the worker names and >> are not commented out. This was the first thing I verified. >> >> <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat7A"> >> <Engine name="Catalina" defaultHost="localhost" >> jvmRoute="tomcat7C"> >> >> Here are the settings in workers.properties (worker tomcat7A identical to >> tomcat7C except for port, since both are running on the same server for >> testing. In production, we will probably install them on separate boxes): >> >> worker.list=loadbalancer,jkstatus >> worker.tomcat7C.type=ajp13 >> worker.tomcat7C.host=<host_name> >> worker.tomcat7C.port=4931 >> worker.tomcat7C.lbfactor=1 >> worker.loadbalancer.type=lb >> worker.loadbalancer.balance_workers=tomcat7A,tomcat7C >> worker.loadbalancer.sticky_session=1 >> worker.jkstatus.type=status > > OK > >> Here are the JkMount settings in mod_jk.conf: >> >> JkMount /jkmanager/* jkstatus >> JkMount / servlet/* loadbalancer > > I hope the space before "servlet" is a copy and paste error and not in the > original config ... > >> Load balancing is working, but subsequent requests from a single client are >> being routed to the other Tomcat instance despite sticky_session being set >> to 1. > > OK, then maybe your cookie header is not OK. To debug: > > - Add %{Cookie}i to the LogFormat you are using in Apache. It will log all > cookies. Check the values. > > - Add %{JSESSIONID}C to the same LogFormat. It will log the value of the > JSESSIONID cookie found by the web server. Check the values. > > - Optional: Add %{Set-Cookie}o to the same LogFormat. It will log the setting > of the cookie (sending a cookie from the server to the client). > Probably of no use for you, since you seem to parse that info in some other > way. > > - Increase log level of mod_jk to debug or even trace (not in > production) and look at the log lines written when your client sends a > request, which isn't handled sticky. > > Regards, > > Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
