tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Is it possible to expire jvmRoute cookie
Date Thu, 06 Dec 2012 15:53:28 GMT
Christopher Schultz wrote:
> 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.


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 ?)
- if it is in the cookie, then it would expire at the same time as the cookie
- 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) ?
But you seem to hint otherwise, so now I doubt.

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.


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.
I'd do that with a nifty mod_perl module of course, if I could figure out how to test for

the right condition..


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message