Zoran,

On 5/1/25 9:14 PM, Zoran Avtarovski wrote:
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.

Each node generates a session identifier for itself, and the (default) session id space is quite large (2^128 bits or 340282366920938463463374607431768211456). So for any given session identifier generated, you have a 1/340282366920938463463374607431768211456 chance of duplicating it.

The presence of the database does not change session-id generation.

Have you altered the default session identifier length in your configuration? If so, what sessionIdLength did you choose?

https://tomcat.apache.org/tomcat-9.0-doc/config/manager.html#Nested_Components

Does your database have a field that is the correct size for the session identifier? It needs to be at least 32 ASCII characters wide.

If you are using a jvmRoute on each server (which is how sticky-sessions work), your session identifier will have a "." and the jvmRoute of the generating node appended to it. However, that .jvmRoute suffix will not be written to the database.

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.

Can you please copy/paste any error messages tomcat gave to you, plus the relevant configurations (minus any secrets)?

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.

I'm not an expert at using persistent sessions, but I believe that either database-persisted sessions OR clustering will get you what I suspect is your primary objective: to have sessions survive the sudden disappearance of one of the Tomcat nodes for whatever reason (failure, maintenance, etc.).

The duplicate id thing is puzzling to me. Are you using a default session configuration?

-chris

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





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to