tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Meyer <>
Subject Re: Tomcat session replication
Date Wed, 01 Jul 2020 10:31:55 GMT
Am 1. Juli 2020 12:21:46 MESZ schrieb Mark Thomas <>:
>On 01/07/2020 11:19, Thomas Meyer wrote:
>> Am 30. Juni 2020 11:07:36 MESZ schrieb Mark Thomas
>>> 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
>>>>> the client that depend on the session MUST be issued in series,
>>>>> in parallel; and
>>>> This is only true of requests that would modify the session-state
>>> 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
>>> 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
>> 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:

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message