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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
