-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rainer,
On 7/18/14, 12:13 PM, Rainer Jung wrote: > late answer but at least an answer. See below. I appreciate the late answer, because it was very helpful. I have some concerns, though. Please see below. > 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'll > definitely look at using this. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTz8isAAoJEBzwKT+lPKRYVDcP/RexqazYXjbzrIu2StWr8ChL eCQzG4ZOPiqz2Q/1bXChH+QLgEw5hdc9OczD/KhHyCUmayKVeSsZVKuS1tzgruPU 7YcTx6ioftlR/fWFGN5K8RprqUX+nkGI/rKn7VpyJe2OdBy149qWbk1DnnDdjFrT UteUZ1penC63n3DlSaTPYdKAkNPkdFhOxasC1tB2hDNMgzcpdi06ci6nIqLMUltd 0dA2pP8MqGnTzdBZUy9s0Y37kU49nSgZ4Qp7dElBYh0bnoz3f1EeyDUIeozNzj7U vXm//7ZQ/ie89pDcGrCEMQFxPBeblPaoAUgYBGsDzNI6kfsB8bp7hR+uskBQnznI IC5tUyvkNKzoOIElSVsmAxDhB+Rtm1pVa1Jd0XaxkBVE+kBHbXIAEfiUlbWIRIUK JgXcXIQaXFBI0kQ9OWeYxDg6ds7RQYmyyzr7haxDmcveqvvZWepnrDtxH3nMve8W HYkIllz5UTShV2S/k5JQmeRw2ZJ8mDXLsH+wPb/qUgxqZF29p7vW08ILAOwXr9Rn GjSeCAT0ruOeyFx4se05h67QcdJt4aBghcaOcHDXJZ50bOyVoD3lDsoclIExwNSv cjfaEev2ERYKDMCd4o2MEYSBzD0LB+ehA28AjcQsZGCRCwcYqYqai8s3Nu5TbhvX ae13hnoiLH/GTyAYDsym =pUfD -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
