tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: mod_jk and session stickiness
Date Wed, 23 Jul 2014 20:10:52 GMT
Am 23.07.2014 um 21:03 schrieb Christopher Schultz:

> On 7/23/14, 1:49 PM, Rainer Jung wrote:

>> The other case, a request with an invalid session ID accessing a
>> tomcat instance with activation disabled can IMHO be handled by a
>> filter that
>> - checks whether the request has a valid session using
>> getSession(false), if it has one, let the request proceed
>> - checks activation state, if "active", let the request proceed
>> - checks the request method, if not GET, let the request proceed
>> - otherwise:
>> - set the session cookie, e.g. JSESSIONID the an empty value -
>> issue an external redirect to the same request URL - optional
>> redirect loop detection: add a query string param or cookie that
>> gets the local jvmRoute appended during each redirect. Before
>> doing the redirect, check that the local jvmRoute is not already
>> part of that token (we have already been here before)
>> This would not really interfere with your saved requests: they
>> would get a redirect which the browser follwos automatically and
>> after that you will observe the normal behavior.
> This is exactly what I have implemented -- as a Filter since we can
> insert it before SecurityFilter intercepts the requests -- and my
> tests suggest that it will work correctly.
> I added code to strip-out any ;jsessionid path parameter from the URL


> if it exists, but haven't done any of the redirect loop detection
> (yet). I think the loop detection is going to have to keep a running
> list of visited nodes which, in large clusters, could grow very large
> especially if the node names are long. I'll post my code when it's a
> little more featureful.

As long as nothing goes wrong, the first redirect - having no more 
session info - should not end up in getting redirected as well, because 
it should only be send to an active node by mod_jk. So you can even stop 
redirecting if you detect, that it already happened once. For a large 
cluster that might be better.

Multiple might happen (didn't check the code), if all active members are 
in error state. Even then one would not like to produce many of those 
redirects for one request, so again, only allowing one redirect might be 
the right solution.



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

View raw message