Cool. This change makes Camel more green :)
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Tuesday, May 21, 2013 at 8:17 PM, Claus Ibsen wrote: > Hi > > Okay so we got some good headway now. > > The sample use case on 2.11 has a stacktrace of about 40 lines (without JMX). > And on trunk we are down to 17 now (without JMX) and +2 if JMX enabled. > > That is reducing the stack traces with by 3 fold in that given sample. > > > > On Mon, May 20, 2013 at 11:16 AM, Claus Ibsen <claus.ib...@gmail.com > (mailto:claus.ib...@gmail.com)> wrote: > > Hi > > > > I added some tasks as comments on > > https://issues.apache.org/jira/browse/CAMEL-6377#comment-13661858 > > > > The goal of CAMEL-6377 is to do *internal* optimiztion changes only > > with the goal of minimazing the stack-frames in use, as well reduce > > the long stacktraces our end users see. And also for the end users who > > go down the path of debugging the Camel routing, then there is less > > "callback hell". > > > > As Raul said we have ideas sketched for Camel 3.0, where we can do > > bigger changes, and as well do some API changes (if it makes > > value/sense) etc. And the ideas that Raul refers to is much bigger and > > takes a lot longer to implement. And possible some prototype is > > needed. And also care has to be taken as we have DSL in Scala / Groovy > > / Kotlin etc. that may be affected. And also a large user base on 2.x > > API that relies on this being stable etc. > > > > However as in CAMEL-6377 with fairly little effort (half a friday + > > half a day on weekend + half toda) + the effort for the remainder > > tasks (eg the comment on the JIRA) we could get this implemented > > fairly soon. > > > > Its IMHO important to keep the scope on the goals of "reducing > > stack-frames, less long stacktraces, and easier debugging). All the > > stuff about iterative routing engine etc, is also what is captured on > > the Camel 3.0 ideas page, and also sketched in more details by Raul > > with his idea of "decision" being returned from the processor(s). But > > that is IMHO not the current scope of CAMEL-6377. The scope is to be > > internal optimizations on the current 2.x architecture. > > > > If people wanna help with CAMEL-6377, then check the JIRA ticket and > > the list of bulleted tasks. > > > > The code changes is about to be committed later this afternoon. Just > > running one extra fully sanity unit tests of the entire code base, to > > ensure no regressions or other gremlins introduced. Including all the > > OSGi tests which you need to run specially. > > > > > > > > > > On Sat, May 18, 2013 at 5:39 PM, Raul Kripalani <r...@evosent.com > > (mailto:r...@evosent.com)> wrote: > > > 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 > > > (mailto: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 (http://www.camelone.org): The open source integration > > > > conference. > > > > > > > > Red Hat, Inc. > > > > FuseSource is now part of Red Hat > > > > Email: cib...@redhat.com (mailto:cib...@redhat.com) > > > > Web: http://fusesource.com > > > > Twitter: davsclaus > > > > Blog: http://davsclaus.com > > > > Author of Camel in Action: http://www.manning.com/ibsen > > > > > > > > > > > > > > > -- > > Claus Ibsen > > ----------------- > > www.camelone.org (http://www.camelone.org): The open source integration > > conference. > > > > Red Hat, Inc. > > FuseSource is now part of Red Hat > > Email: cib...@redhat.com (mailto:cib...@redhat.com) > > Web: http://fusesource.com > > Twitter: davsclaus > > Blog: http://davsclaus.com > > Author of Camel in Action: http://www.manning.com/ibsen > > > > > > -- > Claus Ibsen > ----------------- > www.camelone.org (http://www.camelone.org): The open source integration > conference. > > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com (mailto:cib...@redhat.com) > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
