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'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? Thanks! . . . just my two cents /mde/ >> 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 >
signature.asc
Description: OpenPGP digital signature
