-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 12/6/12 10:53 AM, André Warnier wrote: > Christopher Schultz wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Mitchell, >> >> On 12/6/12 9:48 AM, Smith, Mitchell wrote: >>> I have a jvmRoute appended to my JSESSIONID to enable sticky >>> sessions at an application level. >>> >>> I see often that users do not close browsers, resulting (even >>> if the tomcat session has expired) the user to be forwarded >>> back to the instance. >>> >>> Is it possible to set an expiry for the jvmRoute / JSESSIONID >>> to be expired at the browser so after x amount of time since >>> last request the jvmRoute is not transmitted back to the >>> application apache load balancer. This would prevent users >>> constantly being directed to the same application node. >> >> While I'm not sure if there is actually a way to do this, it's >> an interesting problem I'd never considered: once mod_jk picks a >> jvmroute for you, you may be stuck there for a looong time if you >> never close your browser. >> >> I never close my browser. It's been running since Monday morning >> (okay, bad example -- because I upgraded my Firefox and it did a >> restart for that). But it's not uncommon for me to leave the >> browser running for the entire interval between releases of >> Firefox. When Firefox restarts itself, it actually does not >> expire cookies that should expire when the browser closes. >> >> So, unless I explicitly close Firefox (which happens, sometimes, >> accidentally since CMD-Q and CMD-W are /right next to each other/ >> and ff/Mac doesn't have any "such you want to close all those >> tabs and windows?" confirmation) or maybe if it crashes, I'll be >> stuck on a particular node every time I visit a site. >> >> Hrm. >> >> I'd be interested in any thoughts Rainer might have about this. >> >> AFAIK, a Tomcat node that gets a request with an invalid session >> id will simply ignore it. If a new session is required, then the >> old session id will be replaced with the new one (including the >> same jvmroute that was already attached to the session id), but >> everything happens on that one Tomcat node. >> >> I think the only way this might work would be to have Tomcat >> reply to an AJP connection with an invalid session id with a >> response like "INVALID SESSION ID" and then mod_jk could through >> its normal decision about which balanced worker would be chosen >> for the request. >> >> That seems like an awful lot of work, but it /would/ restore >> "fairness" to the system. >> > > Chris, > > Before I read your answer, I would have been ready to bet that the > OP's question was nonsensical, in the sense that : - the "sticky > identifier" is either included in the JSESSIONID cookie, or > appended together with the JSESSIONID, to the request URLs, right > ? (or wrong ?) Yes: a session id in a sticky-session configuration will have a JSESSIONID cookie whose value looks like "0123456789ABCDEF.jvmRoute". If the jvmroute is tacked-on to the end of the JSESSIONID, mod_jk will route the request to the worker who has that route as long as that balanced-worker is considered "up". > - if it is in the cookie, then it would expire at the same time as > the cookie Yes, but session cookies typically have an expiration of "-1" which means "when the browser exits". Never exiting the browser has predicable consequences, here. > - if it is appended at the end of the URL, then how could the > server get rid of it (in the browser's displayed page) ? Set a new value for the JSESSIONID cookie. > And then, there is this : > > The environment variable JK_STICKY_IGNORE can be set to disable > session stickyness for individual requests. If the variable is set > to an empty string or a nonzero number, session stickyness will be > disabled. Setting it to 0 will reset to the behaviour defined by > the worker configuration. This is available since version 1.2.33. > > Re: http://tomcat.apache.org/connectors-doc/reference/apache.html Interesting -- I was unaware of that feature. Presumably that allows a configuration coupled with, say, SetEnvIf using the JK_STICKY_IGNORE under certain circumstances. > So, if push comes to shove, one could supposedly embed some logic > on the front-end server, to set/unset that variable prior to > letting mod_jk see the call. Right, but the only way to tell if the session id is legit is to ask Tomcat. It's probably cheaper to blindly forward to Tomcat and have Tomcat take some exception scenario in the cases where the session id is no longer valid than it would be to "ping" a back-end server to see if the session id is valid. The former is what I've described above. > I'd do that with a nifty mod_perl module of course, if I could > figure out how to test for the right condition.. > > SetEnvIf %{THE_USER_WALKED_AWAY_WITHOUT_CLOSING_HIS_BROWSER} yes > JK_STICKY_IGNORE=yes That's just the kind of magic Perl was designed to accomplish. You will, of course, need to add "use Pid::CrystalBall;" at the top of the script. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDA6loACgkQ9CaO5/Lv0PDIagCfRxPoKh1cRDzARoqfAVVE1VXQ 2TMAoKbUClB1HZr3mYIkCTnp237wGlB5 =WRux -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
