https://bz.apache.org/bugzilla/show_bug.cgi?id=64560
Bug ID: 64560
Summary: DeltaSession discards pending deltas when
changeSessionId() is called
Product: Tomcat 9
Version: 9.0.34
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Cluster
Assignee: dev@tomcat.apache.org
Reporter: p...@wickenrode.com
Target Milestone: -----
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
