Hi Claus, It's great that you're finding time for this. The need to lighten stacktraces was already brought up within the Camel 3.0 context [1]. In fact, there's also an entry in the roadmap page [2] which proposes moving away from the recursive model into an iterative routing engine.
It's clear that the next step in that area is a prototype. I hope I can start working on that soon, even though the whole Camel 3.0 conversation seems to have cooled down at present. Anyway, do you have a concrete work plan or list of processors you'd are targeting with https://issues.apache.org/jira/browse/CAMEL-6377? If so, could you create a few individual JIRA tasks? I'd happily take on some of the simplification/rationalisation work! Regards, [1] http://camel.465427.n5.nabble.com/DISCUSS-Camel-3-0-Core-of-the-routing-engine-td5727754.html [2] http://camel.apache.org/camel-30-ideas.html *Raúl Kripalani* Enterprise Architect, Open Source Integration specialist, Program Manager | Apache Camel Committer http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Sat, May 18, 2013 at 3:38 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Just to tell about the work I am currently doing > https://issues.apache.org/jira/browse/CAMEL-6377 > > We have room to optimize the routing engine in Camel to make it more > friendlier to end users in terms of > - reduced stacktraces > - faster and easier to debug the code if you single step through all > the routing engine logic > - potential optimization to skip over functionality that is turned off > (eg such as tracer etc) > - potential optimization to add new cross cutting functionality at > runtime (though not currently the primary goal) > - potential to skip using RedeliveryErrorHandler/DefaultErrorHandler > if end user have not configured to use any kind of redelivery (the > reason is that logic in this guy is excessive and is harder for people > to debug) > - reduce wrapping internal processors when not needed > > > There is a sample route in the ticket where a stacktrace is forced > being thrown. And the difference is 40 vs 28 lines in the stacktrace. > And there is room for further optimization. > > The work is aimed at being non invasive on the current architecture > and also backwards compatible. So far I have noticed a problem with > the old behavior I have logged as: > https://issues.apache.org/jira/browse/CAMEL-6378 > > > > > -- > Claus Ibsen > ----------------- > www.camelone.org: The open source integration conference. > > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen >
