-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Thomas,
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. >> - 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). >>> 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. >>> 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. 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 -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl76VPQACgkQHPApP6U8 pFi0Ug/8Ck2gLtvvFqQf+UpYuIGew4KrgnkU3eD/7A+Hae71xiOXvn1Sq8TDW1Az V5GopvxYFmJ78omwvS6bCRw7Vz/iWUYT+5GFWcZ1PZpbzew6utXXraJwh6v+WdxX l+wpQOmlHIk9rVlVuuTi24+sLBd3eRO2OZ/mxqEfGSLZobjfZIAKURImjMIdsaha jUcQ7HXI4oMUtD6Avxiqvjh8ruYGAD/LKbwHW5J9ND+F997wNiEyRRSNuHKU3kFg bQTYUfHDibLPjD43otuRC3jeV5cNc1+ztbL1NVRqWSpizY6TS54sw/YRXlhWWJbZ /yfANil7AUCP9K1FK6aZRUzoXy1IVU3NXxiLF+WPMCsE9eXZ+nWDM8fMO8cjqXYJ O0xwT4HP5yA6Fl5vAZvCinYMw5s45cuKl8aOm4/982y3tTSUybMcBxtIePRXil0T TFXRAncmve9MxtbHGGRrELf27ytyIOuQciFXdrZ1z/iWPyqCGL/34Lp4kzzPiL0L fa94F6x7gFwAHNHleC+9fVg4nyGyK0Am6t9LlnQX7BF5SYnRI17YPUg0KLqCj/iE D9iHTnZQEgH9hp8DudMNfUQeZSR/qRaGzQhCldYBoM417vLit+T4P1KqoBET+xsX 1vgaVRdH12pKI3wrBAh7DiFXTHo/N1NlBXTBGyfPaTLAHOJVap0= =yfLR -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
