-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jonathan,
On 5/12/20 11:20, Jonathan Yom-Tov wrote: > The problem is that my application is running on AWS which > apparently doesn't support multicasting so I can't use Tomcat's > DeltaManager. The membership-manager is separate from the replication-manager, so this has nothing to do with e.g. DeltaManager. You don't have to use multicast. You can use static membership if you know your node IP addresses. Rémy recently added a cloud membership service that uses Kubernetes as its default membership service. It looks like he hasn't written any documentation for it, but it exists in Tomcat 9 and 10.[1] > I thought of using one of the Store implementations for > PersistentManager but that has the issues which I mentioned > earlier. My aim is to get to the point where I can add or take away > servers from the cluster without impacting user experience. See above. Sounds like the cloud membership service is what you are looking for because it (a) handles dynamic membership and (b) doesn't use multicast. > Ideally all state would be stored in a central location (e.g. > Redis). But, since this is difficult because of the way the > application is built I thought of using one server and only > persisting the sessions when the server goes down. But I still have > to solve the issues I mentioned. I would avoid single points of failure if possible. A "central location" tends to be a single point of failure. Tomcat clustered with e.g. BackupManager and dynamic membership will (a) achieve your goals and (b) not require additional products. Hope that helps, - -chris [1] https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/tr ibes/membership/cloud/CloudMembershipService.java#L34 > On Tue, May 12, 2020 at 6:06 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Jonathan, > > On 5/12/20 05:51, Jonathan Yom-Tov wrote: >>>> I have an application which changes the state of user >>>> sessions in lots of places in the code. Is it possible to do >>>> a seamless switch of Tomcat servers, preserving all >>>> sessions? >>>> >>>> I know I can use PersistentManager to persist sessions and >>>> load them. I can think of two strategies: >>>> >>>> 1. Persist sessions periodically. This is more robust as I >>>> might not have control of when the server shuts down. 2. >>>> Persist sessions on server shutdown. >>>> >>>> >>>> The problem with the first approach is that I might lose the >>>> latest changes when the new server comes up. The problem with >>>> the second is that I'll have to lock access to the session >>>> until the old server is done saving it, which may make >>>> response times very slow. >>>> >>>> Is there a good solution to this that I might have >>>> overlooked? > > If you want to solve these problems: > > 1. Seamless (uninterrupted) restarts 2. Always up-to-date (well, as > much as possible) 3. No downtime > > Then you really need a cluster where the sessions are being > replicated around the cluster. > > This will solve some other problems as well: > > 4. Expected downtime (e.g. OS/Tomcat/application upgrade) 5. > Unexpected downtime (network outage, hardware fault) 6. Scaling-out > (either manually or automatically) > > You can do it with as little as two Tomcat instances. If you only > care about being able to restart your application (and not the > whole server, for example), then you can even run them side-by-side > on the same server. You won't get protection against OS upgrades > and unexpected downtime in that case, but you can get familiar with > the setup without a whole lot of infrastructure. > > -chris >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl66/x4ACgkQHPApP6U8 pFhd8g//fAo+sX47/md+l9ZxwJnSLWic4c7idAOv1tm3C4PqkQacdfUmaq1jVurc g9ZMh5NucdM65iubtkXtQrGOyO99kz2ZT9zrz3aFGyF3LY/F0YT3+i8bRtHyDTPp ATEIJ4Bk+TkoHRRWTzJU3R6SMxa055KLBaEUWKUx8mEaXWNT+/bVtmxigKE0z2Ja 6qI6S1IzAdELRHUd2oVT5IjyBV/b2mjDG7N5YAJGNeCQ2obNrKBuQHdSElcA0Bjn kXQo+ZHO1pvoMutgV49dvlAeT6u87KnNTPfwJcb0uEO4Eof7NbTswy40lASBRfp2 kRNrdFal/IE9wYUZF8GjVRU1kHOQB0+T8ZeW9hvpCvEsBWKwP74sPHVp71uudW/5 Ggxo5JkoIRvsi+2b6wPhRlQX4YG3awoBoZrGRSDGRaQttdh732hUVbvzSv9b2Z6F JD0xSy8G5fqPUwouwrF3HIneszrZif1ZoDB6M/Py5i9Fs4F4UxagIEfb59/lTgy+ 7GI/fgNV28rjR9QQJXWRp4j8uRreagSDK1Aehfq7cbAPdTpnh+yQlIkeCgYS3A05 wEzFcOlllLb6XW6UBle9GtY72opF/nAZGtToGeGiZvlP+t2x49aBdy6rN21oSyVC BazreimVfhfS2FrYxYMOJJ8Fj52bSJgIj3dM39vvWpAdnjckg5k= =8cBm -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
