tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: mod_jk and session stickiness
Date Wed, 23 Jul 2014 14:49:19 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rainer,

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:
> 
>>> http://tomcat.apache.org/connectors-doc/reference/apache.html
> 
>> 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
> 
>>> http://tomcat.apache.org/connectors-doc/generic_howto/loadbalancers.html
>
>>> 
> I'm
>>> 
> not seeing this in my request attributes. Do I have to specifically
> enable it using JkEnvVar?

Duh:

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

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTz8tvAAoJEBzwKT+lPKRYYdEP/0yqDT6Ek4mNYfIYbbP8BxXh
1Sq5ubDkzEFy7x1uBEfh4sMPfdgZZE7ACzshRZgij51eJh61X4NIcAHgbiAFzsJP
QQOPnqOBV5GG46T7oeWwCudS1MjrTIBJuWQOJSieFnGJZ3GmZ6S6tdb67B3Kr6of
fw9KePDc10jjxl+bHJxGAI3iXeS4kFXoZV8oLdP99XsQTKp3tOHaZF50k6wQjRks
t9tTiQ9ADM4AAqXcw7lgYl0t1lF5yt2KxWPvAvk6B9fP0k6oUTBmvlVVjt6rxm7G
THXpAXDaZWOkyMN6JbKxj7NzYgcJq9OyNOm1BXrAdKJ0RBRKgGhdYCdH5qVsvaZZ
+JfyNDB1xciJ9XekTltgyFozpwoI5awgedeK985Qga+TlIvSzge9td8YDZ8KnG+U
zyjzP74tT9MjpZCR6xW9lktIhowZy5jJU2O/1audE/Y8CjZLCxs+hYO4ATfXCspW
0v0N6g4e72CC85g660mQnhUhqqSoT8cl7rT1zmRCUXbZVAzHYngwg6+E8uUyvln9
qIQOpdLBR8V6qWzhh5WCd563nWCJr1x54xIJ8y3xOYpXxxBtV+JIpKFCQEuq66sj
zR9MiTpn4cpJ3NJLgmakm1Ad9zeGEu9XGxAAGPWFNPBjh307tCeyUMWOlTFw3C9w
kn7h73+wkOdBAls8R3gw
=DsVT
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message