[CONF] Apache Camel: Camel 2.x Speed optimizations (page created)

Camel 2.x Speed optimizations

This design page is about how to optimize and make Camel 2.x more performant.

Reduce Exchange copying

The first issue to address is to reduce the need for copying exchanges.

Currently Camel does defensive copying of the current Exchange being routed. This happens in org.apache.camel.processor.Pipeline.
This hotspot should be reduced as the Pipeline should not do defensive copy of the Exchange.

Only when redelivering

A defensive copy of the Exchange is only needed when Camel does redelivery using its Error Handler features. So the goal is to move
the defensive copy from the Pipeline to org.apache.camel.processor.RedeliveryErrorHandler. As this error handler is the base for doing redelivery within Camel itself. Then the speed gain is when users do not use this error handler at all.

Optimize RedeliveryErrorHandler

A second goal is to implement logic in RedeliveryErrorHandler to only do defensive copying if a redelivery is possible. End users need to explicit enable redelivery in Camel. By implementing logic if a redelivery is ever possible or not we can reduce the copying even further.

Only copy Message and not Exchange

Another goal is to only copy the IN message as its the input to a processor, and where the processor can mutate it. So instead of copying the entire Exchange we can reduce it to only copying the IN message. This enforces the convention that Exchange properties will not be copied.

Not many processors can mutate IN message

Many of the processors (eg transports, protocols etc.) do not mutate/modify the IN message so we can leverage this fact that a copy is only needed in some situations. For instance the File producer do not mutate the IN message so we do not need to copy it even if we do redelivery.

Logic can be build in to cater for this. For instance:

• Some interface to indicate whether a Processor can mutate or not.
• .process can mutate (you get access to the entire Exchange)
• .bean can mutate (only in some situations)
• we can allow end users to indicate whether they mutate the exchange or not
• we can let end users set a flag on the exchange if it was mutated
• we can add some proxy if getBody/setBody getHeader/setHeader was invoked on IN message to indicate if it was possible to mutate it

We dont have to go all the way, by having just all the Camel component/processors being able to indicate whether they can mutate or not is a big win.
The optimizations of bean/process can be secondary objective as it can be a bit overkill and complex.

Using YourKit profiler

We should use a profiler to aid find hotspots to optimize.

Performance tests

We should have some performance tests we can run and see what we archive.