tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: mod_jk and session stickiness
Date Wed, 23 Jul 2014 14:49:19 GMT
Hash: SHA256


On 7/23/14, 10:40 AM, Christopher Schultz wrote:
> Rainer,
> On 7/23/14, 10:37 AM, Christopher Schultz wrote:
>>> On 17.06.2014 16:43, Christopher Schultz wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>> All,
>>>> I've been using sticky sessions with mod_jk and I can see
>>>> that there is a bit of a problem when attempting to take a
>>>> backend Tomcat server out of load-balanced rotation: a user
>>>> who never (or rarely) restarts their web browser will keep
>>>> the same JSESSIONID cookie forever and therefore end up with
>>>> the same backend server whether it has been disabled or not.
>>>> Quick series of events:
>>>> 1. User visits load-balancer and gets a randomly-assigned 
>>>> backend server/route. We'll call this route "X". The 
>>>> JSESSIONID cookie set by the backend server is therefore 
>>>> foo.X.
>>>> 2. User's requests are routed by mod_jk to route X.
>>>> 3. Route X is disabled using mod_jk's status worker
>>>> 4. User's session on server X expires.
>>>> [Technically, 3 and 4 can happen in either order]
>>>> 5. User makes a new request to the load-balancer, and mod_jk 
>>>> sees the JSESSIONID cookie still set to foo.X. mod_jk sends 
>>>> the request to route X which allows the user to login, etc.
>>>> Thus, it takes more time than necessary to bleed all the 
>>>> traffic from route X for maintenance, etc.
>>>> Is there a way for mod_jk to ask route X if the session is 
>>>> *still* valid? It seems that mod_jk will not re-route a 
>>>> request that looks like it's got a valid session id to a new 
>>>> (active) backend server unless the backend server X is
>>>> actually down.
>>>> Any ideas?
>>> Not exactly what you want, but you can build something around 
>>> it:
>>> 1) Switch off stickyness for specific URLs
>>> If you know that users will come via specific URLs, like a
>>> login page, and you want that page to be handled non-sticky to 
>>> optimize load balancing even if users have an old cookie, you
>>> can do that by setting the Apache envvar JK_STICKY_IGNORE. Look
>>> for JK_STICKY_IGNORE on:
>> This seems like a reasonable way to do things, except that we 
>> still want to support requests to protected resources being
>> saved and redirected to the login page. If we did this 
>> (JK_STICKY_IGNORE), then we'd end up "forgetting" the saved
>> request (because the client would be re-balanced to another node
>> for the login page) and ending up with a (useless) session on the
>> node we are trying to take down.
>> We'd like to retain the request-saving capabilities of the 
>> container.
>> One option we have here is to provide separate URLs for "regular"
>>  logins versus the saved-request logins mentioned above: that
>> would probably solve both problems.
>>> 2) Improve handling of sessions for node with activation 
>>> "disabled"
>>> If you switch a node to activation "disabled", mod_jk will not
>>>  send requests there, that have no session id (and of course
>>> also not when the session route points to another node). But
>>> the old cookie requests might still go there.
>> Yes, this is what we would normally do.
>>> For that you can use the feature, that mod_jk forwards the 
>>> activation state to the Tomcat node. The node can then decide
>>> on itself, whether it will handle a request coming in with an 
>>> invalid session id, or for example clears the session cookie
>>> and does a self-referential redirect, which then by mod_jk is 
>>> balanced on the fully enabled nodes.
>> This sounds like a promising technique. I was thinking we'd just 
>> tell the Tomcat node directly (e.g. set a context-scoped flag)
>> that it was "disabled", but having AJP forward that information
>> would be even better, so the state can be managed entirely by the
>> status worker on the httpd side.
>>> This logic can be put into a servlet filter.
>> I'm not sure it can be in a Filter because of the interaction
>> with the saved-request features described above. If in a Filter,
>> the request would be saved before the Filter has a chance to see
>> it, then authentication would take place, etc.
>> I think this has to be in a Valve, and it has to happen before
>> the AuthenticatorValve sees the request. Do you see a way around
>> using a Valve? Assuming that such a Valve would be required, I
>> think we should provide one with Tomcat. I'd be happy to write
>> such a Valve.
>>> You have to be careful though to not produce redirecting
>>> cycles, e.g. in case of errors or all other nodes are down. You
>>> could add the name of the first node the the URL as a query
>>> param, and if you see it a second time, then do not redirect
>>> again.
>> I think that's a good way of doing it. One could also use
>> cookies if they can be relied upon, if you don't want to modify
>> the URL.
>>> The request attribute is named "JK_LB_ACTIVATION". Search for 
>>> that name on
> I'm
> not seeing this in my request attributes. Do I have to specifically
> enable it using JkEnvVar?


You can retrieve the variables on Tomcat as request attributes via
request.getAttribute(attributeName). Note that the variables send via
JkEnvVar will not be listed in request.getAttributeNames().

The request attribute is in fact there... it's just not advertised
through request.getAttributeNames, just like any other JK_ environment
variable passed-over from the web server.

- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message