[XMLBEANS-610] Compiling XSD is slow since version 5.0.1

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: Version 5.1.0
• Assignee: Unassigned
• Reporter: Pavel Salamon
• Created: 02/Jun/22 12:01
• Updated: 13/Jun/22 09:02
• Resolved: 13/Jun/22 09:02

Description

In our project we use XMLBeans to compile XSD using method org.apache.xmlbeans.XmlBeans.compileXsd(XmlObject[], SchemaTypeLoader, XmlOptions)

 

After upgrading to version 5.0.1 or newer, there is a large performance drop inside XMLBeans. The slowness depends on JVM implementation and size of classpath. In our use cases we went from 4 seconds (XMLBeans 4.0) to ~3 minutes (XMLBeans 5.0.1).

We managed to find the reason, it's related to changed made in https://issues.apache.org/jira/browse/XMLBEANS-82

 

In 5.0.1 and newer versions, XMLBeans loads instance of javax.xml.parsers.SAXParserFactory using javax.xml.parsers.FactoryFinder which is very slow with larger classpaths. Stacktrace fragment shows the way from XmlBeans.compileXsd() to the slow classloading part:

    jdk.internal.loader.URLClassPath$Loader.findResource line: 626 
   jdk.internal.loader.URLClassPath$1.next line: 341 
   jdk.internal.loader.URLClassPath$1.hasMoreElements line: 351 
   java.net.URLClassLoader$3$1.run line: 687 
   java.net.URLClassLoader$3$1.run line: 685 
   java.security.AccessController.doPrivileged line: not available [native method]
   java.net.URLClassLoader$3.next line: 684 
   java.net.URLClassLoader$3.hasMoreElements line: 709 
   org.springframework.boot.loader.LaunchedURLClassLoader$UseFastConnectionExceptionsEnumeration.hasMoreElements line: 336 
   java.lang.CompoundEnumeration.next line: 3032 
   java.lang.CompoundEnumeration.hasMoreElements line: 3041 
   java.lang.CompoundEnumeration.next line: 3032 
   java.lang.CompoundEnumeration.hasMoreElements line: 3041 
   org.jetel.util.CompoundEnumeration.hasMoreElements line: 56 
   org.jetel.util.CompoundEnumeration.hasMoreElements line: 56 
   java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass line: 1202 
   java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService line: 1220 
   java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext line: 1264 
   java.util.ServiceLoader$2.hasNext line: 1299 
   java.util.ServiceLoader$3.hasNext line: 1384 
   javax.xml.parsers.FactoryFinder$1.run line: 287 
   java.security.AccessController.doPrivileged line: not available [native method]
   javax.xml.parsers.FactoryFinder.findServiceProvider line: 283 
   javax.xml.parsers.FactoryFinder.find line: 261 
   javax.xml.parsers.SAXParserFactory.newInstance line: 147 
   org.apache.xmlbeans.impl.common.SAXHelper.saxFactory line: 62 
   org.apache.xmlbeans.impl.common.SAXHelper.newXMLReader line: 47 
   org.apache.xmlbeans.impl.store.Locale.getSaxLoader line: 2227 
   org.apache.xmlbeans.impl.store.Locale.lambda$parseToXmlObject$1 line: 501 
   org.apache.xmlbeans.impl.store.Locale$$Lambda$807/0x0000000100944440.parse line: not available 
   org.apache.xmlbeans.impl.store.Locale.syncWrap line: 488 
   org.apache.xmlbeans.impl.store.Locale.parseToXmlObject line: 499 
   org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.parse line: 139 
   org.apache.xmlbeans.impl.schema.AbstractDocumentFactory.parse line: 40 
   org.apache.xmlbeans.impl.schema.SchemaTypeImpl.parseDocumentation line: 2406 
   org.apache.xmlbeans.impl.schema.SchemaTypeImpl.setParseContext line: 2256 
   org.apache.xmlbeans.impl.schema.StscTranslator.translateGlobalSimpleType line: 675 
   org.apache.xmlbeans.impl.schema.StscTranslator.addAllDefinitions line: 138 
   org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compileImpl line: 255 
   org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile line: 174 
   org.apache.xmlbeans.XmlBeans.compileXmlBeans line: 407 
   org.apache.xmlbeans.XmlBeans.compileXsd line: 297 

 

In previous XMLBeans versions this classloading did not happen when method XmlBeans.compileXsd() was called, so it was much faster.

 

The only workarounds seem to be configuring global JVM settings like -Djavax.xml.parsers.SAXParserFactory. This affects other uses besides XMLBeans so it cannot be always done.

 

Can this behavior be configurable in any way?

Method XmlBeans.compileXsd() already takes XmlOptions instance as a parameter, but configuring it using XmlOptions .setLoadUseXMLReader() doesn't help as that property is not supported there. If we could define our own XMLReader through XmlOptions, we are hoping that XMLBeans would not try to load XMLReader itself using the slow SAXParserFactory classloading way.

Issue Links

• links to: GitHub Pull Request #6