tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Is it possible to expire jvmRoute cookie
Date Thu, 06 Dec 2012 22:54:55 GMT
Hash: SHA256


On 12/6/12 2:40 PM, André Warnier wrote:
> Christopher Schultz wrote:
>> 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.

Since the container (generally) manages the cookie timeout, most
applications don't ever directly touch the JSESSIONID cookie or its

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

That is true, but it would be a shame for the cookie to time out
before the (server-side) session was actually destroyed.

I think this is a legitimate gripe.

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

(Sorry, I just noticed that you said "at the end of the URL". I was
still thinking about cookies. If the jsessionid is in the browser,
you'll have to redirect the client with a different (or missing)
jsessionid parameter.

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

Right. Honestly, the same is true for the cookie situation: Tomcat had
no initial opportunity.

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

Right, they can't.

My suggestion is an invalid-session event to trigger a re-balance at
the mod_jk (or mod_proxy_ajp) level. If Tomcat can use some obscure
response code (306? 308/9?), perhaps that could trigger a re-balance
in httpd. When such a re-balance happens, the new backend server would
ignore both the cookie and the jsessionid (because the jvmroute does
not match the current server) and produce a response with a new
Set-Cookie and re-written URLs (if appropriate).

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

AFAIK, Tomcat does not have a "ping" operation for a session. If you
make a request that touches the session, you'll freshen the last-used
timestamp and extend the life of the session. You must have read
enough "I have a javascript ping to check my session status on the
server, and no my sessions never expire!" posts on the list to be
aware of this.

> (On second thought, of course there would : one could just build
> one into the application).

That might get tricky. I'm not sure if you can even ask Tomcat if the
session is valid without it updating the last-touched time and
extending the life of the session (which I believe is *not* what you
want, here).

> I'm heading for the patent office. Andre::CrystalBall sounds nice
> too.

Right. Pid's probably should be:



- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with undefined -


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

View raw message