[XERCESJ-1647] RegularExpression blocks thread under heavy use

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 2.11.0
• Component/s: XML Schema API
• Assignee: Unassigned
• Reporter: Mateusz Nowakowski
• Created: 06/Oct/14 11:49
• Updated: 06/Oct/14 11:49

Description

When xml schema contains many references to the same simple type or it is very heavily used the threads blocks on:

"http-bio-8089-exec-18" daemon prio=10 tid=0x00002ba3943ce800 nid=0x3a56 waiting for monitor entry [0x00002ba393de4000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.apache.xerces.impl.xpath.regex.RegularExpression.matches(Unknown Source)
        - locked <0x000000073564bd00> (a org.apache.xerces.impl.xpath.regex.RegularExpression$Context)
        at org.apache.xerces.impl.xpath.regex.RegularExpression.matches(Unknown Source)
        at org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl.getActualValue(Unknown Source)
        at org.apache.xerces.impl.dv.xs.XSSimpleTypeDecl.validate(Unknown Source)
        at org.apache.xerces.impl.xs.XMLSchemaValidator.processOneAttribute(Unknown Source)
        at org.apache.xerces.impl.xs.XMLSchemaValidator.processAttributes(Unknown Source)
        at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
        at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
        at org.apache.xerces.jaxp.validation.DOMValidatorHelper.beginNode(Unknown Source)
        at org.apache.xerces.jaxp.validation.DOMValidatorHelper.validate(Unknown Source)
        at org.apache.xerces.jaxp.validation.DOMValidatorHelper.validate(Unknown Source)
        at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(Unknown Source)

The easiest way is to stop reusing Context object.
XERCESJ-1377 mention about it, but different approach was chosen:

A third possibility would be to dispense with the approach of re-using Context objects via an instance variable reference, and always allocate a Context on the stack. I also note that if this was done, and if the "prepare" method was not invoked lazily on the first match but was invoked up front as part of setting the pattern, there would be no need for any kind of synchronization within the "matches" methods. This could give the optimum for heavy concurrent use of a common pattern in highly-multithreaded environment, but of course has trade-offs in other regards.