On 11/02/2026 01:54, 조재현 wrote:
Hello
I am seeking expert advice regarding a java.lang.IllegalStateException
occurring in our Tomcat clustering environment. We have analyzed the logs
and suspect a race condition during session replication, but we would like
to verify our proposed solutions with the community.
[Environment]
Tomcat Version: Apache Tomcat 9.0.73
That version is almost 3 years old and has multiple known security
vulnerabilities. Make sure you have mitigations in place for all of them
or consider upgrading.
JDK Version: Java 11
OS: [RHEL 9.x]
Cluster Nodes: 2 Nodes (Static Membership)
[Current Configuration (server.xml)]
<Cluster channelSendOptions="8"
channelStartOptions="3"
className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Manager
className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"
/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Sender
className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport
className="org.apache.catalina.tribes.transport.nio.PooledParallelSender" />
</Sender>
<Receiver
address="192.168.0.11"
autoBind="0"
className="org.apache.catalina.tribes.transport.nio.NioReceiver"
maxThreads="6"
port="3100"
selectorTimeout="5000"/>
<Interceptor
className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"
staticOnly="true"/>
<Interceptor
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"
/>
<Interceptor
className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
<Member
className="org.apache.catalina.tribes.membership.StaticMember"
port="3200"
host="192.168.0.12"
uniqueId="{0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,2}" />
</Interceptor>
<Interceptor
className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"
/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"
/>
<ClusterListener
className="org.apache.catalina.ha.session.ClusterSessionListener" />
</Cluster>
[The Issue] We are intermittently encountering the following error during
period of session sync: java.lang.IllegalStateException: setAttribute:
Session [SESSION_ID] has already been invalidated at
org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1330)
at
org.apache.catalina.ha.session.DeltaSession.setAttribute(DeltaSession.java:769)
[Questions & Proposed Actions]
Change channelSendOptions from 8 to 6: We currently use ASYNCHRONOUS mode
(8). We suspect that updates are arriving after a session invalidation
message due to lack of order guarantee. Would changing this to SYNCHRONOUS
(6) effectively resolve this without a significant performance penalty in a
2-node setup?
It will resolve the issue. There will be a performance impact. The
impact is likely to be low on a 2-node cluster with the nodes on the
same LAN. The only way to be sure is to try channelSendOptions="6" in
your test environment and measure the performance impact.
DeltaManager vs BackupManager: Given our 2-node setup, would switching to
BackupManager provide better consistency for session states, or is this
error purely a timing issue inherent to how DeltaRequest is processed?
It would not provide better consistency.
For a two-node cluster there is no functional difference between
DeltaManager and BackupManager but I'd BackupManager to be marginally
slower as there is more overhead. For more than 2 nodes, BackupManager
with sticky sessions is usually the better option.
notifyListenersOnReplication="false": We are considering disabling listener
notifications during replication. Could having this true (current setting)
be a bottleneck that contributes to the IllegalStateException?
Whether this is a bottleneck depends on the listeners and those are
provided by the application rather than Tomcat. Does your performance
monitoring indicate that they are a bottleneck?
Additionally, the correct setting for notifyListenersOnReplication
depends on the application expectations. If the application functions
correctly with it set to false there is no good reason to set it to true.
MessageDispatchInterceptor and PooledParallelSender: Does our current
combination of these two components have any known issues regarding session
attribute consistency in Tomcat 9.0.73?
No.
Any insights or recommendations on how to fundamentally suppress these
errors would be greatly appreciated.
channelSendOptions="6"
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
