webMethods Knowlegebase : RosettaNet performance due XPathAPI instead of CachedXPathAPI (1802960)

Problem

Receiving an avalanche of RosettaNet messages from a partner, the RosettaNet inbound queues of Integration Servers grew up to 3000 messages queued.

The system in general stood well, but due to the inbound queue growth the response time of the messages is above 3 minutes, causing the partner to resend messages, making the queue even larger.

Can be detected interlocks between threads that caused contention:

"Integration Server Thread" Id=68826 in BLOCKED

at com.wm.app.b2b.server.PackageClassLoader.loadClassInPackage(PackageClassLoader.java:60)

- waiting on <0x38193bc8> (a com.wm.app.b2b.server.PackageClassLoader) owned by thread="Integration Server Thread" Id=68819

at com.wm.app.b2b.server.PackageClassLoader.loadClass(PackageClassLoader.java:40)

at com.wm.app.b2b.server.ServerClassLoader.loadClass(ServerClassLoader.java:1109)

at org.apache.xml.dtm.ObjectFactory.findProviderClass(ObjectFactory.java:504)

at org.apache.xml.dtm.ObjectFactory.lookUpFactoryClass(ObjectFactory.java:219)

at org.apache.xml.dtm.ObjectFactory.createObject(ObjectFactory.java:133)

at org.apache.xml.dtm.ObjectFactory.createObject(ObjectFactory.java:103)

at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:137)

at org.apache.xpath.XPathContext.<init>(XPathContext.java:102)

at org.apache.xpath.XPathAPI.eval(XPathAPI.java:225)

at org.apache.xpath.XPathAPI.selectNodeIterator(XPathAPI.java:128)

at org.apache.xpath.XPathAPI.selectSingleNode(XPathAPI.java:89)

at org.apache.xpath.XPathAPI.selectSingleNode(XPathAPI.java:69)

at com.wm.estd.common.utils.XMLBuilder.addNodeValue(XMLBuilder.java:133)

at com.wm.estd.common.utils.XMLBuilder.addNodeValue(XMLBuilder.java:153)

at com.wm.estd.common.utils.XMLBuilder.addNodeValue(XMLBuilder.java:153)

at com.wm.estd.common.utils.XMLBuilder.addNodeValue(XMLBuilder.java:153)

at com.wm.estd.common.utils.XMLBuilder.addNodeValue(XMLBuilder.java:164)

at com.wm.estd.rosettaNet.rnif20.mime.RNIF20ServiceHeader.createXMLContent(RNIF20ServiceHeader.java:625)

at com.wm.estd.rosettaNet.rnif20.mime.RNIF20ServiceHeader.getInputStream(RNIF20ServiceHeader.java:293)

at com.wm.estd.rosettaNet.mime.RNMimeMessage.createMimeData(RNMimeMessage.java:354)

at com.wm.estd.rosettaNet.mime.RNMimeMessage.getRawInputStream(RNMimeMessage.java:650)

at com.wm.estd.rosettaNet.rnif20.mime.RNIF20Message.getInputStream(RNIF20Message.java:268)

at com.wm.estd.rosettaNet.rnif20.RNIF20Transport.send(RNIF20Transport.java:301)

at com.wm.estd.rosettaNet.rnif20.RNIF20Transport.sendReceiptAcknowledgment(RNIF20Transport.java:534)

at com.wm.estd.rosettaNet.RequestHandler.sendReceiptAck(RequestHandler.java:1834)

at wm.estd.rosettaNet.transportHandlers.sendReceiptAck(transportHandlers.java:918)

According to the thread dumps, class com.wm.estd.rosettaNet.rnif20.mime.RNIF20ServiceHeader is evaluating several XPath expressions over every document received.

In every one of these points, RNIF20ServiceHeader is calling method com.wm.estd.common.utils.XMLBuilder.addNodeValue(), which in turn uses the static methods of XPathAPI to evaluate the expression over the received document and return its value, if any.

However, as the own documentation of this XPathAPI states https://xml.apache.org/xalan-j/apidocs/org/apache/xpath/XPathAPI.html

"The methods in this class are convenience methods into the low-level XPath API. These functions tend to be a little slow, since a number of objects must be created for each evaluation. A faster way is to precompile the XPaths using the low-level API, and then just use the XPaths over and over. NOTE: In particular, each call to this method will create a new XPathContext, a new DTMManager... and thus a new DTM. That's very safe, since it guarantees that you're always processing against a fully up-to-date view of your document. But it's also portentially very expensive, since you're rebuilding the DTM every time. You should consider using an instance of CachedXPathAPI rather than these static methods."