[SM-860] EndpointReferenceBuilder.getReference() should cache its DocumentBuilderFactory instance

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.1
• Fix Version/s: 3.1.1, 3.2
• Component/s: servicemix-core
• Assignee: Guillaume Nodet
• Reporter: Alex Boisvert
• Created: 01/Mar/07 23:38
• Updated: 02/Mar/07 09:20
• Resolved: 02/Mar/07 09:20

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.