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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org