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> 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 -- 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
