Hi, The thread contention issue with DTDDVFactory was addressed [1] in 2007. The fix should be available in Xerces-J 2.9.1.
Note that the fact that you hit this issue is likely a sign that your application is excessively creating new parser instances. They are meant to be reused and you will get much better performance if you pool [2] them. Thanks. [1] http://svn.apache.org/viewvc?view=revision&revision=558581 [2] http://www.ibm.com/developerworks/library/x-perfap2.html/#reuse Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org "De Rossi Heim Carlo (KIRF 741)" <carlo.dero...@credit-suisse.com> wrote on 04/21/2010 05:22:56 AM: > Dear Madame or Sir > we are facing some serious performance issues, caused by the > implementation of the "org.apache.xerces.impl.dv.DTDDVFactory" and > the "org.apache.xerces.impl.dv.ObjectFactory" classes. > Our environment is based on Oracle WebLogic server 10.3.2, Sun JDK > 160_16 and Xerces 2.8.1 > Basically what we see is an high number of threads blocked by the > method getInstance of the "org.apache.xerces.impl.dv.DTDDVFactory" class.. > An example is given here: > ---------------------------------- THREAD DUMP START > --------------------------------------------- > "[ACTIVE] ExecuteThread: '99' for queue: 'weblogic.kernel.Default > (self-tuning)'" daemon prio=6 tid=0x08597400 nid=0x1444 waiting for > monitor entry [0x4143e000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.xerces.impl.dv.DTDDVFactory.getInstance(Unknown Source) > - waiting to lock <0x2a008228> (a java.lang.Class for > org.apache.xerces.impl.dv.DTDDVFactory) > at org.apache.xerces.parsers.XML11Configuration.<init>(Unknown Source) > at > org.apache.xerces.parsers.XIncludeAwareParserConfiguration.<init> > (Unknown Source) > at > org.apache.xerces.parsers.XMLGrammarCachingConfiguration.<init> > (Unknown Source) > at > org.apache.xerces.parsers.XMLGrammarCachingConfiguration.<init> > (Unknown Source) > at sun.reflect.GeneratedConstructorAccessor61.newInstance > (Unknown Source) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance > (DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance (Constructor.java:513) > at java.lang.Class.newInstance0(Class.java:355) > at java.lang.Class.newInstance(Class.java:308) > at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source) > at org.apache.xerces.parsers.ObjectFactory.createObject > (Unknown Source) > at org.apache.xerces.parsers.ObjectFactory.createObject > (Unknown Source) > at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source) > at org.apache.xerces.parsers.DOMParser.<init>(Unknown Source) > at org.apache.xerces.jaxp.DocumentBuilderImpl.<init>(Unknown Source) > at > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder > (Unknown Source) > ---------------------------------- THREAD DUMP END > --------------------------------------------- > Out of 100 threads available 72 are blocked there when the server is > under stress. > To understand the issue, is useful to remember that when a > Class.forName is done (like the ObjectFactory class invoked from the > DTDDVFactory does) it can takes (depending from the dimension of the > classpath) up to 2-4 seconds which is a huge time if this is invoked > continuosly. > Our suggestion would be to cache the class objects per ClassLoader > in the DTDDVFactory, at least for the default implementation (" > org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl") so that the search > of this class object in the context of a ClassLoader is done only > once. If there is any concern about backward compatibility this > could be done only if a specific System Property is set, which would > enable the feature and/or configure the size of this (LRU) cache. > A similar issue (but less heavy in performance) can be found in the > TransformerFactory. > > Would such a change be possible? > Gladly awaiting your answer and feedback. > Kind regards > Carlo de Rossi
