This design page is about how to optimize and make Camel 2.x more performant.
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.
A defensive copy of the Exchange is only needed when Camel does redelivery using its Error Handler features. So the goal is to move
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.
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.
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:
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.
We should use a profiler to aid find hotspots to optimize.
We should have some performance tests we can run and see what we archive.