Hi Rainer,
so basically I took the Apache path and ended up with the following brute
force method:
RewriteCond "%{REQUEST_METHOD}" "GET"
RewriteRule ^/xxx/facelets/logon.xhtml$ - [E=login_jsid:%{HTTP_COOKIE}]
CustomLog "/opt/xxx/apache2/logs/login_log" xxxlogheader env=login_jsid
RequestHeader unset Cookie env=login_jsid
GET requests on the login page from the same client/browser now end up on
different nodes.
Looking at JK_STICKY_IGNORE, this seems also to work as well:
RewriteCond "%{REQUEST_METHOD}" "GET"
RewriteRule ^/xxx/facelets/logon.xhtml$ - [E=JK_STICKY_IGNORE]
CustomLog "/opt/xxx/apache2/logs/login_log" xxxlogheader
env=JK_STICKY_IGNORE
I like this actually better, as it does not need to mess with the Cookie.
This is better when components like SiteMinder (for SSO) are involved. I
will give that into our testing/integration environments to see whether we
have any bad side effects.
So thanks again for the valuable input. I will also have a look at the
filter/valve suggestions. But they look more intrusive and getting approval
[did I say big professional organisation somewhere :-)] for that might be
more difficult.
Cheers
Martin
On Thu, Mar 22, 2018 at 3:07 PM, Rainer Jung <rainer.j...@kippdata.de>
wrote:
> 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/conne
> ctors-doc/reference/uriworkermap.html#Rule%20extensions. If you are
> instead using JkMount style maps, look for JK_STICKY_IGNORE in
> http://tomcat.apache.org/connectors-doc/reference/apache.
> html#Advanced%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.
>
> HTH,
>
> Rainer
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
--
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
