[
https://issues.apache.org/jira/browse/CAMEL-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117805#comment-15117805
]
Karsten Blees commented on CAMEL-9534:
--------------------------------------
[~dkulp] Actually, using StAXSource involves two global locks...StaxConverter
uses LinkedBlockingQueue to cache XMLInputFactories, i.e. requires one lock for
{{pull()}} and another for {{offer()}}. Additionally, the pool size is quite
small (number of processors), which may become a bottleneck with many threads
and small XML documents (empty pool means create and configure a new
XMLInputFactory from scratch).
On the other hand, using SAXSource creates and configures a new
SAXParserFactory *every* time (in {{XmlConverter.toSAXSourceFromStream}}). I
guess this is the performance problem you're referring to?
> XsltComponent: fix support for Saxon-B (and Woodstox)
> -----------------------------------------------------
>
> Key: CAMEL-9534
> URL: https://issues.apache.org/jira/browse/CAMEL-9534
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-xslt
> Affects Versions: 2.11.4, 2.12.3, 2.13.0, 2.14.0
> Reporter: Karsten Blees
> Attachments:
> 0001-CAMEL-9534-XsltComponent-set-default-of-allowStAX-op.patch,
> 0002-CAMEL-9534-XsltComponent-fix-support-for-Saxon-B-and.patch,
> xmlparserbench.7z
>
>
> AFAIK Saxon-B is the only XSLT 2 processor that supports Java extensions
> (that's why it is still available for download on the Saxon site).
> CAMEL-7130 enabled the "allowStAX" option by default, which is not supported
> by Saxon-B. This also breaks handling of CDATA sections with the Woodstox
> StAX implementation.
> CAMEL-7753 tries to configure Saxon's MessageWarner class via a proprietary
> Saxon API that seems to change frequently - the current code only works with
> Saxon 9.3 - 9.5 (see also CAMEL-7891, CAMEL-8830).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
