Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.218.168 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=eBNcD2Du8WHi52fBRmXI22QtM7TKRNpf6VKN5dEypXCyRC2fkdO81ECyLZWOscWclW
         d6D2XMcxpMUvOHbCDpCRV9MKZxVFfRRFJBpKgSMLF60J270ghXv+9ZBKx9msZ4nZqvrR
         5yCKeFhcoHoekN/studH7M3Skgm4bQ2vFUPGE=
MIME-Version: 1.0
In-Reply-To: <22291841.post@talk.nabble.com>
References: <22291841.post@talk.nabble.com>
Date: Mon, 2 Mar 2009 18:08:43 +0100
Message-ID: <5380c69c0903020908w7f632fc6l1f1e15d659df79@mail.gmail.com>
Subject: Re: Performance and MessageSupport.getBody (1.6.0)
From: Claus Ibsen <claus.ibsen@gmail.com>
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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/