Hash: SHA256


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

> 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
>>> 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
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to