Re: [xmlblaster] More parsing issues

[Marcel Ruff]

Hi John,

John Horner wrote:

This message is (roughly speaking) a follow up to the previous message entitled 
"Subscription Invocation Exception".

In addition to the problem described in that message I have also seen another 
(possibly) similar problem.  I have a unit test which creates 100 threads which 
all try to make a subscription using the same xpath.  In some cases (but not 
always) one or more of the subscriptions fails with the following error:

java.lang.NoSuchMethodException: javax.xml.xpath.XPath.evaluate()
    at java.lang.Class.getMethod(Class.java:1581)
    at org.xmlBlaster.util.XmlNotPortable.getNodeSetFromXPath(XmlNotPortable
.java:137)
    at org.xmlBlaster.engine.xml2java.XmlKeyDom.parseKeyOid(XmlKeyDom.java:1
25)
    at org.xmlBlaster.engine.RequestBroker.queryMatchingKeys(RequestBroker.j

The intermittent nature of this problem (as well as the previously described 
one) suggests to me that we are looking at a synchronization issue.

I have two synchronization concerns when looking at the code.  The following 
snip is from org.xmlBlaster.util.XmlNotPortable

public static Enumeration getNodeSetFromXPath(String expression,                
                                                       org.w3c.dom.Document 
document) throws XmlBlasterException {
   try {
      if (getJvmXmlVersionToUse() >= 15) {
            if (method_newXPath == null) {
               synchronized(XmlNotPortable.class) {
                  if (method_newXPath == null) {

                      ... create xpath factory and objects ...

                  }
               }
            }

Object xpath = method_newXPath.invoke(instance_XPathFactory, new Object[0]); Object[] params = new Object[] { expression, document, field_NODESET };

            java.lang.reflect.Method method_evaluate =
               clazz_XPath.getMethod("evaluate", paramCls_StringDocument);
            final org.w3c.dom.NodeList nodes = (org.w3c.dom.NodeList)
               method_evaluate.invoke(xpath, params);

The issues are:
1. The null check (method_newXPath == null) is outside the synchronization 
block.  Thread A and thread B could both pass through the null check at the 
same time.  Thread A will create the xpath objects while B waits.  Then thread 
B will go through and recreate xpath objects while A is using them.

if (method_newXPath == null) {
 synchronized(XmlNotPortable.class) {
   if (method_newXPath == null) {

method_newXPath creation is protected by the sync
and inside this with another null check (double-checked locking idiom).
This could theoretically fail as we have not set
method_newXPath to be "volatile".

2. XPathFactory is, in general, not thread-safe (see 
http://java.sun.com/javase/6/docs/api/javax/xml/xpath/XPathFactory.html), and a 
method on that object is invoked outside the synchro block.

Yes this is a bug.
We have fixed it and commited it to svn.
Thanks for reporting,

Marcel

I made a local change to wrap the synchro block around the null check and the 
invocations following the original synchro.  Once I did that I was unable to 
reproduce the problem I described above.

I'd appreciate it if the xmlBlaster gurus could comment on the proposed change. 
 I'm happy to push the change up, but I'd like to get a little feedback first 
if I can.

Thanks,
John Horner

Open Roads Consulting
(757) 546-3401
www.openroadsconsulting.com

--
Marcel Ruff
http://www.xmlBlaster.org
http://watchee.net
Phone: +49 7551 309371