[
https://issues.apache.org/jira/browse/CXF-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731659#action_12731659
]
Daniel Kulp commented on CXF-2342:
----------------------------------
I've committed a slightly modified version of this to trunk (and soon to the
other branches).
Basically, the changes to StaxIn/StaxOut wouldn't have worked. We DO need to
be able to specify a factory separate from the StaxUtils cached versions.
That is how things like JSON and FastInfoset support work. They place a
factory that is used instead. I changed the methods to return null if they
don't find one and then call StaxUtils if null. Otherwise, sync on the
factory and call the factory.
I've also changed to using a LinkedBlockingQueue and NOT pre-populate anything.
If poll returns null, it will just create a new one. Thus, on low-volume
cases, the queue may stay small with just a couple instances. On higher
volume, it may grow. Also, that could allow the call to getXmlInputFactory()
to remain public.(although I didn't do that right now) If they don't return
it, it's not a HUGE deal as another would get created.
> Performance issue in StaxInInterceptor
> --------------------------------------
>
> Key: CXF-2342
> URL: https://issues.apache.org/jira/browse/CXF-2342
> Project: CXF
> Issue Type: Improvement
> Affects Versions: 2.2.2
> Reporter: Kevin Conaway
> Assignee: Daniel Kulp
> Attachments: CXF-2342.patch
>
>
> From this mailing list thread [Performance issue in
> StaxInInterceptor|http://www.nabble.com/Performance-issue-in-StaxInInterceptor-td24499018.html]:
> In cxf-2.2.2, StaxInInterceptor#handleMessage() synchronizes on the
> XMLInputFactory before calling
> XMLInputFactory#createXMLStreamReader(InputStream, String).
> Profiling our application reveals this to be a pain point in high volume
> situations
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
