Page History

...

You are welcome to checkout the branch and help along with tuning.

Reduce Exchange copying

DONE in Camel 2.8
The first issue to address is to reduce the need for copying exchanges.

...

If IN is immutable it makes redelivery much easier as we just pass in IN yet again.
The code is in org.apache.camel.impl.ImmutableMessage.

Only when redelivering

DONE in Camel 2.8
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

DONE in Camel 2.8
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

WONT FIX
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.

...

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.

...

Claus used YourKit to find the following hot spots:

• type converter to String could be greatly optimized as it tended to go over fallback converters
• recipient list with only 1 element could be avoid to not use a Scanner as creating a Scanner costs performance

Performance tests

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

...