Re: [Inquiry] java.lang.IllegalStateException: setAttribute: Session already invalidated during Cluster Replication (Tomcat 9.0.73)

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