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