XML processing performance issue in high concurrency scenarios

[iddo]

Using Rhino in a high concurrency situation with JavaScript that contains XML markup (I believe it's called E4X, or ECMAScript) seems to be affected by a hard-coded resource pool due to 26ee7ee

Sample E4X Script:

var myXml = <root><someelement></someelement></root>

In our test environment we got multiple thread with the following stack-trace:

"pool-62-thread-59" - Thread t@174
   java.lang.Thread.State: BLOCKED
at org.mozilla.javascript.xmlimpl.XmlProcessor.getDocumentBuilderFromPool(XmlProcessor.java:182)
- waiting to lock <71a4d2e4> (a org.mozilla.javascript.xmlimpl.XmlProcessor) owned by "pool-62-thread-19" t@134
at org.mozilla.javascript.xmlimpl.XmlProcessor.toXml(XmlProcessor.java:255)
at org.mozilla.javascript.xmlimpl.XmlNode.createElement(XmlNode.java:119)
at org.mozilla.javascript.xmlimpl.XMLLibImpl.parse(XMLLibImpl.java:444)
at org.mozilla.javascript.xmlimpl.XMLLibImpl.ecmaToXml(XMLLibImpl.java:477)
at org.mozilla.javascript.xmlimpl.XMLObjectImpl.ecmaToXml(XMLObjectImpl.java:838)
at org.mozilla.javascript.xmlimpl.XML.jsConstructor(XML.java:229)
at org.mozilla.javascript.xmlimpl.XMLObjectImpl.execIdCall(XMLObjectImpl.java:626)
at org.mozilla.javascript.IdFunctionObject.call(IdFunctionObject.java:129)
at org.mozilla.javascript.BaseFunction.construct(BaseFunction.java:374)
at org.mozilla.javascript.ScriptRuntime.newObject(ScriptRuntime.java:2440)
at <truncated due to irrelevancy>
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

Locked ownable synchronizers:
- locked <6a3fc851> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

Which caused the CPU to be under-utilized at 33%.

Since there's no way of knowing exactly how Rhino will be used I suggest letting the developer configure the size of this pool (or providing other methods to control this bottleneck).

[mbd-dbc-dk]

Hi there.

For some more discussion of this subject, check this pull request:
#9