Awesome work Claus ! This will make camel much easier to debug imho.
2013/5/20 Claus Ibsen <claus.ib...@gmail.com> > 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 >
