-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 5/12/20 16:14, Mark Eggers wrote: > Chris, > > On 5/12/2020 12:55 PM, Christopher Schultz wrote: >> 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] >> > > This sounds interesting. I wonder how this will play using > multiple availability zones for high availability. It still won't > handle region outages, but there are other approaches for that. I have no idea. There doesn't seem to me to be any reason why Kubernetes could not be used across regions. Maybe you wouldn't be able to use AWS-kube and might have to do it yourself. I have zero experience with Kubernetes, and zero experience with complex AWS deployments. > I'll read the link you sent, and maybe play with that locally with > a Kubernetes setup. If I have questions about the set up, would > here or the dev list be the place to ask? I think here would be better, since the answers will be visible to a wider group of people. I'd love to see a writeup about this, including "how to set up Kubernetes from scratch to manage your Tomcat cluster" because I know literally nothing practical about it. - -chris >>> 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 >>>> >>>> >> >> >> --------------------------------------------------------------------- >> >> 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/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl67BlUACgkQHPApP6U8 pFj9EhAAi/CkDkvoZTVPdLHJS9G2UPmrUaO1JjAgKjfy/9NMxJlkcWZmo08roD9h DeJcDdmvC2dzwuZx7KjoMAvE7TxoNpHurD/ug+/i0hLXDYCUQIbuAQ0EdwZ3rZdQ VwvBaYQy+wjP48ZML0Foi4Qq+JX+ZbMho/XklyqZXRUx7JeX/P7CyrbUwwPqAqRi MiI8M0qoioayrbGAkRWQO6LWJL50+01MH8ydNS3O6x3Wr1VkmoB276qj1Jcb8u4P BRFk+F9yMFy4oBvoH4Qgx8LdoHQc0gBr1oUNZsZceJOxyXrtA+AIhHkU7Nhy2Mf5 6dO7XOiB+8PxK/5mdeqf+1Zi9ZKirqtGhOeGYiMJwkmZa6aOb839j0iRzp+kHpKt qrU4UsfJO9TgDHswArKpsZBuTYQvmKZSeOsJZBlg9TfQakOfHaAVDCF8TXD2D1Zf VSOKWdX7OG9mt0fXP8XRPhyO/m4mPEpA7VNIPPc0nJjZ01iVYnFopBcJ1jIo+yEg 1h9TNUNPEZsuAsQWrDHncqJWUfKES2amd/6kOwoCq8+uKHoaFgBGjnI7jrvZFffQ Ab+wD4epC24Fmw4IBMZ20WcYJxr/SS3xzJKxginvD/QODF67GkoggEZr5c+5kkcL k29lvV8SqIskVgmTVyxq7FInTiF7LY70hRrsQ+E4mlADMB+243U= =yo3D -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
