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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
