You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Michael Glavassevich <mr...@ca.ibm.com> on 2010/04/21 12:40:40 UTC

Re: DTDDVFactory

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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org

"De Rossi Heim Carlo (KIRF 741)" <ca...@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