Yes, exactly. Completely agree with this approach. I'm amazed with the amount of stack frame bloat you've been able to remove already! Great work!
I'm planning to contribute too. Will sync up with you on IRC. Regards, *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 Mon, May 20, 2013 at 10:16 AM, Claus Ibsen <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> 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> > 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 > >> > > > > -- > 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 >
