camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paquettd <>
Subject Re: Performance and MessageSupport.getBody (1.6.0)
Date Mon, 02 Mar 2009 17:43:25 GMT

I'm not sure if it makes a difference but I'm not using JMS anywhere. In fact
in this test everything is using "direct".

Is there something I can do in the Spring DSL to hint to Camel that there is
no conversion necessary?

Claus Ibsen-2 wrote:
> On Mon, Mar 2, 2009 at 5:54 PM, paquettd <> wrote:
>> I've been seeing some performance problems with Camel 1.6.0 (I have not
>> tried
>> this with previous versions yet).
>> My profiler is pointing the finger at MessageSupport.getBody,
>> TypeConverter.convertTo, and DefaultTypeConverter.findTypeConverter
>> specifically
>> findTypeConverter is always throwing a
>> NoTypeConversionAvailableException;
>> which is then being caught and ignored in MessageSupport.getBody; at
>> which
>> point processing continues successfully.
> This should be normal in situations where you ask the body to be a
> specific type which cannot be converted to.
> To help this can you show your route and what kind of JMS messages are
> you sending.
> Camel is payload type agnostics (eg dont have to be pure XML etc.) so
> you can send whatever objects you like.
> It has a rich type converter registry to be able to convert seamless
> between types.
> This registry is loaded on demand, so you should make sure your start
> profiling after Camel is "warm".
>> protected <T> T getBody(Class<T> type, Object body) is the specific
>> getBody
>> in question.
>> Is this exception an expected behavior? It's weird how the catch block
>> doesn't even log a warning. Should a converter have been found? My
>> message
>> payload is just a java.lang.String.
> In the old days it returned null, but that did not work as the payload
> you were trying to convert could be null, so it was a catch-22
> situation.
> So we added the exception.
> But if throwing exception is expensive we could maybe add a has test
> to avoid this exception being thrown and caught in the MessageSupport.
> The exception is also meant for end users so they get a good exception
> detailing the problem if they try to convert something into eg,
> MyFooClass and its not possible to convert to it. Instead of returning
> a null value as result.
>> I suspect I've done something wrong but I don't know where to start
>> looking.
>> I'm concerned with this; as I'm comparing Camel to some other message
>> routing solutions. This is making Camel take 40 times longer than the
>> competition and I want to make sure I do a fair comparison.
> We are currently rewamping the internal API in Camel 2.0 that leads us
> up to a point where we can do performance improvements when Camel
> routes exchanges.
> Currently it does a bit of defensive copying when it moves message
> from node to node. The revamped API lets us do some more clever stuff
> there to improve the speed.
> So if you are testing, eg. JMS -> JMS and want it to be really fast
> then of course pure JMS to JMS is faster than eg over Camel as its a
> very flexible and transport/protocol agnostic framework. But
> performance improvements is on our roadmap in 2.1.
>> --
>> View this message in context:
>> Sent from the Camel - Users mailing list archive at
> -- 
> Claus Ibsen
> Apache Camel Committer
> Open Source Integration:
> Blog:

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message