Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Fwd: Moxy expensive classloader search when using elements with primitive types

Hi Rainer,

I am from MOXy development team. Thanks for discovering and reporting this bug to us. In order to get this issue fixed, bug must be filed in tracking tool. This can be done for you if you would like. Then you can attach the proposed patch (and tests) on the bug and it will be reviewed. Looks good at first sight (maybe could use map).

Another question is why are the results not memoized at all. But that will need separate bug.

Thanks again!

Best Regards

Date: 4 Dec 2014 15:33:56 CET
From: Rainer Jung <rainer.jung@xxxxxxxxxxx>
Subject: [eclipselink-dev] Moxy expensive classloader search when using elements with primitive types
Reply-To: Dev mailing list for Eclipse Persistence Services <eclipselink-dev@xxxxxxxxxxx>


this post was originally sent to the users list. There was no response and it is probably more appropriate for the dev list, so moving here.

I analyzed a performance problem of an application using Moxy. It turned out that threads were blocking on the classloader lock. This was due to JaxbClassLoader frequently calling loadClass() on its parent loader.

The root cause was a combination of two factors:

- no reuse of the JAXBContext
- use of xsd:int (and other primitive types) as *element* types

What happens, is that JAXBContext was looking for xsd:int and that went to the JaxbClassLoader calling loadClass("int"). That type of course isn't known so the parent classloader had to search through all of its jars to check. In our case the search was further delegated from a web app classloader to the system classloader to the bootstrap classloader. The latter two do not have caches for not found resources, so each time a new JAXBContext tried to resolve "int", the search was done. Each of the classloaders involved ends the search with creating an (expensive) ClassNotFoundException. Since this takes quite some time, the classloader locks got contented and threads piled up.

Note that if you use xsd:int as the type of an *attribute*, this does not happen. Moxy will map that straight to "Integer" instead of searching for "int". Only when using xsd:int for an *element* that problem shows up. The problem also does not happen when using the JAXB reference implementation.

I'm not saying, that the final result is broken. After the CNFE from the parent classloader, Moxy finally maps e.g. an xsd:int element to the Java primitive int. I'm only saying that doing a classloader search for a primitive type is expensive and should not be done.

I know that this wouldn't have hurt so much, if we had reused the JAXBContext. Nevertheless I think that it would be easy to improve JaxbClassLoader. As a workaround we can use a mapping file to map the primitive types to the corresponding object types during xjc, but that should not be necessary.

I'll attach a simple example project, hopefully attachments are allowed here. It contains a README and you can simply run it with "ant" using Moxy 2.5.x. It contains a slightly patched version of JaxbClassLoader to make the CNFE from the parent classloader observable by output to STDOUT. It first runs the example using attributes - no primitives loading - then using elements showing the primitives loading and CNFE.

I'll also attach a draft patch for improving the JaxbClassLoader.



eclipselink-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top