You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Zoran Avtarovski <zo...@sparecreative.com> on 2025/05/02 01:14:35 UTC
Re: Help with Cluster Setup on Tomcat 9
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
>>>
>>>
>
Re: Help with Cluster Setup on Tomcat 9
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org