[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    [jira] Commented: (XMLBEANS-345) Setting the same variable to
From:       "Radu Preotiuc-Pietro (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date:       2008-03-28 0:18:24
Message-ID: 1928781350.1206663504576.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/XMLBEANS-345?page=com.atlassian.jira.plugi \
n.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582856#action_12582856 ] 

Radu Preotiuc-Pietro commented on XMLBEANS-345:
-----------------------------------------------

I have tried your test code with my own Schema and a similar-sized document. I have \
also inspected the code visually; these are my findings:

First of all, the code looks correct: everything is synchronized and GlobalLock is \
called in the expected pattern, nothing I could detect that might go wrong.

Looking at the test code, what it does basically is continuous sets of the same \
XmlObject to a parent XmlObject on 20 threads and each thread prints out a "." every \
10,000 sets. After 10 seconds, a full stacktrace of all the threads is printed to the \
console.

But the thing is that doing 10,000 sets of a complex document takes time. Moreover, \
since the threads are blocked on the GlobalLock for most of the time and work in \
paralel, initially only one or two threads hit the mark before 10 seconds have \
elapsed and so you don't see a lot of dots. Then, when the stacktraces are printed, \
all of the threads are indeed blocked waiting for the GlobalLock *except* for two (on \
my dual-core proc, I suspect on single-core procs only one is unblocked) which are \
performing work. Increasing the time yields more "."s but the same stacktraces at the \
end.

So I don't think we are dealing with a deadlock at all, merely with the fact that, \
not able to run all the threads at the same time, the JVM suspends all threads except \
for one or two on the GlobalLock call. I have tried this with Sun's JVM and with \
JRockit and the results are the same, except for the fact that JRockit's \
synchronization overhead is smaller, so you get more sets done than with HotSpot in \
the same amount of time.

I am going to resolve this issue. While the test case proves that there is \
contention, it doesn't prove that there is a deadlock.



> Setting the same variable to multiple properties in multi-threaded environment \
>                 causes deadlocking
> -------------------------------------------------------------------------------------------------
>  
> Key: XMLBEANS-345
> URL: https://issues.apache.org/jira/browse/XMLBEANS-345
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Affects Versions:  Version 2.3,  Version 2.3.1
> Environment: Microsoft Windows XP [Version 5.1.2600], single-core
> java version "1.5.0_10"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)
> Reporter: Ian Sollars
> Priority: Critical
> 
> When setting a property on many XmlBeans objects with a single large variable, all \
> threads concerned will block with this stacktrace:  java.lang.Object.wait:-2
> 	java.lang.Object.wait:-1
> 	org.apache.xmlbeans.impl.common.Mutex.acquire:33
> 	org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> 	org.apache.xmlbeans.impl.values.XmlObjectBase.set:1944
> The test below sets a Type on it's Document and illustrates the problem. I can't \
> publish the actual schema and namespace, but to give an idea of size, the XML \
> object is about 90 KB of complex data (multiple namespaces, hundreds of elements, \
> embedded CDATA). A workaround has been included in commented-out form.
> import java.io.File;
> import java.io.IOException;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.Map;
> import org.apache.xmlbeans.XmlException;
> import tests.LargeDataStructureType;
> import tests.LargeDataStructureDocument;
> public class BlockingExample {
> public static void main(String[] args) throws InterruptedException, XmlException, \
> IOException { LargeDataStructureDocument doc = \
> LargeDataStructureDocument.Factory.parse(new File("exampleFile.xml")); \
> LargeDataStructureType type = doc.getLargeDataStructureType(); List<Setter> setters \
> = new ArrayList<Setter>(); for(int i = 0; i != 20; i++) setters.add(new \
> Setter(key)); for(Setter s : setters) s.start();
> Thread.sleep(10000);
> Map<Thread,StackTraceElement[]> map=Thread.getAllStackTraces();
> for(Thread t:map.keySet()){
> StackTraceElement[] ss=map.get(t);
> System.out.println("Thread:"+t.getName()+":"+t.getState()+":"+t.isAlive());
> if(ss!=null) {
> for(StackTraceElement s:ss){
> System.out.println("\t"+s.getClassName()+"."+s.getMethodName()+":"+s.getLineNumber());
>  }
> }
> }
> System.exit(0);
> }
> }
> class Setter extends Thread {
> private static int counter = 0;
> private LargeDataStructureType type;
> Setter(LargeDataStructureType type) {
> /*
> * This reproduces the behaviour
> */
> this.type = type; 
> 
> /*
> * This also reproduces the behaviour
> */
> //      this.type = (LargeDataStructureType)type.copy();
> /*
> * This is a reliable workaround.
> */
> //      this.type = LargeDataStructureType.Factory.newInstance();
> //      type.set(type);
> }
> public void run() {
> while(true) {
> LargeDataStructureDocument obj = LargeDataStructureDocument.Factory.newInstance();
> obj.setLargeDataStructure(key);
> if(counter++ % 10000 == 0) {
> System.out.print(".");
> }
> }
> }
> }
> This produces the following output:
> .Thread:Thread-7:WAITING:true
> 	java.lang.Object.wait:-2
> 	java.lang.Object.wait:-1
> 	org.apache.xmlbeans.impl.common.Mutex.acquire:33
> 	org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> 	org.apache.xmlbeans.impl.values.XmlObjectBase.set:1944
> 	tests.LargeDataStructureTypeImpl.setLargeDataStructure:xx
> 	be.inglease.wel.Setter.run:64
> Thread:Thread-13:WAITING:true
> 	java.lang.Object.wait:-2
> 	java.lang.Object.wait:-1
> 	org.apache.xmlbeans.impl.common.Mutex.acquire:33
> 	org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
> 	org.apache.xmlbeans.impl.values.XmlObjectBase.set:1944
> 	tests.LargeDataStructureTypeImpl.setLargeDataStructure:xx
> 	be.inglease.wel.Setter.run:64
> (...etc. for 20 threads)
> The expected output would just be lots of dots followed by various stacktraces.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]