camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: [DISCUSS] Upcoming 2.9.2 and 2.8.5 releases
Date Wed, 11 Apr 2012 08:58:36 GMT
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.mueller@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" <hzbarcea@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<dkulp@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<dkulp@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<dkulp@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
>>>>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Daniel Kulp
>>>>>> dkulp@apache.org - http://dankulp.com/blog
>>>>>> Talend Community Coder - http://coders.talend.com
>>>>>>
>>>>> --
>>>> Daniel Kulp
>>>> dkulp@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: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Mime
View raw message