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