[
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/26/13 10:53 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)*
10. Optimized EIPs which would create wrapped UnitOfWorkProcessor, to use
internal processor task instead (*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 *(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)*
> 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
