-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
