cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Conaway <kevin.cona...@gmail.com>
Subject Re: Performance issue in StaxInInterceptor
Date Wed, 15 Jul 2009 16:14:02 GMT
How about CXF bundling its own implementation of XMLInputFactory that
provides thread safe wrappers around the JDK version?  This could used if
Woodstox (or any other implementation) is not available.

Otherwise, pooling might work.  StaxInInterceptor ends up calling
StaxUtils.getXMLInputFactory() for each call.  This means that all instances
of the interceptor end up using the same instance.  Where would be the
appropriate place to pool the factories?

On Wed, Jul 15, 2009 at 10:44 AM, Daniel Kulp <dkulp@apache.org> wrote:

> On Wed July 15 2009 10:24:01 am Kevin Conaway wrote:
> > In cxf-2.2.2, StaxInInterceptor#handleMessage() synchronizes on the
> > XMLInputFactory before calling
> > XMLInputFactory#createXMLStreamReader(InputStream, String).
> >
> > Is this synchronization necessary?  Profiling our application reveals
> this
> > to be a pain point in high volume situations
>
> Well, kind of depends on which Stax implementation.   With woodstox, no.
>  It
> wasn't necessary.   But if you use the Stax implementation built into JDK6,
> it
> IS necessary.   Per spec, the XMLInputFactory implementations are not
> guaranteed to be thread safe and the Sun versions are not.   Thus, we need
> to
> sync on it to create the reader.   Otherwise, we ended up with multiple
> threads using the same XMLStreamReader (and writer) and thus having
> improper
> results and such.
>
> Not sure what the options are.   I suppose one option could be to use a
> pool
> of XMLInputFactory objects.   That would avoid the sync on the
> XMLInputFactory, but would introduce a sync on the pool, although that sync
> should be much shorter lived/cheaper.  Obviously slightly higher memory
> usage
> as well to have multiple factories around.   Probably worth it though.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message