[jira] [Comment Edited] (CAMEL-6377) Optimize routing engine to reduce stack frames in use during routing and reduce callbacks

["Claus Ibsen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13661858#comment-13661858 ] 

Claus Ibsen edited comment on CAMEL-6377 at 5/21/13 9:04 AM:
-------------------------------------------------------------

Things to do:

1. Naming the API is hard so the names is not set in stone. 
2. Passing state from before -> after, is the current approach fine?
3. All the current tasks are in the same parent class, this gives a full overview of the ones we have. Should we put them in separate classes, and in a sub package?
4. Migrate JMX InstrumentationProcessor to a new task *(done for route, not possible yet for each processor due we keep track of redeliveries as well)*
5. Migrate Tracer to a new task (a bit harder as it has some custom tracer factory and whatnot) (the tracer is a bit ugly and should be ditched for Camel 3.0 and rewritten - or just rely on backlog tracer) *(done by disabling tracer out of the box)*
6. Add more javadoc to the API if missing
7. Look at DefaultChannel and see if we should merge/migrate it with this new stuff.
8. And consider dropping the Channel name as it was a pseudo name, and EIP term for Channel is better for external communication. Its only internal so end users is not affected.
9. All together its important to be backwards compatible and only do internal optimizations. *(done)*


                
      was (Author: davsclaus):
    Things to do:

1. Naming the API is hard so the names is not set in stone. 
2. Passing state from before -> after, is the current approach fine?
3. All the current tasks are in the same parent class, this gives a full overview of the ones we have. Should we put them in separate classes, and in a sub package?
4. Migrate JMX InstrumentationProcessor to a new task
5. Migrate Tracer to a new task (a bit harder as it has some custom tracer factory and whatnot) (the tracer is a bit ugly and should be ditched for Camel 3.0 and rewritten - or just rely on backlog tracer)
6. Add more javadoc to the API if missing
7. Look at DefaultChannel and see if we should merge/migrate it with this new stuff.
8. And consider dropping the Channel name as it was a pseudo name, and EIP term for Channel is better for external communication. Its only internal so end users is not affected.
9. All together its important to be backwards compatible and only do internal optimizations.


                  
> Optimize routing engine to reduce stack frames in use during routing and reduce callbacks
> -----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-6377
>                 URL: https://issues.apache.org/jira/browse/CAMEL-6377
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.12.0
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>             Fix For: 2.12.0
>
>
> We can optimize the Camel routing engine internally, and redue the need for wrapping processors (those internally used for cross cutting functionality) where they would wrap each other one by one; which then results in larger call stacks during routing.
> This also shows to end users when stacktraces is being logged etc, as they tend to be a bit longer with many internal calls.
> Though the JVM optimizes this at runtime as it can inline the calls and whatnot. But the stacktraces is still shown expanded.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira