Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6859212

OOM in xml validator when maxOccurs is large (dup of 6859210)

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P5
    • Resolution: Duplicate
    • Affects Version/s: 6-pool
    • Fix Version/s: None
    • Component/s: xml
    • Labels:

      Description

      we have an issue in the XML Schema validation area with JDK 5 and 6. The problem is, that certain schemas can easily lead to a huge memory footprint in the JVM. Background is that you can specify an attribute "maxOccurs" (and "minOccurs") which controls how often an element in a document may appear (see also: http://www.w3.org/TR/xmlschema-0/, section 2.2.1). With high values for maxOccurs (minOccurs), the syntax tree generated by the XML validator in the JDK can easily "explode", since for each allowed occurrence tree nodes are generated. In our business cases high values for maxOccurs must be possible and therefore we are running into out-of-memory situations easily.
       
      There are a number of known potential workarounds, which all cannot be applied:

          * Use secure processing (see also http://java.sun.com/developer/technicalArticles/xml/jaxp1-3/#Security). This limits the maximum number for minOccurs and maxOccurs, but unfortunately cannot be applied in our business case, since pretty large numbers must be allowed.
          * Use value "unbounded" instead of a number in the maxOccurs (minOccurs) attribute: This reduces the memory footprint, but is semantically different, since no limitation is used. It is also not always possible to change the style sheets, since our customers have many of them, some of them generated out of other data validation descriptions. Therefore our customers are reluctant to change their stylesheets.

      Optimally there would be an implemenation, which does not unroll the max/minOccurs attribute in the syntax tree.
      6859212 was accidentially created. Closed as a dup of 6859210

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              ikrylov Ivan Krylov
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: