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 19:40:33 GMT
Christopher Schultz wrote:
> Hash: SHA256
> André,
> On 12/6/12 10:53 AM, André Warnier wrote:
>> Christopher Schultz wrote:
>>> 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.

>> - 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:
> 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..
> 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:
For additional commands, e-mail:

View raw message