-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix concurrency issues in XStreamMarshaller #25017
Comments
Thanks for raising the issue. We'd not want to start throwing an exception here, since that might break existing use cases that did not encounter concurrency issues. Rather, we'll introduce some locking for that field to avoid concurrency issues. |
This has been addressed in ce11fdf for the upcoming Spring Framework 5.2.7 release. Feel free to try it out in the next 5.2.7 snapshot and provide feedback. |
Reopening to make use of the |
Prior to this commit, if an instance of XStreamMarshaller was used concurrently from multiple threads without having first invoked the afterPropertiesSet() method, the private `xstream` field could be initialized multiple times resulting in a ConcurrentModificationException in XStream's internal DefaultConverterLookup. This commit fixes these concurrency issues by making the `xstream` field volatile and by implementing a double-checked locking algorithm in getXStream() to avoid concurrent instance creation. Closes gh-25017
Prior to this commit, if an instance of XStreamMarshaller was used concurrently from multiple threads without having first invoked the afterPropertiesSet() method, the private `xstream` field could be initialized multiple times resulting in a ConcurrentModificationException in XStream's internal DefaultConverterLookup. This commit fixes these concurrency issues by making the `xstream` field volatile and by implementing a double-checked locking algorithm in getXStream() to avoid concurrent instance creation. Closes spring-projectsgh-25017
Prior to this commit, if an instance of XStreamMarshaller was used concurrently from multiple threads without having first invoked the afterPropertiesSet() method, the private `xstream` field could be initialized multiple times resulting in a ConcurrentModificationException in XStream's internal DefaultConverterLookup. This commit fixes these concurrency issues by making the `xstream` field volatile and by implementing a double-checked locking algorithm in getXStream() to avoid concurrent instance creation. Closes spring-projectsgh-25017
Just stumbled on a nasty concurrency issue in
org.springframework.oxm.xstream.XStreamMarshaller
.When you forget to call
afterPropertiesSet
on this marshaller, the internally held XStream instance will not be initialized. Instead, it will be done in the methodgetXStream
, which is called from both marshal and unmarshal methods.This initialization is not guarded, and might happen concurrently. In this case, the
ConverterLookup
used to store converters will be shared by the XStream instances that are constructed, which can lead to strange application behaviour, since the underlying data structure is not thread safe.In our application, it lead to very strange errors during XML marshalling/unmarshalling, since a couple of converters were missing. This happened whenever our app process scaled up during high load.
I see 2 possible solutions:
Spring version affected is 5.2.5.RELEASE
The text was updated successfully, but these errors were encountered: