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 Fri, 07 Dec 2012 08:51:23 GMT
Christopher Schultz wrote:
> Hash: SHA256
> André,
> 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
> timeout.
>> 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).

You are going to force me to disclose the details, and thus maybe lose my patenting 
opportunity, but oh well.
I am not thinking of a regular ping which would run independently.
What I am thinking of is this :
- the front-end httpd server intercepts all requests for this application "early" (before

mod_jk gets to see them). That's not a problem.
- the interceptor at the front-end retrieves the jsession.jvmroute from the URL (or even 
the cookie), and reformulates a request to tomcat, substituting the real application path

by the path of a "ping responder" servlet within the target application, adding the 
jsessionid.jvmroute back into this new path. It then makes an (internal) request to this 
URL. (In the meantime, the original request is held; that's not a problem either).
- the (internal, secondary) request is handled normally, goes to mod_jk, who forwards it 
normally to tomcat according to the jvmroute.
- the response from tomcat is either
   - a) a normal response, if that session was still alive and well
   - b) a "session expired" response (probably a login page or whatever, but in any case 
with a new session-id which doesn't match the original)
- this response goes back to the "interceptor" module in httpd, which gets a chance to 
examine it.
- if the response is (a), then the session is still active. In that case, the interceptor

module can let the original request continue, and the original request will proceed 
normally and be routed to the tomcat which holds this session and to the normal application.
- if the response was (b) however, the interceptor module does not let the original 
request go any further, and instead answers the request itself, with whatever kind of 
appropriate response the OP would wish in this case.
Such as a page with "You have been away for coffee for 00:13:05 hours. This exceeds our 
corporate standard of 00:05:00 hours. The difference has been deducted from your paycheck,

and your session has been closed. Click here to resume serious work."

The above scheme does not artificially refresh the session and keep it alive no matter 
what. The "ping" only happens when a real request would trigger one anyway.

The inconvenient is of course that this applies to every request to that application, 
generating an extra request for each real one.  However, considering that the premise was

that this is a project with an unlimited budget,
a) a simple caching mechanism could optimise this, avoiding unnecessary secondary requests

when the previous request for the same session was recent
b) one can always upgrade the server to cope with the additional requests

(Also, having written and used quite a few such similar "interceptor" modules for Apache 
httpd, I can testify that a scheme like the above is not as heavy as it may look. It uses

mostly internal Apache httpd logic, which is very optimised already.  And you'd probably 
be surprised at what httpd already goes through for each request anyway.)

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

View raw message