Fix concurrency issues in XStreamMarshaller #25017
Assignees
Labels
in: data
Issues in data modules (jdbc, orm, oxm, tx)
status: backported
An issue that has been backported to maintenance branches
type: enhancement
A general enhancement
Milestone
Comments
spring-projects-issues
added
the
status: waiting-for-triage
sbrannen
added
type: enhancement
|
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 |
spring-projects-issues
added
status: backported
sbrannen
changed the title
sbrannen
added a commit
that referenced
this issue
May 7, 2020
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
sbrannen
added a commit
that referenced
this issue
May 7, 2020
FelixFly
pushed a commit
to FelixFly/spring-framework
that referenced
this issue
Aug 16, 2020
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
FelixFly
pushed a commit
to FelixFly/spring-framework
that referenced
this issue
Aug 16, 2020
zx20110729
pushed a commit
to zx20110729/spring-framework
that referenced
this issue
Feb 18, 2022
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
zx20110729
pushed a commit
to zx20110729/spring-framework
that referenced
this issue
Feb 18, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Just stumbled on a nasty concurrency issue in
org.springframework.oxm.xstream.XStreamMarshaller.When you forget to call
afterPropertiesSeton 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
ConverterLookupused 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: