On 5/12/2020 1:25 PM, Christopher Schultz wrote:
> 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.

That sounds reasonable. I know a lot of the devs read this group, so
hopefully (once I get started) there will be some answers.

> 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.

That and tying it into a cloud environment should be interesting. I'll
need to think about this before writing stuff on a mailing list, let
alone a document.

I'm just starting my journey through Docker / Kubernetes. I've put
together some simple images locally, and even have a private repository
set up running on Nexus 3. My experience with Kubernetes clusters is
limited to running "canned" environments.

It looks like an interesting road.

. . . just my two cents.

> -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]
> /tr
> ibes/membership/cloud/
>>>> On Tue, May 12, 2020 at 6:06 PM Christopher Schultz <
>>>>> 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:
> For additional commands, e-mail:

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to