Yep a lock is IMHO never the solution.
The frameworks of the future is lock free solutions.

People have many different use-cases, so what may appear to work for a
single scenario may not work well for another.
And what happens when people run on servers which has 16+ cores, where
concurrency can make a bigger difference.

IMHO the pool would work better in general.


On Wed, Apr 4, 2012 at 11:54 PM, Daniel Kulp <dk...@apache.org> 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
>
>
>
>
>>
>> Dan
>>
>> > Regarding Camel 2.10.0:
>> > The last Spring3.1 build [2] run successfully.
>> > For Java 7 support I need more time (and appreciate any help) and I'm
>> > not
>> > 100% sure it will work.
>> >
>> > [1] https://issues.apache.org/jira/browse/CAMEL-3776
>> > [2]
>> > https://builds.apache.org/view/A-F/view/Camel/job/Camel.trunk.fulltest.s
>> > pr ing3.1/
>> >
>> > Best,
>> > Christian
>> >
>> > On Wed, Apr 4, 2012 at 11:14 AM, Claus Ibsen <claus.ib...@gmail.com>
>>
>> wrote:
>> > > A good idea about a 2.9.2 release. And possible 2.8.x as well.
>> > >
>> > > In terms of 2.10 then I think it needs more time. Spring 3.1 and Java7
>> > > support is hanging a bit there. Not throughly tested and complete.
>> > >
>> > > Also a lot of new components in 2.10, which is neither documented, and
>> > > properly tested (especially for OSGi). Just because a bundle
>> > > can be installed in OSGi, does not mean the camel component actually
>> > > works. So we need osgi tests to ensure that.
>> > >
>> > >
>> > >
>> > > On Tue, Apr 3, 2012 at 2:50 PM, Hadrian Zbarcea <hzbar...@gmail.com>
>> > >
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > I back merged trunk to 2.9.x and will take care of 2.8.x today.
>> > > > There
>> > > > are
>> > > > only 10 issues left in 2.9.x (half of them are mine) and I'll work
>> > > > on
>> > > > closing them down and getting ready for a release towards the end of
>> > > > this
>> > > > week, or early next week.
>> > > >
>> > > > There are also a ton of features/improvement on the trunk as well. I
>> > >
>> > > think
>> > >
>> > > > we should consider releasing 2.10.0 this month as well, but this
>> > > > should
>> > > > probably be another thread.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > --
>> > > > 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/
> --
> Daniel Kulp
> dk...@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.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/

Reply via email to