 | | | Commented: (XERCESJ-1227) Poor performance / OutOfMemoryError for sequenc | Commented: (XERCESJ-1227) Poor performance / OutOfMemoryError for sequenc 2007-08-10 - By Georg Fischer (JIRA)
[ https://issues.apache.org/jira/browse/XERCESJ-1227?page=com.atlassian
.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519144 ]
Georg Fischer commented on XERCESJ-1227:
----------------------------------------
With Xerces 2.9.0 I had persistent OutOfMemory problems with a ISO 20022 schema
whch was modified for SEPA. Even -Xmx512m did not help.
The original schema on http://www.iso20022.org/index.cfm?item_id=60055 for oain
.001.001.02
works fine. The modifed SEPA schema has the following restrictions as compared
to the ISO schema:
427c427
< <xs:element name="CdtTrfTxInf" type="CreditTransferTransactionInformation2
" maxOccurs="unbounded"/>
---
> <xs:element name="CdtTrfTxInf" type="CreditTransferTransactionInformation2
" maxOccurs="9999999"/>
527c527
< <xs:element name="RfrdDocAmt" type="ReferredDocumentAmount1Choice"
minOccurs="0" maxOccurs="unbounded"/>
---
> <xs:element name="RfrdDocAmt" type="ReferredDocumentAmount1Choice"
minOccurs="0" maxOccurs="999999"/>
Instances validate with this schema in XMLSpy, but Xerces blows up.
I feel that such high upper bounds make not much sense. I would much like to be
able to validate against such schemata with Xerces code. If you cannot rewrite
the DFA in general, my suggestion for the Xerces code would be
(a) to silently replace such high maxOccurs values by "unbounded"
(b) to introduce a special feature which allows the user to control such a
replacement
> Poor performance / OutOfMemoryError for sequences, choices and nested with
large minOccurs/maxOccurs
> -----------------------------------------------------------------------------
-----------------------
>
> Key: XERCESJ-1227
> URL: https://issues.apache.org/jira/browse/XERCESJ-1227
> Project: Xerces2-J
> Issue Type: Bug
> Components: XML Schema Structures
> Affects Versions: 2.9.0
> Reporter: Michael Glavassevich
> Priority: Minor
>
> We now handle large minOccurs/maxOccurs on element/wildcard particles more
gracefully by creating a compact representation in the DFA and using counters
to check the occurence constraints, however we will still fully expand the
content model for minOccurs/maxOccurs on sequences and choices which could
still lead to an OutOfMemoryError or very poor performance (i.e. could still
take several minutes to build the DFA). Sequences, choices and nested
minOccurs/maxOccurs are somewhat tricker to handle. We would need a more
general solution than the one implemented for elements and wildcards to improve
those.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@(protected)
For additional commands, e-mail: j-dev-help@(protected)
|
|
|