JDK-8028111 : XML readers share the same entity expansion counter
  • Type: Bug
  • Component: xml
  • Sub-Component: jaxp
  • Affected Version: 5.0u55,6u65,7u45,8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-11-11
  • Updated: 2017-05-19
  • Resolved: 2013-11-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7 JDK 8 JDK 9
5.0u61Fixed 6u71Fixed 7u51Fixed 8 b124Fixed 9Fixed
Related Reports
Relates :  
Relates :  
Issue described here:
Oct 23, 2013 11:07 PM by Borislav.Andruschuk
After upgrading to 1.7.0_45 we have noticed that StAX XMLInputFactory started throwing an exception on reader creation for our simple XML messages. After some investigation, we found that all XML readers share the same XMLSecurityManager and the same XMLLimitAnalyzer with its aggregated total entity expansion counter. It is my understanding that the counter is supposed to be local per reader and not shared across all of them.
The default entity expansion limit is 64000 and if XMLInputFactory tries to create more than 64000 readers It fails because XMLLimitanalyzer total counter is accumulated and at some point exceeds the limit.
OS version:
I assume It should be related to all OS versions, checked only MacOS and RHEL
Development Kit or Runtime version:

java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
Regression information:

Test case defined below works on prior JDK versions to 1.7.0_45

Steps to Reproduce:

1. create XMLInputFactory
XMLInputFactory factory = XMLInputFactory.newInstance();
2. create XMLEventReader:
3. repeat step 2 64001 times (default entity expansion limit is 64000)
Expected Result:

XMLInputFactory should be able to create as many XMLReaders as requested
Actual Result:

JAXP00010001 error

Error Message(s):
Exception in thread "main" javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1]
Message: JAXP00010001: The parser has encountered more than "64000" entity expansions in this document; this is the limit imposed by the JDK.
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.setInputSource(XMLStreamReaderImpl.java:219)
at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.<init>(XMLStreamReaderImpl.java:189)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.getXMLStreamReaderImpl(XMLInputFactoryImpl.java:277)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLStreamReader(XMLInputFactoryImpl.java:129)
at com.sun.xml.internal.stream.XMLInputFactoryImpl.createXMLEventReader(XMLInputFactoryImpl.java:78)
at Main.main(Main.java:38)
Source code for an executable test case:

import java.io.ByteArrayInputStream;
import javax.xml.stream.XMLInputFactory;
public class Main {
    public static void main(String[] args) throws Exception {
        String xml = "<?xml version=\"1.0\"?><test></test>";
        XMLInputFactory factory = XMLInputFactory.newInstance();
        for (int i = 0; i < 64001; i++) {
            ByteArrayInputStream stream = new ByteArrayInputStream(xml.getBytes());
The workaround is to disable FPS or entity expansion limit (be careful now your code can be vulnerable to denial of service attack, see replies on Bug ID: JDK-4843787 org.xml.sax.SAXException was thrown when parsing large file )
- set system property jdk.xml.entityExpansionLimit to 0
- disable FPS in XMLSecurityManager for XMLInputFactory:
        XMLInputFactory factory = XMLInputFactory.newInstance();
        XMLSecurityManager securityManager = new XMLSecurityManager(false);
        factory.setProperty("http://apache.org/xml/properties/security-manager", securityManager);
Related below 3 tests work well based on latest 8-cpu1401 binaries. javax/xml/jaxp/common/8014530/ResetLimitTest.java javax/xml/jaxp/common/8014530/ResetLimitXSLTTest.java javax/xml/jaxp/common/8014530/StAXLimitTest.java

Just to note another example of this in OpenGamma: http://jira.opengamma.com/browse/PLAT-5046 We're going to recreate the factory every time as the fix.

SQE OK to take the fix into CPU14_01 based on the nighlty test run results.

CAP member had reported the same regression bug in Java 7u45/6u65 . This bug killed their production system after a short period of time and they had to roll back to the previous versions. The details are already public, for example: https://forums.oracle.com/thread/2594170 It is a critical issue for the CAP member and would like have a fix for 6 and 7 update releases

Workaround: Assuming it's feasible to re-create the factory, then a better workaround is to refresh the factory upon encountering the JAXP00010001 EntityExpansionLimit error. Using the code as in the bug report, the following demonstrate this approach: static XMLInputFactory factory = XMLInputFactory.newInstance(); public void workaround() { String xml = "<?xml version=\"1.0\"?><test></test>"; try { int reTry = 0; for (int i = 0; i < 64001; i++) { ByteArrayInputStream stream = new ByteArrayInputStream(xml.getBytes()); try { factory.createXMLEventReader(stream); } catch (XMLStreamException e) { if (reTry == i) { ///this individual file does exceed the limit throw new XMLStreamException(e); } //refresh the factory if (e.getMessage().indexOf("JAXP00010001") > -1) { factory = XMLInputFactory.newInstance(); reTry = i; i = i-1; } } } } catch (Exception e) { //handling exception } }

Wordaround: The workaround is to increase the entity expansion limit, and total entity size limit depending on the size of the entity references. The getEntityCountInfo Property may be helpful in evaluating the limits. Please refer to http://docs.oracle.com/javase/tutorial/jaxp/limits/using.html for more details.

The limit values need to be reset per each parsing operation.