You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Thomas Meyer <th...@m3y3r.de> on 2020/06/27 09:19:23 UTC
Tomcat session replication
Hi,
A few questions regarding tomcat session replication:
1) is the jvmRoute attribute on Engine object necessary for session replication to work correctly?
2) does session replication only work correctly with sticky load balancer routing?
My setup is
1) load balancer without sticky session routing into kubernetes
2) two pods running tomcat with cloud member provider, which see and find each other
No jvmRoute attribute is set.
Above setup doesn't work and give strange errors for the distributed webapp which relies on http sessions.
Should above setup work? If not why and what do I need to fix?
Any hints of what logging to enable to debug the problem if any at all?
Mfg
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Thomas Meyer <th...@m3y3r.de>.
Am 1. Juli 2020 12:21:46 MESZ schrieb Mark Thomas <ma...@apache.org>:
>On 01/07/2020 11:19, Thomas Meyer wrote:
>> Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas
><ma...@apache.org>:
>>> On 29/06/2020 21:41, Christopher Schultz wrote:
>>>> Mark,
>>>>
>>>> On 6/27/20 05:29, Mark Thomas wrote:
>>>>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>>>>> Hi,
>>>>>>
>>>>>> A few questions regarding tomcat session replication:
>>>>
>>>>> load-balancing and session replication are two separate parts of
>>>>> an overall clustering solution.
>>>>
>>>>>> 1) is the jvmRoute attribute on Engine object necessary for
>>>>>> session replication to work correctly?
>>>>
>>>>> No, but if you don't use it it places a number of restrictions on
>>>>> the web application behaviour and on the configuration of session
>>>>> replication.
>>>>
>>>>> The limitations are: - you need to use the DeltaManager (which
>>>>> doesn't scale as well as the BackupManager); - any requests made
>by
>>>>> the client that depend on the session MUST be issued in series,
>not
>>>>> in parallel; and
>>>>
>>>> This is only true of requests that would modify the session-state
>in
>>> a
>>>> way that needed to be deterministic, right? A bunch of GET requests
>>>> that don't change the session ought to be okay in parallel (as long
>>> as
>>>> any prior state-changing requests have completed _ those changes
>>>> replicated).
>>>
>>> Yes.
>>> You don't want state changes in parallel on different nodes.
>>> Any request that depends on a previous change in state can't be
>issued
>>> until the state changing request has completed and the changes
>>> replicated.
>>>
>>>>> - the session Manager must be configured to update all the other
>>>>> nodes in the cluster BEFORE the current request returns to the
>>>>> client.
>>>>
>>>> Same (negative) caveat here, right?
>>>
>>> Yes.
>>>
>>> Essentially you want channelSendOptions="6".
>>
>> Hi,
>>
>> Yes I'm using that option. But it still gives an error, but I may now
>found some hints what's going wrong:
>>
>> When using Spring's ChangeSessionIdAuthStrategy it fails with unknown
>CSRF token.
>>
>> It looks like the node fails to replicate, i.e. doesn't export, the
>session data after a changeSessionId call.
>>
>> When using Spring's SessionFixationProtectionStrategy (which
>basically creates a new session and copy all attributes to the new
>session) it works correctly with tomcats session replication.
>>
>> So it looks like calling changeSessionId fails to somehow replication
>the new session state to the remote nodes.
>>
>> Looking at ManagerBase "session" attribute it's unclear if it
>contains only "internal session IDs" or external session IDs which do
>change.
>>
>> The ReplicationValve seems to call manager.findSession with the
>internal ID.
>>
>> Maybe somewhere something mixes up internal and external session IDs
>or forgets to update ManagerBase.session map.
>>
>> Opinions?
>
>Maybe this:
>https://bz.apache.org/bugzilla/show_bug.cgi?id=64560
Yes, that's seems to be exactly the same problem!
And it's already fixed!
Thank you very much!
I'll update our tomcat version from 9.0.34 to the fixed version.
Regards
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Mark Thomas <ma...@apache.org>.
On 01/07/2020 11:19, Thomas Meyer wrote:
> Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas <ma...@apache.org>:
>> On 29/06/2020 21:41, Christopher Schultz wrote:
>>> Mark,
>>>
>>> On 6/27/20 05:29, Mark Thomas wrote:
>>>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>>>> Hi,
>>>>>
>>>>> A few questions regarding tomcat session replication:
>>>
>>>> load-balancing and session replication are two separate parts of
>>>> an overall clustering solution.
>>>
>>>>> 1) is the jvmRoute attribute on Engine object necessary for
>>>>> session replication to work correctly?
>>>
>>>> No, but if you don't use it it places a number of restrictions on
>>>> the web application behaviour and on the configuration of session
>>>> replication.
>>>
>>>> The limitations are: - you need to use the DeltaManager (which
>>>> doesn't scale as well as the BackupManager); - any requests made by
>>>> the client that depend on the session MUST be issued in series, not
>>>> in parallel; and
>>>
>>> This is only true of requests that would modify the session-state in
>> a
>>> way that needed to be deterministic, right? A bunch of GET requests
>>> that don't change the session ought to be okay in parallel (as long
>> as
>>> any prior state-changing requests have completed _ those changes
>>> replicated).
>>
>> Yes.
>> You don't want state changes in parallel on different nodes.
>> Any request that depends on a previous change in state can't be issued
>> until the state changing request has completed and the changes
>> replicated.
>>
>>>> - the session Manager must be configured to update all the other
>>>> nodes in the cluster BEFORE the current request returns to the
>>>> client.
>>>
>>> Same (negative) caveat here, right?
>>
>> Yes.
>>
>> Essentially you want channelSendOptions="6".
>
> Hi,
>
> Yes I'm using that option. But it still gives an error, but I may now found some hints what's going wrong:
>
> When using Spring's ChangeSessionIdAuthStrategy it fails with unknown CSRF token.
>
> It looks like the node fails to replicate, i.e. doesn't export, the session data after a changeSessionId call.
>
> When using Spring's SessionFixationProtectionStrategy (which basically creates a new session and copy all attributes to the new session) it works correctly with tomcats session replication.
>
> So it looks like calling changeSessionId fails to somehow replication the new session state to the remote nodes.
>
> Looking at ManagerBase "session" attribute it's unclear if it contains only "internal session IDs" or external session IDs which do change.
>
> The ReplicationValve seems to call manager.findSession with the internal ID.
>
> Maybe somewhere something mixes up internal and external session IDs or forgets to update ManagerBase.session map.
>
> Opinions?
Maybe this:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64560
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Thomas Meyer <th...@m3y3r.de>.
Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas <ma...@apache.org>:
>On 29/06/2020 21:41, Christopher Schultz wrote:
>> Mark,
>>
>> On 6/27/20 05:29, Mark Thomas wrote:
>>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>>> Hi,
>>>>
>>>> A few questions regarding tomcat session replication:
>>
>>> load-balancing and session replication are two separate parts of
>>> an overall clustering solution.
>>
>>>> 1) is the jvmRoute attribute on Engine object necessary for
>>>> session replication to work correctly?
>>
>>> No, but if you don't use it it places a number of restrictions on
>>> the web application behaviour and on the configuration of session
>>> replication.
>>
>>> The limitations are: - you need to use the DeltaManager (which
>>> doesn't scale as well as the BackupManager); - any requests made by
>>> the client that depend on the session MUST be issued in series, not
>>> in parallel; and
>>
>> This is only true of requests that would modify the session-state in
>a
>> way that needed to be deterministic, right? A bunch of GET requests
>> that don't change the session ought to be okay in parallel (as long
>as
>> any prior state-changing requests have completed _ those changes
>> replicated).
>
>Yes.
>You don't want state changes in parallel on different nodes.
>Any request that depends on a previous change in state can't be issued
>until the state changing request has completed and the changes
>replicated.
>
>>> - the session Manager must be configured to update all the other
>>> nodes in the cluster BEFORE the current request returns to the
>>> client.
>>
>> Same (negative) caveat here, right?
>
>Yes.
>
>Essentially you want channelSendOptions="6".
Hi,
Yes I'm using that option. But it still gives an error, but I may now found some hints what's going wrong:
When using Spring's ChangeSessionIdAuthStrategy it fails with unknown CSRF token.
It looks like the node fails to replicate, i.e. doesn't export, the session data after a changeSessionId call.
When using Spring's SessionFixationProtectionStrategy (which basically creates a new session and copy all attributes to the new session) it works correctly with tomcats session replication.
So it looks like calling changeSessionId fails to somehow replication the new session state to the remote nodes.
Looking at ManagerBase "session" attribute it's unclear if it contains only "internal session IDs" or external session IDs which do change.
The ReplicationValve seems to call manager.findSession with the internal ID.
Maybe somewhere something mixes up internal and external session IDs or forgets to update ManagerBase.session map.
Opinions?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Mark Thomas <ma...@apache.org>.
On 29/06/2020 21:41, Christopher Schultz wrote:
> Mark,
>
> On 6/27/20 05:29, Mark Thomas wrote:
>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>> Hi,
>>>
>>> A few questions regarding tomcat session replication:
>
>> load-balancing and session replication are two separate parts of
>> an overall clustering solution.
>
>>> 1) is the jvmRoute attribute on Engine object necessary for
>>> session replication to work correctly?
>
>> No, but if you don't use it it places a number of restrictions on
>> the web application behaviour and on the configuration of session
>> replication.
>
>> The limitations are: - you need to use the DeltaManager (which
>> doesn't scale as well as the BackupManager); - any requests made by
>> the client that depend on the session MUST be issued in series, not
>> in parallel; and
>
> This is only true of requests that would modify the session-state in a
> way that needed to be deterministic, right? A bunch of GET requests
> that don't change the session ought to be okay in parallel (as long as
> any prior state-changing requests have completed _ those changes
> replicated).
Yes.
You don't want state changes in parallel on different nodes.
Any request that depends on a previous change in state can't be issued
until the state changing request has completed and the changes replicated.
>> - the session Manager must be configured to update all the other
>> nodes in the cluster BEFORE the current request returns to the
>> client.
>
> Same (negative) caveat here, right?
Yes.
Essentially you want channelSendOptions="6".
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 6/27/20 05:29, Mark Thomas wrote:
> On 27/06/2020 10:19, Thomas Meyer wrote:
>> Hi,
>>
>> A few questions regarding tomcat session replication:
>
> load-balancing and session replication are two separate parts of
> an overall clustering solution.
>
>> 1) is the jvmRoute attribute on Engine object necessary for
>> session replication to work correctly?
>
> No, but if you don't use it it places a number of restrictions on
> the web application behaviour and on the configuration of session
> replication.
>
> The limitations are: - you need to use the DeltaManager (which
> doesn't scale as well as the BackupManager); - any requests made by
> the client that depend on the session MUST be issued in series, not
> in parallel; and
This is only true of requests that would modify the session-state in a
way that needed to be deterministic, right? A bunch of GET requests
that don't change the session ought to be okay in parallel (as long as
any prior state-changing requests have completed _ those changes
replicated).
> - the session Manager must be configured to update all the other
> nodes in the cluster BEFORE the current request returns to the
> client.
Same (negative) caveat here, right?
>> 2) does session replication only work correctly with sticky load
>> balancer routing?
>
> No. It works quite happily without it.
>
>>
>> My setup is 1) load balancer without sticky session routing into
>> kubernetes 2) two pods running tomcat with cloud member provider,
>> which see and find each other
>>
>> No jvmRoute attribute is set.
>>
>> Above setup doesn't work and give strange errors for the
>> distributed webapp which relies on http sessions.
>>
>> Should above setup work? If not why and what do I need to fix?
>>
>> Any hints of what logging to enable to debug the problem if any
>> at all?
>
> Please show us how you have configured the session manager and
> clustering.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76UgcACgkQHPApP6U8
pFjoNQ//TbmZA3oh1ISz3ogBK9Txb/VH1qXnJ8+Y/uP0sjK45p88vd+hoqfAyQ98
8faqgN5/IuuYCnGPYlySGDfF2b2rfXL2umq5P62rjYnDBEsWulIix4dYxNLDqZF6
GeK7lKGXABAM+gJXxbyXELEwjnppP2qCYE+gSTzwJH3Jnz4UMj2oT9bjZjBp1jOy
7CaXY0VYnVqLZhbHwTmUC4A1eIQrzN+4Cag3FVoWE2oLUpi1/GK6iYmDJpy2owA/
1kirT89sMqehaoTS02EnBfSusX9DN0qDmUK0ddxtv8jUiEz408+ujs5YPRuVG71z
5ISuymx9Sf8e9RA+TFNm252PIJWKtumi9uddG0As/FF4Qy+LMmY94RX+aXyBcQU9
r0A1nkX8/UmjqaUx61um2/t2PDfTBCDwl0ORat4ERHHc0vfQLYnvPYLZzKj/jNn6
guflkExS5qpwbiuvWFgvFiFTAi9Og5tF2ks+sqdb3PWoie2snStGKboivQKof4qb
7BStuSWVP1aeUieGn7fqCWhLlr9VSC0r2czEShkVde4TWC/cV5F38NfSGmbYssrQ
97zjbup6+/fL5MKmOaoDY2kOS1/XPzrB/BDK+d83w98cb03txezZCwtM2QPzn/48
1QvL3n3XMna31XHa8ljHldrX2c7bm2lpkhJPL5269pFznMRZOA4=
=Lg+P
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Thomas Meyer <th...@m3y3r.de>.
Am 29. Juni 2020 22:54:12 MESZ schrieb Christopher Schultz <ch...@christopherschultz.net>:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Thomas,
Hi,
>
>On 6/27/20 05:52, Thomas Meyer wrote:
>> Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas
>> <ma...@apache.org>:
>>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>>> Hi,
>>>>
>>>> A few questions regarding tomcat session replication:
>>>
>>> load-balancing and session replication are two separate parts of
>>> an overall clustering solution.
>>>
>>>> 1) is the jvmRoute attribute on Engine object necessary for
>>>> session
>>> replication to work correctly?
>>>
>>> No, but if you don't use it it places a number of restrictions on
>>> the web application behaviour and on the configuration of
>>> session replication.
>>>
>>> The limitations are: - you need to use the DeltaManager (which
>>> doesn't scale as well as the BackupManager);
>>
>> Yes, I'm using default DeltaManager as I will only have two pods
>> running Tomcat.
>>
>>> - any requests made by the client that depend on the session MUST
>>> be issued in series, not in parallel; and
>>
>> Not sure about this one, the app uses spring default security for
>> login. So need to check this one.
>
>This has more to do with how your web application itself works and
>less about your security framework. For example, if you have a
>web-1.0-style web application which is mostly user-driven GET and POST
>requests, then you are probably fine with the occasional
>user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event.
>
>But if you have a web-2.0 style
>websocket/AJAX/many-things-happening-at-once-style application, then
>you are probably going to have problems without sticky sessions.
Yes, okay understood.
Webapp is a traditional request/reply jsp app. So nothing fancy going on.
>
>>> - the session Manager must be configured to update all the other
>>> nodes in the cluster BEFORE the current request returns to the
>>> client.
>>
>> How to do that? I did have a look at Manager/DeltaManager
>> attributes but didn't see something that looks like above setting.
>> Can you plea point me in the right direction?
>
>http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Infor
>mation
>
>This is done using channelSendOptions on the <Cluster> and
>mapSendOptions on the ReplicationValve. The default value is to be
>synchronous, which would be required, here. Synchronous means that the
>data is replicated before the response is completed to the client. You
>could also do asynchronous which would allow the request to complete
>and queue the replication for "later" (but probably pretty shortly
>thereafter).
Yes I also found out that simple tcp cluster had this option, but async is the default for some reason:
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/ha/tcp/SimpleTcpCluster.java#L152
I tried ack and sync-ack but I still see "session not found errors".
I'll check replication valve setting.
In the meantime I also did enable tribes message logging, and tried to find out what goes wrong, but have not yet fully understand the problem.
The error seems to happen in springs csrf filter which stores a uuid token in the http sessions.
Also a change session id happens in between. Everything looks actually okay, but it doesn't work.
>
>>>> 2) does session replication only work correctly with sticky
>>>> load
>>> balancer routing?
>>>
>>> No. It works quite happily without it.
>>
>> Good to know.
>
>You might want to use sticky-sessions anyway.
>
>>>> My setup is 1) load balancer without sticky session routing
>>>> into kubernetes 2) two pods running tomcat with cloud member
>>>> provider, which see and
>>> find each other
>>>>
>>>> No jvmRoute attribute is set.
>>
>> Another question regarding jvmRoute: Even if my load balancer has
>> no sticky sessions, should I add jvmRoute attribute? I think I
>> could easily add the pod's name as jvmRoute.
>
>If it's no particular trouble, I would:
>
>1. Add jvmRoute
>2. Enable sticky sessions
>
>#2 just means that all requests for an session-holding client will be
>directed to a single Tomcat node. If fail-over is necessary, the other
>node will have the session-information that was last sent successfully
>and should be relatively up-to-date. The session-id will be changed
>upon fail-over and the user shouldn't really notice unless some
>replication message was lost.
>
>IMHO the only potential downside to non-sticky-sessions is that it's
>possible for one of your nodes to "collect" more users than the others
>and give you a lop-sided load-profile across your nodes. Unless that's
>a particular concern for you (and, for most applications, it's not a
>problem at all), I would enable sticky-sessions because it avoids a
>lot of race-conditions and other performance-related issues with
>cluster
>s.
>
>This isn't Tomcat-specific: it's just the nature of the beast.
Okay.
>>>> Above setup doesn't work and give strange errors for the
>>>> distributed
>>> webapp which relies on http sessions.
>>>>
>>>> Should above setup work? If not why and what do I need to fix?
>>>>
>>>> Any hints of what logging to enable to debug the problem if any
>>>> at
>>> all?
>>>
>>> Please show us how you have configured the session manager and
>>> clustering.
>>
>> My setup is just go with the defaults:
>>
>> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
>> <Channel
>> className="org.apache.catalina.tribes.group.GroupChannel">
>> <Membership
>>
>className="org.apache.catalina.tribes.membership.cloud.CloudMembership
>Service"
>>
>>
>membershipProviderClassName="org.apache.catalina.tribes.membership.cloud
>.DNSMembershipProvider"/>
>> </Channel> </Cluster>
>
>So pretty much default-everything (except maybe the CloudMembership).
>
>> In the logs I can see the member appears/disappears messages, which
>> is a good thing I guess.
>
>It is!
>
>Unless you can think of a particular reason NOT to enable
>sticky-sessions, I'd go ahead and do it.
I didn't know how to do it :-)
But in the meantime I found out how to configure AVI appliance to do sticky sessions.
But I first I want to find out and understand why the current setup doesn't work.
>
>Remember that your reverse-proxy needs to understand how to handle
>session stickiness, though. What are you using for
>load-balancing/reverse-proxying in this environment?
>
>- -chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Thomas,
On 6/27/20 05:52, Thomas Meyer wrote:
> Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas
> <ma...@apache.org>:
>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>> Hi,
>>>
>>> A few questions regarding tomcat session replication:
>>
>> load-balancing and session replication are two separate parts of
>> an overall clustering solution.
>>
>>> 1) is the jvmRoute attribute on Engine object necessary for
>>> session
>> replication to work correctly?
>>
>> No, but if you don't use it it places a number of restrictions on
>> the web application behaviour and on the configuration of
>> session replication.
>>
>> The limitations are: - you need to use the DeltaManager (which
>> doesn't scale as well as the BackupManager);
>
> Yes, I'm using default DeltaManager as I will only have two pods
> running Tomcat.
>
>> - any requests made by the client that depend on the session MUST
>> be issued in series, not in parallel; and
>
> Not sure about this one, the app uses spring default security for
> login. So need to check this one.
This has more to do with how your web application itself works and
less about your security framework. For example, if you have a
web-1.0-style web application which is mostly user-driven GET and POST
requests, then you are probably fine with the occasional
user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event.
But if you have a web-2.0 style
websocket/AJAX/many-things-happening-at-once-style application, then
you are probably going to have problems without sticky sessions.
>> - the session Manager must be configured to update all the other
>> nodes in the cluster BEFORE the current request returns to the
>> client.
>
> How to do that? I did have a look at Manager/DeltaManager
> attributes but didn't see something that looks like above setting.
> Can you plea point me in the right direction?
http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html#Cluster_Infor
mation
This is done using channelSendOptions on the <Cluster> and
mapSendOptions on the ReplicationValve. The default value is to be
synchronous, which would be required, here. Synchronous means that the
data is replicated before the response is completed to the client. You
could also do asynchronous which would allow the request to complete
and queue the replication for "later" (but probably pretty shortly
thereafter).
>>> 2) does session replication only work correctly with sticky
>>> load
>> balancer routing?
>>
>> No. It works quite happily without it.
>
> Good to know.
You might want to use sticky-sessions anyway.
>>> My setup is 1) load balancer without sticky session routing
>>> into kubernetes 2) two pods running tomcat with cloud member
>>> provider, which see and
>> find each other
>>>
>>> No jvmRoute attribute is set.
>
> Another question regarding jvmRoute: Even if my load balancer has
> no sticky sessions, should I add jvmRoute attribute? I think I
> could easily add the pod's name as jvmRoute.
If it's no particular trouble, I would:
1. Add jvmRoute
2. Enable sticky sessions
#2 just means that all requests for an session-holding client will be
directed to a single Tomcat node. If fail-over is necessary, the other
node will have the session-information that was last sent successfully
and should be relatively up-to-date. The session-id will be changed
upon fail-over and the user shouldn't really notice unless some
replication message was lost.
IMHO the only potential downside to non-sticky-sessions is that it's
possible for one of your nodes to "collect" more users than the others
and give you a lop-sided load-profile across your nodes. Unless that's
a particular concern for you (and, for most applications, it's not a
problem at all), I would enable sticky-sessions because it avoids a
lot of race-conditions and other performance-related issues with cluster
s.
This isn't Tomcat-specific: it's just the nature of the beast.
>>> Above setup doesn't work and give strange errors for the
>>> distributed
>> webapp which relies on http sessions.
>>>
>>> Should above setup work? If not why and what do I need to fix?
>>>
>>> Any hints of what logging to enable to debug the problem if any
>>> at
>> all?
>>
>> Please show us how you have configured the session manager and
>> clustering.
>
> My setup is just go with the defaults:
>
> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
> <Channel
> className="org.apache.catalina.tribes.group.GroupChannel">
> <Membership
> className="org.apache.catalina.tribes.membership.cloud.CloudMembership
Service"
>
>
membershipProviderClassName="org.apache.catalina.tribes.membership.cloud
.DNSMembershipProvider"/>
> </Channel> </Cluster>
So pretty much default-everything (except maybe the CloudMembership).
> In the logs I can see the member appears/disappears messages, which
> is a good thing I guess.
It is!
Unless you can think of a particular reason NOT to enable
sticky-sessions, I'd go ahead and do it.
Remember that your reverse-proxy needs to understand how to handle
session stickiness, though. What are you using for
load-balancing/reverse-proxying in this environment?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76VPQACgkQHPApP6U8
pFi0Ug/8Ck2gLtvvFqQf+UpYuIGew4KrgnkU3eD/7A+Hae71xiOXvn1Sq8TDW1Az
V5GopvxYFmJ78omwvS6bCRw7Vz/iWUYT+5GFWcZ1PZpbzew6utXXraJwh6v+WdxX
l+wpQOmlHIk9rVlVuuTi24+sLBd3eRO2OZ/mxqEfGSLZobjfZIAKURImjMIdsaha
jUcQ7HXI4oMUtD6Avxiqvjh8ruYGAD/LKbwHW5J9ND+F997wNiEyRRSNuHKU3kFg
bQTYUfHDibLPjD43otuRC3jeV5cNc1+ztbL1NVRqWSpizY6TS54sw/YRXlhWWJbZ
/yfANil7AUCP9K1FK6aZRUzoXy1IVU3NXxiLF+WPMCsE9eXZ+nWDM8fMO8cjqXYJ
O0xwT4HP5yA6Fl5vAZvCinYMw5s45cuKl8aOm4/982y3tTSUybMcBxtIePRXil0T
TFXRAncmve9MxtbHGGRrELf27ytyIOuQciFXdrZ1z/iWPyqCGL/34Lp4kzzPiL0L
fa94F6x7gFwAHNHleC+9fVg4nyGyK0Am6t9LlnQX7BF5SYnRI17YPUg0KLqCj/iE
D9iHTnZQEgH9hp8DudMNfUQeZSR/qRaGzQhCldYBoM417vLit+T4P1KqoBET+xsX
1vgaVRdH12pKI3wrBAh7DiFXTHo/N1NlBXTBGyfPaTLAHOJVap0=
=yfLR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Thomas Meyer <th...@m3y3r.de>.
Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas <ma...@apache.org>:
>On 27/06/2020 10:19, Thomas Meyer wrote:
>> Hi,
>>
>> A few questions regarding tomcat session replication:
>
>load-balancing and session replication are two separate parts of an
>overall clustering solution.
>
>> 1) is the jvmRoute attribute on Engine object necessary for session
>replication to work correctly?
>
>No, but if you don't use it it places a number of restrictions on the
>web application behaviour and on the configuration of session
>replication.
>
>The limitations are:
>- you need to use the DeltaManager (which doesn't scale as well as the
> BackupManager);
Yes, I'm using default DeltaManager as I will only have two pods running Tomcat.
>- any requests made by the client that depend on the session MUST be
> issued in series, not in parallel; and
Not sure about this one, the app uses spring default security for login. So need to check this one.
>- the session Manager must be configured to update all the other nodes
> in the cluster BEFORE the current request returns to the client.
How to do that? I did have a look at Manager/DeltaManager attributes but didn't see something that looks like above setting. Can you plea point me in the right direction?
>
>> 2) does session replication only work correctly with sticky load
>balancer routing?
>
>No. It works quite happily without it.
Good to know.
>
>>
>> My setup is
>> 1) load balancer without sticky session routing into kubernetes
>> 2) two pods running tomcat with cloud member provider, which see and
>find each other
>>
>> No jvmRoute attribute is set.
Another question regarding jvmRoute:
Even if my load balancer has no sticky sessions, should I add jvmRoute attribute? I think I could easily add the pod's name as jvmRoute.
>>
>> Above setup doesn't work and give strange errors for the distributed
>webapp which relies on http sessions.
>>
>> Should above setup work? If not why and what do I need to fix?
>>
>> Any hints of what logging to enable to debug the problem if any at
>all?
>
>Please show us how you have configured the session manager and
>clustering.
My setup is just go with the defaults:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.cloud.CloudMembershipService"
membershipProviderClassName="org.apache.catalina.tribes.membership.cloud.DNSMembershipProvider"/>
</Channel>
</Cluster>
In the logs I can see the member appears/disappears messages, which is a good thing I guess.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat session replication
Posted by Mark Thomas <ma...@apache.org>.
On 27/06/2020 10:19, Thomas Meyer wrote:
> Hi,
>
> A few questions regarding tomcat session replication:
load-balancing and session replication are two separate parts of an
overall clustering solution.
> 1) is the jvmRoute attribute on Engine object necessary for session replication to work correctly?
No, but if you don't use it it places a number of restrictions on the
web application behaviour and on the configuration of session replication.
The limitations are:
- you need to use the DeltaManager (which doesn't scale as well as the
BackupManager);
- any requests made by the client that depend on the session MUST be
issued in series, not in parallel; and
- the session Manager must be configured to update all the other nodes
in the cluster BEFORE the current request returns to the client.
> 2) does session replication only work correctly with sticky load balancer routing?
No. It works quite happily without it.
>
> My setup is
> 1) load balancer without sticky session routing into kubernetes
> 2) two pods running tomcat with cloud member provider, which see and find each other
>
> No jvmRoute attribute is set.
>
> Above setup doesn't work and give strange errors for the distributed webapp which relies on http sessions.
>
> Should above setup work? If not why and what do I need to fix?
>
> Any hints of what logging to enable to debug the problem if any at all?
Please show us how you have configured the session manager and clustering.
Mark
> Mfg
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org