Christopher Schultz wrote:
-----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.
So for this case, the solution would consist in setting a timeout for the
cookie.
If the cookie times out, the browser will not send it anymore when the user comes back,
mod_jk will route this to any tomcat, which will start a new session and set a new cookie.
CQFD.
- 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.
Well no, not in this case.
The OP says : because the previous user does not close his browser, walks away for a while
to have a drink, and comes back. In the meantime, the session has expired but the old page
containing the URL links with the expired "jsessionid.jvmroute" tagged at the end is still
there, sitting in the browser's window..
So now the user clicks on a link of that old page, which sends a request to the server,
with the expired session-id. But because of the tagged-on old jvmroute, mod_jk sends it
through to the same tomcat as before.
Which is what he is trying to prevent.
Until now, Tomcat hasn't sent anything, so it had no opportunity to set a new
jsessionid.
My question was thus : how can one even imagine to have tomcat or mod_jk or Apache httpd
go clear these links (with the expired jsessionid.jvmroute) out of the browser's currently
displayed page, when the session times out. Obviously they can't.
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.
Well, assuming for a minute that the final customer here is one of these large
multinational security-conscious organisations with an unlimited budget, and that these
expired pages really bother them, I believe that I have the outline of a solution.
I will of course not describe it here this time, because that might invalidate my future
patent claims.
Just tell me : if I happened to know the session-id and the jvmroute, would there be any
request which I could send to Tomcat, which would not have any non-idempotent effect, and
which would tell me if that session is still valid ?
(On second thought, of course there would : one could just build one into the
application).
I'm heading for the patent office.
Andre::CrystalBall sounds nice too.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
