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/