|Summary:||DeltaSession discards pending deltas when changeSessionId() is called|
|Product:||Tomcat 9||Reporter:||Max Lohrmann <post>|
|Component:||Cluster||Assignee:||Tomcat Developers Mailing List <dev>|
Description Max Lohrmann 2020-06-25 09:36:15 UTC
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.
Comment 1 Max Lohrmann 2020-06-25 09:40:39 UTC
Sorry, typo. It should have said removeAttribute("A"); above (not C).
Comment 2 Mark Thomas 2020-06-29 20:26:44 UTC
Thanks for the report and for tracking down what was going on. I agree with your assessment. I have refactored the setId() methods. Fixed in: - master for 10.0.0-M7 onwards - 9.0.x for 9.0.37 onwards - 8.5.x for 8.5.57 onwards - 7.0.x for 7.0.105 onwards