| Summary: | DeltaSession discards pending deltas when changeSessionId() is called | ||
|---|---|---|---|
| Product: | Tomcat 9 | Reporter: | Max Lohrmann <post> |
| Component: | Cluster | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | post |
| Priority: | P2 | ||
| Version: | 9.0.34 | ||
| Target Milestone: | ----- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Sorry, typo.
It should have said
removeAttribute("A");
above (not C).
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 |
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.