[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: mod_jk and session stickiness
From:       Christopher Schultz <chris () christopherschultz ! net>
Date:       2015-01-30 14:14:19
Message-ID: 54CB91BB.30004 () christopherschultz ! net
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rainer,

On 1/30/15 5:57 AM, Rainer Jung wrote:
> Am 30.01.2015 um 03:06 schrieb Christopher Schultz:
>> On 7/23/14 5:14 PM, Christopher Schultz wrote:
>>> Rainer,
>>> 
>>> On 7/23/14, 4:10 PM, Rainer Jung wrote:
>>>> Am 23.07.2014 um 21:03 schrieb Christopher Schultz:
>>> 
>>>>> On 7/23/14, 1:49 PM, Rainer Jung wrote:
>>> 
>>>>>> The other case, a request with an invalid session ID 
>>>>>> accessing a tomcat instance with activation disabled can
>>>>>> IMHO be handled by a filter that
>>>>>> 
>>>>>> - checks whether the request has a valid session using 
>>>>>> getSession(false), if it has one, let the request
>>>>>> proceed
>>>>>> 
>>>>>> - checks activation state, if "active", let the request 
>>>>>> proceed
>>>>>> 
>>>>>> - checks the request method, if not GET, let the request 
>>>>>> proceed
>>>>>> 
>>>>>> - otherwise:
>>>>>> 
>>>>>> - set the session cookie, e.g. JSESSIONID the an empty
>>>>>> value - issue an external redirect to the same request
>>>>>> URL - optional redirect loop detection: add a query
>>>>>> string param or cookie that gets the local jvmRoute
>>>>>> appended during each redirect. Before doing the redirect,
>>>>>> check that the local jvmRoute is not already part of that
>>>>>> token (we have already been here before)
>>>>>> 
>>>>>> This would not really interfere with your saved
>>>>>> requests: they would get a redirect which the browser
>>>>>> follwos automatically and after that you will observe the
>>>>>> normal behavior.
>>>>> 
>>>>> This is exactly what I have implemented -- as a Filter
>>>>> since we can insert it before SecurityFilter intercepts the
>>>>> requests -- and my tests suggest that it will work
>>>>> correctly.
>>>>> 
>>>>> I added code to strip-out any ;jsessionid path parameter
>>>>> from the URL
>>> 
>>>> ACK
>>> 
>>>>> if it exists, but haven't done any of the redirect loop 
>>>>> detection (yet). I think the loop detection is going to
>>>>> have to keep a running list of visited nodes which, in
>>>>> large clusters, could grow very large especially if the
>>>>> node names are long. I'll post my code when it's a little
>>>>> more featureful.
>>> 
>>>> As long as nothing goes wrong, the first redirect - having
>>>> no more session info - should not end up in getting
>>>> redirected as well, because it should only be send to an
>>>> active node by mod_jk. So you can even stop redirecting if
>>>> you detect, that it already happened once. For a large
>>>> cluster that might be better.
>>> 
>>>> Multiple might happen (didn't check the code), if all active 
>>>> members are in error state. Even then one would not like to 
>>>> produce many of those redirects for one request, so again,
>>>> only allowing one redirect might be the right solution.
>>> 
>>> That's a good thought, and simplifies things. The request 
>>> parameter could then just be a boolean flag and not actually 
>>> identify the node that produced the redirect: any node
>>> considering redirecting simply would not redirect if that flag
>>> had been set.
>> 
>> So, I've implemented all of the above and just given it a real 
>> test-drive in production. It seems to work well on the first
>> shot.
> 
> Good!
> 
>> I'll be testing it a bit more as time does on, actually. I also 
>> converted it to a Valve that I will propose to include in Tomcat
>> once I get some real mileage on it.
> 
> Was a Valve more useful than a filter? Did you need to access
> Tomcat internals?

I can do everything without using Tomcat internals *except* for
determining whether or not the cookie path should end with a "/". I'll
have to make that part of the configuration, and have it default to
"true". That's the only part that isn't exposed by the Servlet API.

(This was one of the things that bit me when deploying this recently.)

I got crickets when posting a while back to the dev list:
http://markmail.org/thread/4oldeombollmp2dw

Feel free to lend your opinion.

>> I also discovered that I'd like to have a new feature: the
>> ability for a whitelisted client to ignore the re-balance rules
>> and continue to contact the server. So, if you have a cluster
>> member called, say, "foo" and you want to force your way into
>> "foo", you can make a request to any page with a jsessionid
>> parameter:
>> 
>> http://host/some_page;jsessionid=1234.foo
>> 
>> mod_jk will send you to the "foo" node, even though it is in the 
>> DISABLED state.
>> 
>> Normally, my Filter/Valve would see that you have no valid
>> session ("1234.foo" is not valid) and perform a redirect without
>> the "jsessionid" path parameter added, thus re-balancing you to
>> another node.
>> 
>> Instead, I've added the ability to configure an "ignore" cookie
>> and cookie value (like "ignore=SECRETCODE"). If the client
>> presents this cookie to the Filter/Valve, then it's business as
>> usual.
>> 
>> This allows a trusted user to log into the DISABLED node through
>> the load-balancer to take a look around, make sure that things
>> are working properly, etc. before re-enabling the node in the
>> cluster. I'll give this a shot in the next few days, clean it all
>> up, and publish it (soon?).
> 
> That sounds useful.

I'm testing it in development right now.

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUy5G7AAoJEBzwKT+lPKRYn3MP/3KTIAq8QP8CqyEQR1ckXLWM
668XN5YfolSnwWloaeoihEUgwbZBoXNDK9jdEqXcMEzf0cwsHipCRp/PHhejSFNy
Q7iiDGbHsiXr3fzWXEOCdKiiHLHvMYr0KVff4TefQUvK06LgS8zupgp/PJ3mymfr
xjBmBrzpg5rljZ8PeYVI6csr85E0lL15WWwCSDS+AM/NHYR6UELcvXUCwMDOINe+
0UgZwgbYvbSpIPHZ2i30WZHQCA3DJJ4RpNpm7pT6jhptp2WflAWlAAPQYaifHVlz
+VbMVzrbPLSs/JLa+rIAih5jXqYMLcsYJ1RxxkrbTHGRFcBY2IAq2eFuCxyZ5Wfq
hECQXqFJyosADx1fBNvdmnDOXb60JmYnX6r1nu0aZ1jZImsZSgsW4Ca9IoSBKv4A
NY27n1kmMvqyqskizB5IYpo/7M3PDqBhdzhF9D9aDR4Llpx5oi7PlLa/xUPghPzV
BAxO2w/qUi9UCjzCI7MHDkEV29BzmJYhNhfcaRZBLFiU86xY8no/2b2Ezxq6pOC/
J/Fmv0pZ+vWPa/F+K5abwdLr3FTiLPJa4DFazry/BfBCaH00Lb0vFXUG677dXSmK
o2CfxzSB8tXR6qAuLQHtas/FrBd/Gm9guHNh8ncjRim4kurHFFsU4v5YWeW5hP/u
IYX8/t+qznF263F9G+8U
=lZOs
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]