Thanks Chris,
I appreciate you input. In answer to your questions the primary issue we
are experiencing is that on occasions (once a month or two) we will get
two users on different nodes with the same session id. We suspect this
could be because there is a short window from when tomcat creates a new
session and when it is persisted to db which under heavy loads
duplicates can be created.
We are keen to use DB based sessions and tomcat clustering but when we
tried to start clustering tomcat threw a warning that clustering was not
started because it doesn't support PersistentManager.
Finally, the ideal situation is for us to avoid the duplicate session
ids. We have been discussing internally if we should drop persistent
sessions as the clustering avoids the need for them and try just
clustering as it may be a more reliable solution, but we are far from
experts in this area.
Z.
On 26/4/2025 5:29 am, Christopher Schultz wrote:
Zoran,
On 4/24/25 4:21 AM, Zoran Avtarovski wrote:
Thanks Chuck,
I missed that and will implement. Bigger problem is that
PersistentManager is incompatible with Clusters so we have to migrate
back to memory based sessions and use clusters to share sessions.
I would have thought that cluster would be easier to support with DB
based sessions. Does anyone know why they aren't supported?
What is the primary problem you are trying to solve? Are you trying to
solve the problem of mixed-up sessions (which sounds very surprising
to me that it happens, with the session identifier space being so big)
or do you want to move to clustering anyway? It seems like you've
decided that clustering is the solution to your problem and so now you
have a new problem: how to implement clustering.
You can use both persistent sessions AND clustering if you want. It's
how your sessions can survive a situation where all members of the
cluster are stopped.
But it would be helpful if you would tell us your ideal situation and
we can help you get there.
-chris
On 24/4/2025 11:20 am, Chuck Caldarale wrote:
On 2025 Apr 23, at 20:02, Zoran Avtarovski<zo...@sparecreative.com>
wrote:
We have a cluster of tomcat servers on AWS EC2 which operate behind
an AWS load balancer with sticky sessions.
We have our session storage on a DB using a JDBC store which for
the most part is working well, but we occasionally see duplicate
session ids which create issues where a new session with a
duplicate session id hijacks an existing session.
As you can imagine we would like to prevent this from occurring and
have been looking into the issue. It looks like using the cluster
tag might be the solution but I wanted to tap into the collective
wisdom of the group on the best way forward. We can't just add the
|<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/> |
tag as it uses ip multicast which doesn't work in EC2 as there is
no physical broadcast layer. The alternative appears to be to use
the StaticMemebrshipService and I wanted to confirm if my config
ideas are correct? I have the following setup:
<Membership
className="org.apache.catalina.tribes.membership.StaticMembershipService">
<Member
className="org.apache.catalina.tribes.membership.StaticMember"
host="10.0.1.11" port="4004"
uniqueId="{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15}"/>
<Member
className="org.apache.catalina.tribes.membership.StaticMember"
host="10.0.1.12" port="4004"
uniqueId="{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,1}"/>
</Membership>
Does this look right to others and do I need a separate Member tag
for each member of the cluster?
I'd appreciate any assistance on this and other suggestions you
guys may have.
Have you specified a unique jvmRoute attribute in the <Engine>
element of each Tomcat server?
https://tomcat.apache.org/tomcat-9.0-doc/config/
engine.html#Common_Attributes
- Chuck
