Hi Dan,
great work! I got the following results:
testUnmarshallConcurrent() took 5898ms
testUnmarshallFallbackConcurrent() took 2477ms
testMarshallFallbackConcurrent() took 1728ms
testMarshallConcurrent() took 1674ms
I'm wondering why 'testUnmarshallConcurrent()' is significant slower than
'testUnmarshallFallbackConcurrent()'...
Best,
Christian
On Thu, Apr 5, 2012 at 4:53 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Christian,
>
> I just committed some updates to the jaxb component to completely flip all
> the unmarshalling over to StAX which completely removes the need for the
> pooling and locks and such. Can you give it a quick run on your box and
> see how the performance looks? I'd also be curious about the difference
> with the larger XML messages created with the code below.
>
> One note: right now, this REQUIRES Woodstox to be at all threadsafe. I'm
> going to try and update the StaxConverter to work better with the in-jdk
> stax parser. There is a TON of code in CXF I can use, just depends on if
> it's easier to just copy the code over or somehow shade it in or something.
>
> Anyway, can you give it a quick run with Woodstox and let me know how it
> goes?
>
> Dan
>
>
>
>
>
> On Wednesday, April 04, 2012 05:54:35 PM Daniel Kulp wrote:
> > On Wednesday, April 04, 2012 05:21:25 PM Daniel Kulp wrote:
> > > On Wednesday, April 04, 2012 11:09:14 PM Christian Müller wrote:
> > > > I just committed the last piece of code for [1] which improve the
> > > > performance of XML unmarshalling with JAXB. I would like to see this
> > > > improvement also in Camel 2.9.2 and Camel 2.8.5. At present I'm
> > > > waiting
> > > > for the users response whether this solution out performs his custom
> > > > pooling solution (using commons-pool).
> > > > I would also appreciate if you could have a look at the changes.
> > >
> > > I'll take a closer look tomorrow, but my initial look at the code
> > > definitely has concerns in a multi-threaded case. Putting a lock
> > > around
> > > the unmarshall it really going to cause a performance hit in
> > > multi-threaded cases, particularly with larger payloads. I'll play a
> > > bit with it tomorrow to see what I can do with it.
> >
> > Yea... a very quick test by creating the payload string via:
> >
> > private int fooBarSize = 200;
> > public String createPayload() throws Exception {
> > Foo foo = new Foo();
> > for (int x = 0; x < fooBarSize; x++) {
> > Bar bar = new Bar();
> > bar.setName("Name: " + x);
> > bar.setValue("value: " + x);
> > foo.getBarRefs().add(bar);
> > }
> > Marshaller m = JAXBContext.newInstance(Foo.class,
> > Bar.class).createMarshaller();
> > StringWriter writer = new StringWriter();
> > m.marshal(foo, writer);
> > return writer.toString();
> > }
> >
> > (ends up just over 8K in size)
> >
> > and then removing the locks and creating a new unmarshaller per request
> > drops the time from 12 seconds to 5.5 seconds on my machine.
> > (testUnmarshallConcurrent) That's huge. I'll look a bit more
> tomorrow.
> >
> > Dan
> >
>
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
