[jira] Commented: (XMLBEANS-389) List accessors generated with -javasource=1.5 produce lists that scale poorly with the size of the list

[Philip Aston (JIRA)]

[ 
https://issues.apache.org/jira/browse/XMLBEANS-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663707#action_12663707
 ] 

Philip Aston commented on XMLBEANS-389:
---

Thanks Radu.

I may be missing something for the first issue. Why can't you use the 
AbstactList.modCount to implement a fail fast iterator?

The second issue is the killer of course. Could the iterator use an XmlCursor?

If nothing can be done, I suggest the FAQ is updated to warn that the List 
accessors should not be used for large arrays.

 List accessors generated with -javasource=1.5 produce lists that scale poorly 
 with the size of the list
 ---

 Key: XMLBEANS-389
 URL: https://issues.apache.org/jira/browse/XMLBEANS-389
 Project: XMLBeans
  Issue Type: Bug
  Components: Compiler
Affects Versions: Version 2, Version 2.1, Version 2.2, Version 2.2.1,  
 Version 2.3,  Version 2.3.1, Version 2.4 , Version 2.4.1 
Reporter: Philip Aston
 Attachments: testcase.tgz


 When a schema is compiled with -javasource=1.5, convenient list based 
 accessors are generated as well as the array accessors. E.g. 
 java.util.Listjava.lang.String getParamList()
 The implementation of the List is built upon java.lang.AbstractList. The 
 AbstractList iterator's hasNext() method calls size(). For an XMLBean 
 generated list, size() walks the store and so iteration scales quadratically.
 Here are some numbers showing the problem:
  XMLBeans backed list of 1 strings: 0.013766 ms
  XMLBeans backed list of 16 strings: 0.255458 ms
  XMLBeans backed list of 256 strings: 1.612057 ms
  XMLBeans backed list of 1024 strings: 25.458934 ms
  XMLBeans backed list of 2048 strings: 123.393447 ms
  XMLBeans backed list of 4096 strings: 505.594661 ms
  plain list of 1 strings: 0.002304 ms
  plain list of 16 strings: 0.007788 ms
  plain list of 256 strings: 0.013384 ms 
  plain list of 1024 strings: 0.052215 ms 
  plain list of 2048 strings: 0.103550 ms
  plain list of 4096 strings: 0.206648 ms
 I think the generated list should override iterator(), and return an Iterator 
 that calculates the list size once per iteration.

-- 
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-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org

[jira] Resolved: (XMLBEANS-388) XmlBeans can Deadlock Threads

[Cezar Andrei (JIRA)]

 [ 
https://issues.apache.org/jira/browse/XMLBEANS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cezar Andrei resolved XMLBEANS-388.
---

Resolution: Fixed

Also the array setter has been fixed to avoid deadlock, but in the same time, 
with the current synchonize architecture the setter can not be atomic, i.e. 
thread safe. In order to make it thread safe the entire XMLBeans syncronization 
code must be changed so use generated array setters (setArrayXXX(GenXObj[] ) ) 
with caution in multi-threaded environments.

 XmlBeans can Deadlock Threads
 -

 Key: XMLBEANS-388
 URL: https://issues.apache.org/jira/browse/XMLBEANS-388
 Project: XMLBeans
  Issue Type: Bug
  Components: XmlObject
Affects Versions:  Version 2.3,  Version 2.3.1, Version 2.4 
 Environment: Windows XP, Java 1.6
Reporter: Paul Hepworth
Assignee: Cezar Andrei
 Fix For: Version 2.4.1 

 Attachments: XmlBeansDeadlock.zip


 The situation can occur when calling a setter on an XmlObject which 
 synchronizes on Locale A, to set an XmlObject which synchronizes on Locale B 
 at the same time as calling a setter on an XmlObject which synchronizes on 
 Locale B to set an XmlObject which synchronizes on Locale A.
 The code within XmlObjectBase is fine, but the problem lies in the generated 
 code compiled from a schema. 
 The code that is generated contains a synchronized block on the monitor 
 (Locale A or B depending on the object), and then delegates to the 
 XmlObjectBase set method, which detects that you need to lock more than 1 
 Locale and so acquires a GlobalLock and then synchronizes on both monitors. 
 As another thread can be doing the reverse, you can end up with 2 threads, 
 one with Locale A locked, and one with Locale B locked. The first one then 
 acquires a GlobalLock, but can never obtain a lock on the other Locale.
 The attached code can produce the following:
 run:
  [java] Thread:main:RUNNABLE:true
  [java] java.lang.Thread.dumpThreads:-2
  [java] java.lang.Thread.getAllStackTraces:1487
  [java] Deadlock.main:21
  [java] Thread:Signal Dispatcher:RUNNABLE:true
  [java] Thread:Finalizer:WAITING:true
  [java] java.lang.Object.wait:-2
  [java] java.lang.ref.ReferenceQueue.remove:116
  [java] java.lang.ref.ReferenceQueue.remove:132
  [java] java.lang.ref.Finalizer$FinalizerThread.run:159
  [java] Thread:Reference Handler:WAITING:true
  [java] java.lang.Object.wait:-2
  [java] java.lang.Object.wait:485
  [java] java.lang.ref.Reference$ReferenceHandler.run:116
  [java] Thread:Attach Listener:RUNNABLE:true
  [java] Thread:Thread-0:WAITING:true
  [java] java.lang.Object.wait:-2
  [java] java.lang.Object.wait:485
  [java] org.apache.xmlbeans.impl.common.Mutex.acquire:33
  [java] org.apache.xmlbeans.impl.common.GlobalLock.acquire:27
  [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2049
  [java] noNamespace.impl.ObjectBTypeImpl.setObjectA:-1
  [java] MyThread.run:49
  [java] Thread:Thread-1:BLOCKED:true
  [java] org.apache.xmlbeans.impl.values.XmlObjectBase.set:2054
  [java] noNamespace.impl.ObjectATypeImpl.setObjectB:-1
  [java] MyThread.run:48
  [java] Java Result: 1
 As you can see, one thread is waiting on the GlobalLock, and the other has 
 the lock and is waiting for a lock on the other Locale 
 (XmlObjectBase.set:2054).

-- 
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-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org