Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.7.12
-
None
-
Unknown
Description
We have an application with quite a few jars in the classpath. Since the class org.apache.cxf.xmlbeans.XmlBeansWrapperHelper doesn't exist, the loading of this class causes the class loader to search the entire classpath which means scanning each and every jar. This is causing performance issues for us where under heavy load several threads get blocked while one thread is searching all the jars in the classpath.
Here is the thread which is searching the classpath:
java.lang.Thread.State: RUNNABLE
at java.util.zip.ZipFile.getEntry(Native Method)
at java.util.zip.ZipFile.getEntry(ZipFile.java:306)
- locked <0x000000074069ee30> (a java.util.jar.JarFile)
at java.util.jar.JarFile.getEntry(JarFile.java:226)
at weblogic.utils.classloaders.ZipClassFinder.getSource(ZipClassFinder.java:39)
at weblogic.utils.classloaders.JarClassFinder.getSource(JarClassFinder.java:50)
at weblogic.utils.classloaders.AbstractClassFinder.getClassSource(AbstractClassFinder.java:31)
at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:59)
at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:59)
at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:59)
at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:59)
at weblogic.application.utils.CompositeWebAppFinder.getClassSource(CompositeWebAppFinder.java:88)
at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:59)
at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:59)
at weblogic.utils.classloaders.CodeGenClassFinder.getClassSource(CodeGenClassFinder.java:28)
at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:329) - locked <0x0000000740a46f30> (a weblogic.utils.classloaders.ChangeAwareClassLoader)
at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:302)
at weblogic.utils.classloaders.ChangeAwareClassLoader.findClass(ChangeAwareClassLoader.java:64)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425) - locked <0x0000000740a46f30> (a weblogic.utils.classloaders.ChangeAwareClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:180)
at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:43)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:91)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
and here are two of the many blocked threads:
"[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x000000001a357800 nid=0x189a waiting for monitor entry [0x00002b7d60ef1000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.ClassLoader.loadClass(ClassLoader.java:405)
- waiting to lock <0x0000000740a46f30> (a weblogic.utils.classloaders.ChangeAwareClassLoader)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:180)
at weblogic.utils.classloaders.ChangeAwareClassLoader.loadClass(ChangeAwareClassLoader.java:43)
at com.sun.org.apache.xerces.internal.utils.ObjectFactory.findProviderClass(ObjectFactory.java:322)
at com.sun.org.apache.xerces.internal.utils.ObjectFactory.newInstance(ObjectFactory.java:270)
at com.sun.org.apache.xerces.internal.utils.ObjectFactory.newInstance(ObjectFactory.java:256)
at com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance(DTDDVFactory.java:63)
at com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance(DTDDVFactory.java:49)
at com.sun.org.apache.xerces.internal.impl.xs.opti.SchemaParsingConfig.<init>(SchemaParsingConfig.java:358)
at com.sun.org.apache.xerces.internal.impl.xs.opti.SchemaParsingConfig.<init>(SchemaParsingConfig.java:255)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.<init>(XSDHandler.java:475)
at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.<init>(XSDHandler.java:482)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.<init>(XMLSchemaLoader.java:362)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.<init>(XMLSchemaLoader.java:311)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.<init>(XMLSchemaValidator.java:1144)
at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaValidatorComponentManager.<init>(XMLSchemaValidatorComponentManager.java:214)
at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorHandlerImpl.<init>(ValidatorHandlerImpl.java:194)
at com.sun.org.apache.xerces.internal.jaxp.validation.AbstractXMLSchema.newValidatorHandler(AbstractXMLSchema.java:70)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:172)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:610)
at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:240)
at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:221)
at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:140)
"[ACTIVE] ExecuteThread: '21' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x000000001b424800 nid=0x18b7 waiting for monitor entry [0x00002b7d62597000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at org.apache.cxf.jaxws.interceptors.WrapperClassOutInterceptor.handleMessage(WrapperClassOutInterceptor.java:91)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
We are using CXF 2.7.12 but I believe this issue also exists in 2.7.13 and 2.7.14. I am also sorry that I can't provide an test to reproduce this as this is a load related issue.
Is it possible to update the code in WrapperClassOutInterceptor which is trying to load the non-existent class org.apache.cxf.xmlbeans.XmlBeansWrapperHelper?