camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel 2.0 - About type converter degrade performance issue
Date Wed, 18 Mar 2009 11:22:34 GMT

Any thoughts on this one?

It all boils down to a suggestion to add 1 methods to the
org.apache.camel.Message API

new method:
- tryGetBody(Class type)

or overload existing with a boolean to indicate ignore exception and return null
- getBody(Class, true)

The same applies for the org.apache.camel.spi.TypeConverter interface
as we need a method
on the line as above

new method:
- tryConvertTo(Class type)

or overload existing with a boolean to indicate ignore exception and return null
- convertTo(Class, true)

The boolean thing is maybe a nice one as it have the same method name.

On Mon, Mar 16, 2009 at 7:32 AM, Claus Ibsen <> wrote:
> Hi
> In Camel 1.6.0 and 2.0 we have had a performance issue that could
> seriously degrade performance by x2-x10 when you did stress test by
> sending > 1000 msg/sec.
> The cause of this is the TypeConverter that will throw a
> NoSuchTypeConverterExists when Camel cannot converter to the desired
> type.
> We do this internally in Camel in some areas of the code where we will
> ignore this exception and eg. continue.
> We did a fix for this performance issue in the stream cache but this
> was just a fix in once place. Lately this issue surfaced again in
> camel-mina when using UDP.
> So I have been experimenting with doing a fix once for all.
> I suggest to:
> - add 2 new methods to TypeConverter that returns *null* instread of
> throwing the NoSuchTypeConverterExists exception.
>  I have named them: tryConvertTo. But maybe there is a better name?
> - add 1 new method on Message to get the body using the try convert to instead.
>  I have named the method: tryGetBody(T). But maybe there is a better name?
> - Use tryGetBody internally in Camel where we today do try ..
> catch(NoSuchTypeConverterExists)
> - Then we can expose the regular getBody(T) for the end users, and let
> it act as it does today by throwing the exception
> - We can also optimize the DefaultTypeConverter to let it look in the
> miss cache first if it have tried to convert this before but could not
> If the tryGetBody, tryConvertTo are you to your liking we can also do:
> - add a new method to TypeConvert: boolean canConvertTo(T, value)
> - add a new method to Message: boolean canGetBody(T, value)
> - then use that method as guard before doing the regular convertTo/getBody
>  But this requires that you always use this as guard, to be sure that
> the NoSuchTypeConverterExists is not thrown
>  And it also requires that we use the miss cache to not do 2x
> convertions, 1 for the boolean check, and then 1 for the actual
> convertion
>  It also requires that the body can be converted multiple times.
> Whether solution 1 or 2 we also need to check the other components and
> fix it internally as well, so we dont have a situation like mina with
> UDP that was affected by the performance drawback.
> In my experiment I have the first solution up and running.
> Any thoughts?
> I will create a JIRA ticket for this one as well so we wont forget it.
> --
> Claus Ibsen
> Apache Camel Committer
> Open Source Integration:
> Blog:

Claus Ibsen
Apache Camel Committer

Open Source Integration:

View raw message