On Wed July 15 2009 12:14:02 pm Kevin Conaway wrote: > 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.
The trick is that we really don't know when we can use the non-synced versions or not. We'd have to be conservative. Example: if the packagename of the factory contains wstx, then don't wrapper, otherwise do. Over time, we could find other thread safe implementations where we could update this. > 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? Well, they would be changed to call something like: StaxUtils.createXMLStreamReader(....) where internally, we could grab an instance from a pool, use it, then return it to the pool, and return the reader. Dan > > 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 -- Daniel Kulp [email protected] http://www.dankulp.com/blog
