Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
3.1
-
None
Description
Doing performance testing on Apache Ode, I saw the following call stack:
"pool-1-thread-31" prio=1 tid=0x975717a8 nid=0x46df waiting for monitor entry [0x9e2f4000..0x9e2f4e60]
at org.apache.xbean.classloader.UrlResourceFinder.findResource(UrlResourceFinder.java:91)
- waiting to lock <0xa65d5a18> (a java.lang.Object)
at org.apache.xbean.classloader.JarFileClassLoader$3.run(JarFileClassLoader.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.xbean.classloader.JarFileClassLoader.findResource(JarFileClassLoader.java:151)
at org.apache.xbean.classloader.MultiParentClassLoader.getResource(MultiParentClassLoader.java:246)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1159)
at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:72)
at java.security.AccessController.doPrivileged(Native Method)
at javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:65)
at javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:213)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:185)
at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:98)
at org.apache.servicemix.jbi.servicedesc.EndpointReferenceBuilder.getReference(EndpointReferenceBuilder.java:34)
at org.apache.servicemix.jbi.servicedesc.InternalEndpoint.getAsReference(InternalEndpoint.java:69)
at org.apache.ode.jbi.JbiEndpointReference.toXML(JbiEndpointReference.java:64)
at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.invoke(BpelRuntimeContextImpl.java:761)
at org.apache.ode.bpel.runtime.INVOKE.run(INVOKE.java:96)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:805)
at org.apache.ode.bpel.engine.BpelProcess.handleWorkEvent(BpelProcess.java:310)
at org.apache.ode.bpel.engine.BpelEngineImpl.onScheduledJob(BpelEngineImpl.java:311)
at org.apache.ode.bpel.engine.BpelServerImpl.onScheduledJob(BpelServerImpl.java:386)
at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.doExecute(QuartzSchedulerImpl.java:340)
at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.access$000(QuartzSchedulerImpl.java:59)
at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl$1$1.call(QuartzSchedulerImpl.java:223)
at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransaction(QuartzSchedulerImpl.java:264)
at org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl$2.call(QuartzSchedulerImpl.java:292)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
As you can see, it appears EndpointReferenceBuilder.getReference() creates a new instance of DocumentBuilderFactory every time it resolves an EPR... which is a significant performance overhead.