Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.3.1
-
Fix Version/s: 1.4
-
Component/s: None
-
Labels:None
-
JDK version and platform:Sun 1.6.0_14 64bit for Linux
Description
com.thoughtworks.xstream.io.xml.XmlFriendlyReplacer makes use of 2 WeakHashmaps to hold string.
Those maps are accessed multi-threaded, but are not synchronized.
This can lead to access on those maps occupying all CPU-resources, which can only get solved by restarting the VM.
This happens under rare heavily multi-threaded circumstances, nevertheless the impact is critical. Testsystem: 8 * Intel(R) Xeon(R) CPU E5345 @ 2.33GHz, 32GB RAM, FS on SAN
See attached stacktrace, with lots of threads bein in
at java.util.WeakHashMap.get(WeakHashMap.java:355)
at com.thoughtworks.xstream.io.xml.XmlFriendlyReplacer.escapeName(XmlFriendlyReplacer.java:67)
and occupying the CPU.
Also see Scott.Stark's comment in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=85301 for the same problem.
Suggested solution: Use synchronized WeakHashmap, see attached patch. (To check: performance impact? If yes, a non-synchronized, but thread-safe implementation would be suitable like ConcurrentSkipListMap).
Activity
Hi,
any idea when this fix will be available in a new release?
Is there any plan when the new version is released?
Thomas
Thomas Sartissohn
added a comment - Hi,
any idea when this fix will be available in a new release?
Is there any plan when the new version is released?
Thomas 
Hi Rico,
thanks for reporting, I've synchronized it now. If it causes a race condition it must be fixed. We will change in the complete naming mechanism something anyway, so it is fine with the synch. For a workaround with the reeleased version, simply derive from the XmlFriendlyReplacer and overwrite the complete implementation with yours. While you will have the member fields doubled, it does not really matter for the functionality
Cheers,
Jörg