I still have to back port the JAXB Marshaller/Unmarshaller improvements. I will do this today evening.
Best, Christian Sent from a mobile device Am 11.04.2012 10:59 schrieb "Claus Ibsen" <claus.ib...@gmail.com>: > Hi > > I fixed some of the know bugs and backported them to the 2.9 branch so > we will have those fixes in the release. > I added a new 2.9.3 version in JIRA and pushed a few tickets to that. > > There is one pending ticket I will look at now, but its not a block > for cutting a release. > https://issues.apache.org/jira/browse/CAMEL-5157 > > > And was there something about a JVM property being added to the JAXB > type converters, that was a copy/paste from Apache CXF? > If so that JVM system property should be named org.apache.camel etc. > And we need to document that. > > > > On Wed, Apr 11, 2012 at 12:09 AM, Christian Müller > <christian.muel...@gmail.com> wrote: > > The numbers are really good! Go ahead with the 2.9.2 release. > > > > Best, > > Christian > > > > Sent from a mobile device > > Am 10.04.2012 17:44 schrieb "Hadrian Zbarcea" <hzbar...@gmail.com>: > > > >> Christian, > >> > >> Are those numbers good? Are they blocking the release? I'd like to cut > the > >> release sometimes this week. > >> > >> Cheers, > >> Hadrian > >> > >> On 04/06/2012 10:58 AM, Christian Müller wrote: > >> > >>> By using a ByteArrayInputStream as payload, and a "warmed up" system (I > >>> sent 100 messages before the measurement to warm up the system) I got > the > >>> following results with the payload of 2046 bytes: > >>> > >>> testUnmarshallConcurrent() took 2202ms (5196ms by using a string as > >>> payload > >>> and a cold system) > >>> testUnmarshallFallbackConcurre**nt() took 1224ms (2761ms by using a > >>> string as > >>> payload and a cold system) > >>> > >>> testMarshallConcurrent() took 875ms > >>> testMarshallFallbackConcurrent**() took 999ms > >>> > >>> Best, > >>> Christian > >>> > >>> On Thu, Apr 5, 2012 at 11:18 PM, Daniel Kulp<dk...@apache.org> wrote: > >>> > >>> > >>>> Great numbers! Huge improvement! > >>>> > >>>> Still wondering why the FallbackTypeConverter is faster than the > >>>>> JaxbDataFormat... > >>>>> > >>>> > >>>> The UnmarshalProcessor which is invoked in this does a: > >>>> > >>>> InputStream stream = ExchangeHelper.** > >>>> getMandatoryInBody(exchange, > >>>> InputStream.class); > >>>> > >>>> since the DataFormat things require a stream. The Fallback stuff can > >>>> keep > >>>> the payload as a String and create the writer from that. Thus, part > of > >>>> the > >>>> time of the JaxbDataFormat tests is constantly converting from String > to > >>>> InputStream. > >>>> > >>>> Probably should update the tests to use a ByteArrayInputStream as the > >>>> payload or something to make them more comparable. > >>>> > >>>> > >>>> Dan > >>>> > >>>> > >>>> > >>>> > >>>> On Thursday, April 05, 2012 11:05:46 PM Christian Müller wrote: > >>>> > >>>>> I did a few test an recorded the fastest one: > >>>>> > >>>>> Length: 2046: > >>>>> ============= > >>>>> Before: > >>>>> testUnmarshallConcurrent() took 14122ms > >>>>> testUnmarshallFallbackConcurre**nt() took 8479ms > >>>>> > >>>>> After: > >>>>> testUnmarshallConcurrent() took 5196ms > >>>>> testUnmarshallFallbackConcurre**nt() took 2761ms > >>>>> > >>>>> Length: 104 > >>>>> =========== > >>>>> Before: > >>>>> testUnmarshallConcurrent() took 7281ms > >>>>> testUnmarshallFallbackConcurre**nt() took 4815ms > >>>>> > >>>>> After: > >>>>> testUnmarshallConcurrent() took 2767ms > >>>>> testUnmarshallFallbackConcurre**nt() took 2458ms > >>>>> > >>>>> Still wondering why the FallbackTypeConverter is faster than the > >>>>> JaxbDataFormat... > >>>>> > >>>>> Best, > >>>>> Christian > >>>>> > >>>>> On Thu, Apr 5, 2012 at 6:55 PM, Daniel Kulp<dk...@apache.org> > wrote: > >>>>> > >>>>>> On Thursday, April 05, 2012 06:46:43 PM Christian Müller wrote: > >>>>>> > >>>>>>> Hi Dan, > >>>>>>> > >>>>>>> great work! I got the following results: > >>>>>>> > >>>>>>> testUnmarshallConcurrent() took 5898ms > >>>>>>> testUnmarshallFallbackConcurre**nt() took 2477ms > >>>>>>> testMarshallFallbackConcurrent**() took 1728ms > >>>>>>> testMarshallConcurrent() took 1674ms > >>>>>>> > >>>>>>> I'm wondering why 'testUnmarshallConcurrent()' is significant > slower > >>>>>>> than > >>>>>>> '**testUnmarshallFallbackConcurre**nt()'... > >>>>>>> > >>>>>> > >>>>>> testUnmarshallFallbackConcurre**nt still uses your "old" tiny > >>>>>> payload. > >>>>>> I > >>>>>> only updated testUnmarshallConcurrent to use a much larger payload. > (I > >>>>>> think around 2K). Feel free to play with the payload sizes and > such > >>>>>> to > >>>>>> get some comparisons and such. > >>>>>> > >>>>>> > >>>>>> Dan > >>>>>> > >>>>>> 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 > >>>>>>>> > >>>>>>> > >>>>>> -- > >>>>>> Daniel Kulp > >>>>>> dk...@apache.org - http://dankulp.com/blog > >>>>>> Talend Community Coder - http://coders.talend.com > >>>>>> > >>>>> -- > >>>> Daniel Kulp > >>>> dk...@apache.org - http://dankulp.com/blog > >>>> Talend Community Coder - http://coders.talend.com > >>>> > >>>> > >>>> > >>> > >> -- > >> Hadrian Zbarcea > >> Principal Software Architect > >> Talend, Inc > >> http://coders.talend.com/ > >> http://camelbot.blogspot.com/ > >> > > > > -- > Claus Ibsen > ----------------- > CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ >
