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 <[email protected]> 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 > [email protected] > http://www.dankulp.com/blog >
