camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-6377) Optimize routing engine to reduce stack frames in use during routing and reduce callbacks
Date Tue, 21 May 2013 09:05:16 GMT

    [ 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

Mime
View raw message