-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jonathan,
On 5/12/20 14:19, Jonathan Yom-Tov wrote:
> Thanks Mark. I've tried to use Redisson, it would've been the
> perfect solution for this except for the fact that my session
> object is a deep tree which is mutated in many areas of the code.
> So what happens is that as one request is changing the session
> state another will persist its session to Redis and overwrite the
> session of the first request. I can't think of an easy way to get
> around this.
This will be a problem with everything you try to do.
To make your code more "distributable", you might have to change
things so that you make a local copy (clone?), mutate the clone, then
write it back to the session.
Unless you call session.setAttribute (or similar), Tomcat won't
distribute anything to the other nodes in a cluster. For example:
((Transaction)session.getAttribute("tx")).setStatus(TransactionStaus.COM
PLETE);
Will not cause the cluster to replicate, but this will:
Transaction tx = ((Transaction)session.getAttribute("tx"));
tx.setStatus(TransactionStaus.COMPLETE);
session.setAttribute("tx", tx);
I think you will find many session managers work this way, otherwise
they end up being hideously inefficient by replicating the entire
session across the cluster (or to the session-store) after every request
.
- -chris
> On Tue, May 12, 2020 at 8:39 PM Mark Eggers
> <its_toas...@yahoo.com.invalid> wrote:
>
>> Jonathan,
>>
>> On 5/12/2020 8:20 AM, 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. 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. 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.
>>>
>>>
>>>
>>>
>>> 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
>>
>> Could you use the RedissonSessionManager and an AWS - distributed
>> Redis server?
>>
>> You could put all of your Tomcat servers in an elastic group, and
>> let AWS manage that.
>>
>> The real problem with this approach is deployment. How do you
>> deploy across an elastic group of Tomcat servers when you may not
>> know the IP addresses of the servers or how many you have?
>>
>> I can think of some really kludgy ways to do this with S3 and
>> AWS events, but I've not worked out the details.
>>
>> Another way to approach this is to run Docker on AWS (along with
>> Redis), and then deploy a new version by deploying a new Docker
>> image in a rolling fashion.
>>
>> If your session interface changes a lot, that could create
>> issues.
>>
>> That's one of the advantages of using versioned deployment
>> (app.war##nnn) with a cluster. Old apps stay around until the
>> session expires, while new sessions get the new version.
>>
>> Maybe -- just thinking out loud -- you could use an elastic
>> group, AWS events, Redis (RedisSessionManager), and numbered WAR
>> files to simulate a Tomcat cluster.
>>
>> Another question: Is the database-backed session manager provided
>> with Tomcat slow? You could use that instead of the third party
>> RedissonSessionManager.
>>
>> You should be able to test everything but the deployment locally.
>> Just run a Docker implementation on your development machine, and
>> then test either RedissonSessionManager or the JDBC backed
>> session store. Docker will (can) be set up to mimic AWS elastic
>> group behavior (expansion / contraction of containers), so the
>> only question will be updates.
>>
>> Use something like JMeter to test sessions and hammer your
>> Docker cluster. By default, Docker routes every request to a new
>> container in a multi-container group. You'll know really quickly
>> if distributed sessions aren't working.
>>
>> I need to get back to this for $work, but I've been getting
>> yanked around a bit. Hopefully, I'll be able to start testing all
>> of these ideas in the next month or so.
>>
>> . . . just my two cents /mde/
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl67APoACgkQHPApP6U8
pFiOABAAyutfg+Yhy/Zn22TMhIvlLWhx8sHNOxXphJNbXugJ1gZmC8Ab+DCBr1N/
+QZVzEcVOj80QdL5iQ3yeKxp5gEmcplYD9A9sIOXzUdTc6tRHjasuu8Y0TALZ/13
bUYQEQKx5ZuFLPCIP91QtdgV2GcRJALbRC6MCi95LW0RO6LR1Ge1FoO+R+Y5EsUX
ci4NesPm6HPoJOROm7H5daeS12Wq4GqZOMZKpS14ouLb01bo1vr7fUrDmQxOTXKL
zs473g/pyiPUxlom2rzVHgU5bNiU0rQcTpMK6PO0YSxRs36WwA59vU5HNYJRyoPQ
MG3lbwHVmDS6MhvcuAJVWIOsEGjxHCfmAN5tysbfmsAv6DNl7dPM0R8WYpVppDiz
Q8lfglbP2VRY5KHJai5QbdPxg+iyAdvcriImJA16s3XpW4X/B8x5uswwlvpOdCOA
OnsXIB9BlIJ++HhqVx7JYLrM9ygUH1M5H9/9rlYNwhSRO2X/DXQH8cA8IX6siMuA
BqfKdMx0kdmxVZBodT6x7wzDBv1e4zgdl4UcWQF2X7tXzgC7+9kkAyQf8TFhG7zr
ZKZQiwZJ+iNr+GwRpfvdsn+jiG6K/zGtFWHUGYnyiifokFhHAfdfE9W0p0gDKKzM
gqEtLs/NN880n9FlpJ3PNajjY13CLgKHC1T+ORiHg/FGXa11TNc=
=RTC7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
