-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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? Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTz8lZAAoJEBzwKT+lPKRY7YcQAL23/2/XSQhekfTaB+5IL7IL UQSz7QInnxbRjrHo/oOElIFNn/AoThpXYFtYLAUauZ2sYyT56gDPyVCRwZXn3XqB gEVZsnQLivW+wEVb79htUS4yUn1j3O8lijmtg/BXRWL+2/KDlF6kbLSBOOGRbwtS PRTmXnqLr+YQVm5e/UUj1Ctz4t5lFnVz7ahrj6dfOUntm1wUvF2U7QWsEbhcXmNA gyvfYVmXJTahsEgAWmHEiyqrMY8P2gzexain9Dk9RwZpEQPC1apsMqvalXJl7JIr wCwFB4L6NXTgkhVc4ROM4i4r+oKvPNPWstRQGbyZ6hzWMGlGqqE3nqd7exHws9fp lVEUWMfeCGQjcnr+SKDpYvzMgXEbk5N6rigjUX6c94pVtRq79f5ietcH91tM6FpX tLvcUiFLA61/ZbWmNXTiqQTNL3ECsVrqN8bckLwMjaUD6Z5FtiWWVqQPIWn04jza ISehwLE2MePdTWR+IrTu6FCDf/Jlaib1DW/SLlxGGGDGkWiZTLXu6BxL3mkqR3r9 BLarkvtfqrMTV3ixqDyahs6uCbQoyeRbdt7iqC3ORUdMleMhuQ0J3Q6wq9ZEepc5 TfWmwUdTbAyCoEysxx2/lCSrMBtPzXtxsbxeJNnGSW6H6vKTB74gtxpNyyH7cgZf xr2eDDrw5cSMMvJYeAOL =Kt74 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
