camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paquettd <dan.paque...@lmco.com>
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 <dan.paquette@lmco.com> 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:
>> http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22291841.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Claus Ibsen
> Apache Camel Committer
> 
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> 
> 

-- 
View this message in context: http://www.nabble.com/Performance-and-MessageSupport.getBody-%281.6.0%29-tp22291841p22292939.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message