-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rainer,
On 3/22/18 10:11 AM, Rainer Jung wrote: > Am 22.03.2018 um 15:07 schrieb Rainer Jung: >> Am 22.03.2018 um 11:58 schrieb Martin Knoblauch: >>> Hi, >>> >>> we have this annoying problem that although Tomcat workers are >>> set to DIS state in mod_jk, there are new connections being >>> opened. This prevents us from "idle down" Tomcats in a timely >>> fashion. This hurts when a restart is needed. While our empathy >>> for human clients is pretty limited, we care a lot about our >>> automated workloads :-) >>> >>> Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, >>> sticky sessions -> a bunch of Tomcat 7 (yes I know. Oldie but >>> Goldie :-) workers. >>> >>> As far as I understand, the problem arises with HTTP(S) >>> clients that cache the session cookies. If such a client tries >>> to open a new connection to the backend, the old cookie passes >>> to a DIS worker even if it is no longer valid on the Tomcat >>> side. Tomcat/Application then sees that the cookie is not valid >>> and doles out a new cookie which then allows the new >>> connection to be established. >>> >>> My idea is now to delete existing session cookies for certain >>> request pattern on the Apache frontend. If it works, it should >>> force mod_jk to a new ACT Tomcat. But I am nor really fond of >>> messing with the Apache configuration, as the reason lies on >>> the mod_jk/Tomcat side. >>> >>> So if anybody has another suggestion I would love to hear it. >>> Before I forget, changing the application itself is not an >>> option. >> >> Either your idea, or - if those unwanted new request flows start >> with a specific URL, e.g. a login - mark those URLs specifically >> as not using the cookie. If you are using a >> uriworkermap.properties, look for "sticky_ignore" below >> http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#R ule%20extensions. >> >> If you are instead using JkMount style maps, look for JK_STICKY_IGNORE >> in >> http://tomcat.apache.org/connectors-doc/reference/apache.html#Advance d%20Environment%20Variables. >> >> >> >> Whenever you set the Apache environment variable JK_STICKY_IGNORE >> during a request execution, mod_jk will ignore the cookie and >> distribute like if it didn't see one. Such environment variables >> (different from Unix environment variables) can be set e.g. with >> mod_setenvif based on request properties and also with >> mod_rewrite as a [E=] side effect. >> >> But that would only help if you can describe request properties >> that alow you to decide - based on the request alone - whether >> the cookie needs to be ignored or not. You can use any request >> info including all headers for that decision. What is not >> possible, is to first check, whether the session is valid. >> >> You could also write a filter that checks the cookie for validity >> in Tomcat and if it is not valid, reply with a self-referential >> redirect including a Set-Cookie-Header that deletes the cookie. >> This filter should be written, such that it does not itself >> create a new session. > > Plus I vaguely remember Chris (Schultz) has written such code that > yould be used pretty generic. Chris, am I right? If I am not > mistaken, it is actually here: > > http://home.apache.org/~schultz/lbdf/ Yup, that's it. I think the Valve might be better because it can intercept the request before any potential authentication occurs. The Filter may be easier to get into a Tomcat 7.0 environment/application, though. There's coverage of the theory and pretty pictures starting on slide 41 here: http://home.apache.org/~schultz/ApacheCon%20NA%202015/Load-balancing%20T omcat%20with%20mod_jk.pdf I'm using the Filter in production and WOW does it make a difference. We used to have to wait for almost a day for users to drain from a node and now it's maybe 30-90 minutes. I have not used the Valve in production because we are on Tomcat 8 (moving to 8.5) and neither version has the Valve in it, yet. Martin, please take the valve for a test-drive if you can and let me know how it goes. It it works for you I'll absolutely back-port it to Tomcat 8.5.x and possibly 8.0.x and 7.0.x. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqzvZkdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFj/5xAAtIb5XbXQj5YGMtVl ZUjq0m2gfZ9C/p5Xtyumd1u5gXLrKLVwhxb9Zx4QF6pSOjvKY2mrbbPiLnILqn/w B2izrvi8Xr8nsIInAcrKV6jwWuQT9rJVLwG7PfkdK6UXmXSxq+HcqW78zpD9y11+ O1QM0PijYDvCbDFY9JME6PJ2EuxNFNLllPsmrJ/Ad/UTOLnWBLCp0IgrE0EP6uUg FAJVS+6EsItcuOL+OmgFnqVkJHkWFeRHC4mL4l9P/RCvgA6g2Hs2vW5uanXKORI4 6fiikmWrDdvoH9oEr01kOFaWGZuIjK6ASqenTsRY3uVIoLAkcrYMR/QCM0dyjq79 eVbhsGAWYACYo9Ah+2qa8kfeW2SzB/t2FOcrEn+VwfQlec7V8sOwvlxhsBTzxy9c 0eyCNi3g65y+oolSoYbap06mr6/8xIevoufhCDuRRFWsCOiDaTDcq5C1+nomWKts YY0QnBemjNpkrQ/v9yXxw9w9VMfFBcf1cnqJ4TZznJ8Lsw/enZHBMEP6VGSB9hoK 09Y+CWp59/nfhRTGASBF2CgmXQlY/wQ4F6EaRMpKO2jCB4FZAnfIfpZ1wgE2vJSZ e+CPUbyHZvcC4Z4+wblEhWvsZefbzhqqjL6fAcoRl5QgH2JpB/Gu4bKglQ5AYYCk sIE8F4q7qjGrRzJsWoshSRfU8HI= =YKKI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
