Hi,
This week we discovered that one of our CXF based web services was behaving
strangely under moderate load. We traced this down to a race condition in
JAXB that sometimes caused unmarshalled objects returned by UnmarshallerImpl
to be only partially populated. In our case we had something like this:
public class Foo {
private String name;
private Map<String, String> properties;
// standard getters / setters for both
}
Thread-1 calls unmarshal(), which creats Foo-Ref-A
Thread-2 calls unmarshal(), which creats Foo-Ref-B
Thread-1 would call Foo-Ref-A.setName()
**Thread-1 would call Foo-Ref-B.setProperties() (with the data on the reader
from Thread-2)
Thread-2 would call Foo-Ref-B.setName()
Thread-2 would call Foo-Ref-B.setProperties()
Thread-1 would receive Foo-Ref-A
Thread-2 would receive Foo-Ref-B
So Foo-Ref-A would be processed by the web service, and bad things would
happen because its properties had never been unmarshalled.
We could confirm this problem in JAXB 2.2.1.1 (which ships with CXF 2.3.3).
Dropping in JAXB 2.2.3u1 appears to have fixed the issue. We also observed
that a brute-force synchronized lock in CXF (which we patched and rebuilt)
that globally synchronized JAXB unmarshalling fixed the issue too.
Obviously the latter is not something we would consider deploying, but it
did help us isolate the area of the fault.
We looked through the JAXB JIRA database, but didn't see any tickets that
looked relevant.
We're curious if anyone on the list knows if any threading/concurrency bugs
were fixed in the June 2010 - January 2011 time range.
thank you
-- James
--
James Cooper
Principal Consultant - Bitmechanic LLC
http://www.bitmechanic.com/