Issue Details (XML | Word | Printable)

Key: XMLBEANS-46
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Kevin Krouse
Reporter: Dejan Predovic
Votes: 2
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
XMLBeans

Regex validation fails in multi-threaded, multi-processor environment

Created: 03/Aug/04 02:43 PM   Updated: 02/Mar/06 05:48 AM
Return to search
Component/s: Validator
Affects Version/s: Version 1.0.3, Version 2
Fix Version/s: unspecified

Time Tracking:
Not Specified

Environment: sun 1.4.2_04, jrockit 1.4.2_04, multi-cpu machine

Resolution Date: 02/Mar/06 05:47 AM


 Description  « Hide
When using validate() method in multi-threaded, multi-cpu environment, there is a pretty high probability of getting false XMLErrors for elements defined with regex patterns in schema.

import EDU.oswego.cs.dl.util.concurrent.CountDown;
import junit.framework.TestCase;
import org.apache.xmlbeans.XmlException;
import org.apache.xmlbeans.XmlOptions;
import org.apache.xmlbeans.XmlError;

import java.util.Collection;
import java.util.ArrayList;
import java.util.Iterator;

public class XmlBeansTest extends TestCase {

    public void testMultipleThreads() throws XmlException, InterruptedException {
        final int totalThreadCount = 100;
        CountDown latch = new CountDown(totalThreadCount);
        CountDown start = new CountDown(1);

        long now = System.currentTimeMillis();

        System.out.println("Starting");
        for (int i = 0; i < totalThreadCount; i++) {
            new ParseAndValidate(latch, start).start();
        }

        start.release();
        latch.acquire();

        System.out.println("Finished: " + (System.currentTimeMillis() - now));
    }

    public static void main(String[] args) throws Exception, InterruptedException {
        XmlBeansTest xmlBeansTest = new XmlBeansTest();
        xmlBeansTest.setUp();
        xmlBeansTest.testMultipleThreads();
    }

    private class ParseAndValidate extends Thread {

        private CountDown countDownLatch;
        private CountDown start;
        private final String xmldata = ...;

        public ParseAndValidate(CountDown countDownLatch, CountDown start) {
            this.countDownLatch = countDownLatch;
            this.start = start;
        }

        public void run() {
            try {
                start.acquire();
                boolean valid = parseAndValidate();
                if (!valid) {
                    System.out.println("Not Valid!!!");
                }
                countDownLatch.release();
            } catch (XmlException e) {
                e.printStackTrace();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

        private boolean parseAndValidate() throws XmlException {
            MyXml xml = MyXml.Factory.parse(xmldata);
            return validate(xml);
        }

        private boolean validate(MyXml rdd) {
Collection errors = new ArrayList();
XmlOptions validateOptions = new XmlOptions();
validateOptions.setErrorListener(errors);
boolean valid = rdd.validate(validateOptions);
if (!valid) {
for (Iterator iterator = errors.iterator(); iterator.hasNext();) {
XmlError xmlError = (XmlError) iterator.next();
System.out.println("XML Error - " + xmlError.getMessage() + " at\n" + xmlError.getCursorLocation().xmlText());
}
}
return valid;
        }
    }
}

The code above, when executed on a MP machine, has a pretty high probability (5%+ I'd say) of generating at least one failed validation. On machines with hyperthreading, the probability is even higher (10%+).
I only saw it fail on regex patterns. On SP machines it never fails. The only workaround I've found is encasing a validate method in a globally synchronised block (not really a workaround, I know).
The code also runs very slowly on MP machines with sun jdk, but that's unrelated to the problem I guess.


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Kevin Krouse added a comment - 03/Mar/05 11:54 AM
I've tried testing and I can't repro on a 8-way box running RedHat AS, but I suspect this may be due to r110680.

http://svn.apache.org/viewcvs.cgi?rev=110680&view=rev

Radu Preotiuc-Pietro added a comment - 09/Jul/05 07:23 AM
Since Kevin was not able to reproduce it and one of the goals of the V2 store was to have better synchronization, I would say that we should close this now. Dejan, if you still run into problems, I would say upgrading to V2 is the easiest path to take.

Dejan Predovic added a comment - 19/Dec/05 09:22 PM
I tested the same code today with 2.1.0 release on a quad Xeon/Debian/jdk 1.5.0_04_b05 (clean install, basically no other app running) and reqexp validations still fail sometimes. Not as many failures I had with 1.0.3, but still some - if I start the test 10x or so, I'm bound to get at least one failure. Single CPU never fails, dual Xeon/Win 2003/jdk 1.4.0_04 also fails sometimes.

Padraic Renaghan added a comment - 10/Feb/06 11:51 AM
Seeing something which sounds a lot like this on

SunOS myhostname 5.8 Generic_117350-12 sun4u sparc SUNW,Ultra-80
2 cpu
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-b05)
Java HotSpot(TM) Client VM (build 1.4.2_09-b05, mixed mode)

XmlBeans sporadically reports validation errors on text fields which when reviewed do not seem to be true errors.

For example just now got a validation error on "ERSYS1" value in a field with type of

  <xs:simpleType name="UserIdType">
    <xs:restriction base="xs:string">
      <xs:pattern value="[A-Z0-9]+"/>
      <xs:minLength value="5"/>
      <xs:maxLength value="8"/>
    </xs:restriction>
  </xs:simpleType>


Padraic Renaghan added a comment - 10/Feb/06 12:05 PM
sorry forgot to mention xmlbeans v 2.0.0 in my last comment

Radu Preotiuc-Pietro added a comment - 02/Mar/06 05:47 AM
I think I found out what was wrong with this.

Radu Preotiuc-Pietro added a comment - 02/Mar/06 05:48 AM
SVN change 382149.