Hash: SHA256


On 6/27/20 05:52, Thomas Meyer wrote:
> Am 27. Juni 2020 11:29:03 MESZ schrieb Mark Thomas
> <ma...@apache.org>:
>> On 27/06/2020 10:19, Thomas Meyer wrote:
>>> Hi,
>>> A few questions regarding tomcat session replication:
>> load-balancing and session replication are two separate parts of
>> an overall clustering solution.
>>> 1) is the jvmRoute attribute on Engine object necessary for
>>> session
>> replication to work correctly?
>> No, but if you don't use it it places a number of restrictions on
>> the web application behaviour and on the configuration of
>> session replication.
>> The limitations are: - you need to use the DeltaManager (which
>> doesn't scale as well as the BackupManager);
> Yes, I'm using default DeltaManager as I will only have two pods
> running Tomcat.
>> - any requests made by the client that depend on the session MUST
>> be issued in series, not in parallel; and
> Not sure about this one, the app uses spring default security for
> login. So need to check this one.

This has more to do with how your web application itself works and
less about your security framework. For example, if you have a
web-1.0-style web application which is mostly user-driven GET and POST
requests, then you are probably fine with the occasional
user-initiated page RELOAD or STOP/RELOAD or STOP/RETRY event.

But if you have a web-2.0 style
websocket/AJAX/many-things-happening-at-once-style application, then
you are probably going to have problems without sticky sessions.

>> - the session Manager must be configured to update all the other
>> nodes in the cluster BEFORE the current request returns to the
>> client.
> How to do that? I did have a look at Manager/DeltaManager
> attributes but didn't see something that looks like above setting.
> Can you plea point me in the right direction?


This is done using channelSendOptions on the <Cluster> and
mapSendOptions on the ReplicationValve. The default value is to be
synchronous, which would be required, here. Synchronous means that the
data is replicated before the response is completed to the client. You
could also do asynchronous which would allow the request to complete
and queue the replication for "later" (but probably pretty shortly

>>> 2) does session replication only work correctly with sticky
>>> load
>> balancer routing?
>> No. It works quite happily without it.
> Good to know.

You might want to use sticky-sessions anyway.

>>> My setup is 1) load balancer without sticky session routing
>>> into kubernetes 2) two pods running tomcat with cloud member
>>> provider, which see and
>> find each other
>>> No jvmRoute attribute is set.
> Another question regarding jvmRoute: Even if my load balancer has
> no sticky sessions, should I add jvmRoute attribute? I think I
> could easily add the pod's name as jvmRoute.

If it's no particular trouble, I would:

1. Add jvmRoute
2. Enable sticky sessions

#2 just means that all requests for an session-holding client will be
directed to a single Tomcat node. If fail-over is necessary, the other
node will have the session-information that was last sent successfully
and should be relatively up-to-date. The session-id will be changed
upon fail-over and the user shouldn't really notice unless some
replication message was lost.

IMHO the only potential downside to non-sticky-sessions is that it's
possible for one of your nodes to "collect" more users than the others
and give you a lop-sided load-profile across your nodes. Unless that's
a particular concern for you (and, for most applications, it's not a
problem at all), I would enable sticky-sessions because it avoids a
lot of race-conditions and other performance-related issues with cluster

This isn't Tomcat-specific: it's just the nature of the beast.

>>> Above setup doesn't work and give strange errors for the
>>> distributed
>> webapp which relies on http sessions.
>>> Should above setup work? If not why and what do I need to fix?
>>> Any hints of what logging to enable to debug the problem if any
>>> at
>> all?
>> Please show us how you have configured the session manager and
>> clustering.
> My setup is just go with the defaults:
> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
> <Channel
> className="org.apache.catalina.tribes.group.GroupChannel">
> <Membership
> className="org.apache.catalina.tribes.membership.cloud.CloudMembership
> </Channel> </Cluster>

So pretty much default-everything (except maybe the CloudMembership).

> In the logs I can see the member appears/disappears messages, which
> is a good thing I guess.

It is!

Unless you can think of a particular reason NOT to enable
sticky-sessions, I'd go ahead and do it.

Remember that your reverse-proxy needs to understand how to handle
session stickiness, though. What are you using for
load-balancing/reverse-proxying in this environment?

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