tomcat-users mailing list archives

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

Re: http://tomcat.apache.org/connectors-doc/reference/apache.html

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..

SetEnvIf %{THE_USER_WALKED_AWAY_WITHOUT_CLOSING_HIS_BROWSER} yes JK_STICKY_IGNORE=yes


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message