Hi We got that camel-jaxb bug backported now to the 2.8.x branch. I think it would be a good time to start cutting a new 2.8.5 release.
On Wed, Apr 11, 2012 at 12:06 PM, Christian Müller <christian.muel...@gmail.com> wrote: > 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/ >> -- 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/
