[
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/30/13 12:34 PM:
--------------------------------------------------------------
Things to do:
1. Naming the API is hard so the names is not set in stone. (*done*)
2. Passing state from before -> after, is the current approach fine? *(done)*
(yes this works well)
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? (*done*) (keep in one class = easy overview, and classes is
internal only)
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 (*done*)
7. Look at DefaultChannel and see if we should merge/migrate it with this new
stuff. *(done)* (now DefaultChannel extends CamelInternalProcessor)
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. *(for camel 3.0)*
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*)
11. Migrate UnitOfWorkProcessor to CamelInternalProcessor, and remove these
classes when no longer needed (*done*)
12. for direct derived classes of AsyncDelegateProcessor, replace
super.process(exchange, callback) with processor.process(exchange, callback) as
it avoids a useless method call (*done*)
13. on wrap when really needed in Policy / Transaction Definition (*done*)
14. optimize WrapProcessor to avoid using AsyncProcessorHelper when wrapped
processor is not asynchronous. (*only partially possible*)
15. optimize InstrumentationProcessor to detect if target processor is Async or
Sync, and call it directly and accordingly (this avoids the bridge) (*done*)
16. RedeliveryErrorHandler can avoid the processErrorHandler method and reduce
one stack-frame (*done*)
17. When calling a Processor using process then we should optimize that for
sync vs async and be able to drop 1 frame by avoiding the bridge when in sync
mode. (*done*)
18. fix the remaining processors not implementing AsyncProcessor to avoid
wrapping (SetBody, Transform, Aggregate, Marshall ...) (*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? *(done)*
(yes this works well)
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. *(done)* (now DefaultChannel extends CamelInternalProcessor)
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. *(for camel 3.0)*
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*)
11. Migrate UnitOfWorkProcessor to CamelInternalProcessor, and remove these
classes when no longer needed (*done*)
12. for direct derived classes of AsyncDelegateProcessor, replace
super.process(exchange, callback) with processor.process(exchange, callback) as
it avoids a useless method call (*done*)
13. on wrap when really needed in Policy / Transaction Definition (*done*)
14. optimize WrapProcessor to avoid using AsyncProcessorHelper when wrapped
processor is not asynchronous. (*only partially possible*)
15. optimize InstrumentationProcessor to detect if target processor is Async or
Sync, and call it directly and accordingly (this avoids the bridge) (*done*)
16. RedeliveryErrorHandler can avoid the processErrorHandler method and reduce
one stack-frame (*done*)
17. When calling a Processor using process then we should optimize that for
sync vs async and be able to drop 1 frame by avoiding the bridge when in sync
mode. (*done*)
18. fix the remaining processors not implementing AsyncProcessor to avoid
wrapping (SetBody, Transform, Aggregate, Marshall ...) (*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
