cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Commented: (CXF-2342) Performance issue in StaxInInterceptor
Date Wed, 15 Jul 2009 20:23:15 GMT


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:
>             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|]:
> 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.

View raw message