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:


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

Reply via email to