Re: contention during XMLReaderFactory.createXMLReader

Michael Glavassevich <[email protected]>
Newsgroups gmane.text.xml.xerces-j.user
Message-ID <OF9EDD066F.98F07B10-ON85257C22.0062EBF7-85257C22.0063F4C3@ca.ibm.com>
Hi Andrew,

System properties are global settings. It's not always a good idea to set 
them. If you were to set the system property in an application server 
where other applications have a preference to use alternate JAXP 
implementations you may break them.

Frameworks such as OSGi allow bundles to be loaded/unloaded dynamically 
meaning that the "classpath" which the ClassLoader searches over can 
change over time. It may return a different implementation or another 
version of the same implementation depending on when you invoke 
XMLReaderFactory.createXMLReader().

Thanks.

Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]

Andrew Welch <[email protected]> wrote on 11/13/2013 06:10:12 AM:

> Hi again,
> 
> Out of interest - what's the reason for not setting the system
> property after doing the META-INF search?  At the moment every jar
> file gets examined every time an XMLReader is created - is there a
> situation where users want different results from subsequent calls to
> createXMLReader("...")  controlled purely by the classpath?
> 
> With that system property set, it's really fast to create XMLReaders...
> 
> 
> On 12 November 2013 19:18, Michael Glavassevich <[email protected]> 
wrote:
> > Hi Andrew,
> >
> > Creating a new XML parser can be very expensive. The ClassLoader used 
to
> > create the parser and its internal components might block or spend a 
long
> > time searching its "classpath" for META-INF/services files. This is 
why
> > it's generally a good idea to cache and reuse [1] XML parser 
instances.
> >
> > Thanks.
> >
> > [1]
> > 
http://www.ibm.com/developerworks/xml/library/x-perfap2/index.html#reuse
> >
> > Michael Glavassevich
> > XML Technologies and WAS Development
> > IBM Toronto Lab
> > E-mail: [email protected]
> > E-mail: [email protected]
> >
> > Andrew Welch <[email protected]> wrote on 11/12/2013 07:48:47 
AM:
> >
> >> Hi,
> >>
> >> A colleague was doing some performance testing and discovered some
> >> contention at this line of my code:
> >>
> >> 
XMLReaderFactory.createXMLReader("org.apache.xerces.parsers.SAXParser");
> >>
> >> ...which was surprising : ) He informed me it was doing a blocking
> >> operation every time.
> >>
> >> Anyway, he went away and went through the Xerces source and found 
that
> >> if the "org.apache.xerces.xni.parser.XMLParserConfiguration" system
> >> property is not set it does indeed do a blocking operation (in
> >> parsers.ObjectFactory)
> >>
> >> To demonstrate this, run the below code with and without the system
> >> property set:
> >>
> >> public static void main(String... args) throws Exception {
> >>
> >>     //System.setProperty
> >> ("org.apache.xerces.xni.parser.XMLParserConfiguration",
> >>     // "org.apache.xerces.parsers.XIncludeParserConfiguration");
> >>
> >>     long start = System.nanoTime();
> >>
> >>     for (int i = 0; i <= 10000; i++) {
> >>         XMLReaderFactory.createXMLReader
> >> ("org.apache.xerces.parsers.SAXParser");
> >>     }
> >>
> >>     long end = System.nanoTime();
> >>     double millis = (end - start) * 1e-6;
> >>
> >>     System.out.println(millis);
> >>
> >> }
> >>
> >> On my machine it consistently takes around ~2000ms without the system
> >> property, and ~1300ms with.
> >>
> >> This is present in both 2.9 and 2.11 as far as I can see.
> >>
> >>
> >>
> >>
> >> --
> >> Andrew Welch
> >> http://andrewjwelch.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> 
> 
> 
> -- 
> Andrew Welch
> http://andrewjwelch.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.