Camel 2.0 - About type converter degrade performance issue

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Camel 2.0 - About type converter degrade performance issue

Claus Ibsen-2
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: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Camel 2.0 - About type converter degrade performance issue

Claus Ibsen-2
Hi

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 <[hidden email]> 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: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
>



--
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Camel 2.0 - About type converter degrade performance issue

William Tam
+1 on overloading methods.

On Wed, Mar 18, 2009 at 7:22 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> 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 <[hidden email]> 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: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
>
Reply | Threaded
Open this post in threaded view
|

Re: Camel 2.0 - About type converter degrade performance issue

Claus Ibsen-2
Hi

I had a chat with James about it, and we came to a conclusion.
See the JIRA for summary.

I am running final unit tests now on the change. Will commit later
today if all passes.



On Wed, Mar 18, 2009 at 2:53 PM, William Tam <[hidden email]> wrote:

> +1 on overloading methods.
>
> On Wed, Mar 18, 2009 at 7:22 AM, Claus Ibsen <[hidden email]> wrote:
>> Hi
>>
>> 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 <[hidden email]> 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: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>



--
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Camel 2.0 - About type converter degrade performance issue

Claus Ibsen-2
Hi

Could you test on the SMX side?

We have changed how the getBody(Class type) behaves. Now it returns
null if it cannot convert.
You should use the getMandatoryBody(Class type) instead if you want to
be sure the payload can be converted.

Maybe it affects the camel-jbi component in SMX.



On Thu, Mar 19, 2009 at 10:37 AM, Claus Ibsen <[hidden email]> wrote:

> Hi
>
> I had a chat with James about it, and we came to a conclusion.
> See the JIRA for summary.
>
> I am running final unit tests now on the change. Will commit later
> today if all passes.
>
>
>
> On Wed, Mar 18, 2009 at 2:53 PM, William Tam <[hidden email]> wrote:
>> +1 on overloading methods.
>>
>> On Wed, Mar 18, 2009 at 7:22 AM, Claus Ibsen <[hidden email]> wrote:
>>> Hi
>>>
>>> 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 <[hidden email]> 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: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
>



--
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Reply | Threaded
Open this post in threaded view
|

Re: Camel 2.0 - About type converter degrade performance issue

Willem.Jiang
Administrator
Hi Claus,

Current servicemix-camel component is still using Camel 1.x.

I just went through the code and found that camel-jbi component uses the
ExchangeHelper.convertToType() to covert the camel message body into a
Source object for JBI to use.
I think it is OK for this change.

willem

Claus Ibsen wrote:

> Hi
>
> Could you test on the SMX side?
>
> We have changed how the getBody(Class type) behaves. Now it returns
> null if it cannot convert.
> You should use the getMandatoryBody(Class type) instead if you want to
> be sure the payload can be converted.
>
> Maybe it affects the camel-jbi component in SMX.
>
>
>
> On Thu, Mar 19, 2009 at 10:37 AM, Claus Ibsen <[hidden email]> wrote:
>> Hi
>>
>> I had a chat with James about it, and we came to a conclusion.
>> See the JIRA for summary.
>>
>> I am running final unit tests now on the change. Will commit later
>> today if all passes.
>>
>>
>>
>> On Wed, Mar 18, 2009 at 2:53 PM, William Tam <[hidden email]> wrote:
>>> +1 on overloading methods.
>>>
>>> On Wed, Mar 18, 2009 at 7:22 AM, Claus Ibsen <[hidden email]> wrote:
>>>> Hi
>>>>
>>>> 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 <[hidden email]> 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: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Camel 2.0 - About type converter degrade performance issue

Claus Ibsen-2
On Thu, Mar 19, 2009 at 4:09 PM, Willem Jiang <[hidden email]> wrote:
> Hi Claus,
>
> Current servicemix-camel component is still using Camel 1.x.
>
> I just went through the code and found that camel-jbi component uses the
> ExchangeHelper.convertToType() to covert the camel message body into a
> Source object for JBI to use.
> I think it is OK for this change.
Good. ExchangeHelper.convertToType() will *now* return null if the
conversion was not possible.
So there are no more exceptions thrown.

If you need to conversion to succeed, then you can use convertToMandatoryType()
that will throw NoTypeConversionAvailableException


>
> willem
>
> Claus Ibsen wrote:
>> Hi
>>
>> Could you test on the SMX side?
>>
>> We have changed how the getBody(Class type) behaves. Now it returns
>> null if it cannot convert.
>> You should use the getMandatoryBody(Class type) instead if you want to
>> be sure the payload can be converted.
>>
>> Maybe it affects the camel-jbi component in SMX.
>>
>>
>>
>> On Thu, Mar 19, 2009 at 10:37 AM, Claus Ibsen <[hidden email]> wrote:
>>> Hi
>>>
>>> I had a chat with James about it, and we came to a conclusion.
>>> See the JIRA for summary.
>>>
>>> I am running final unit tests now on the change. Will commit later
>>> today if all passes.
>>>
>>>
>>>
>>> On Wed, Mar 18, 2009 at 2:53 PM, William Tam <[hidden email]> wrote:
>>>> +1 on overloading methods.
>>>>
>>>> On Wed, Mar 18, 2009 at 7:22 AM, Claus Ibsen <[hidden email]> wrote:
>>>>> Hi
>>>>>
>>>>> 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 <[hidden email]> 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: http://fusesource.com
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>>
>>>>> Open Source Integration: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>>
>>
>>
>>
>
>



--
Claus Ibsen
Apache Camel Committer

Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/