I had a problem in an application using Spring Security and using clustering with DeltaManager where some attributes would be replicated while others would not during login.

Basically what I was seeing was:

- First request to tomcat A
- Session attributes on both tomcats afterwards:
A=1
B=2

- Second request to tomcat A
- Session attributes on tomcat A afterwards:
C=1
B=3
- Session attributes on tomcat B afterwards:
A=1
B=3

Thus resulting in an invalid application state.

Using a debugger the calls on the session for the second request were:

removeAttribute("C");
setAttribute("C",1);
changeSessionId();
setAttribute("B",3);

So it looks like all attribute changes made before changeSessionId got lost in replication.

After looking at the tomcat code I think this is an issue with tomcat, because the changeSessionId calls DeltaSession#setId which in turn calls DeltaSession#resetDeltaRequest() which then discards the buffered AttributeInfo, so by the time the ReplicationValve is executed, only the last setAttribute call is seen as a delta.