Skip to content
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

@JacksonXmlRootElement malfunction when using it with XmlMapper in multi-thread environment #171

Closed
wanglingsong opened this issue Nov 20, 2015 · 4 comments
Milestone

Comments

@wanglingsong
Copy link

This is the sample to reproduce the bug. The "localName" override is failed in some of thread, printing original class name "TestModel" instead of "model". XmlMapper seems not thread safe.

import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.dataformat.xml.XmlMapper;
import com.fasterxml.jackson.dataformat.xml.annotation.JacksonXmlRootElement;

@JacksonXmlRootElement(localName = "model")
public class TestModel {


    public static void main(String[] s) throws Exception {

        final ObjectMapper xmlMapper = new XmlMapper();

        for (int i=0;i < 100;i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        System.out.println(xmlMapper.writeValueAsString(new TestModel()));
                    } catch (JsonProcessingException e) {
                        e.printStackTrace();
                    }
                }
            }).start();
        }

        Thread.sleep(10000L);

    }

}

Output:

<model/>
<model/>
<model/>
<model/>
<model/>
<model/>
<model/>
<TestModel/>
<model/>
<model/>
<model/>
<model/>
@cowtowncoder
Copy link
Member

Whoa. That is interesting... I assume this is with 2.6.3?

@wanglingsong
Copy link
Author

Yes

@cowtowncoder
Copy link
Member

I can reproduce this. No obvious cause, looking at code, but should not be too difficult to find.

@cowtowncoder
Copy link
Member

Ok. Yes, interesting. Bug comes from a combination of factors, and was introduced in 2.5, most likely.
Basically, a subset of AnnotatedClass instances (ones for which only class annotations are checked, like for use with root name discovery) may be cached (start with 2.5.0). Further, class annotation lookup is actually done lazily. And finally, since (earlier) assumption was that access to AnnotatedClass is not multi-threaded, this becomes problematic.

I'll try to get this fixed; 2.6 probably needs bit different fix than what may be done for 2.7, but both should be addressable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants