Good news; the 1.6.1-SNAPSHOT release had a big performance impact.
In my benchmarking the mean execution of the test case went from 8.5ms to
around 1ms. This is a great improvement!
I did a little work with the profiler running and I didn't see the issue
with the Exceptions anymore. There are s
Hi Dan
Thank you very much for reporting and doing the detective work of
digging into the codebase and using a probe to detect the hot spot.
I am about to commit a fix that avoids the excessive overhead of the
NoTypeConverterException.
In a simple test sending 1000 messages to a route, I get abo
Hi
I am looking into this now. Its an issue introduced by the StreamCache
eg:
No type converter available to convert from type: java.lang.Integer to
the required type: org.apache.camel.StreamCache with value 1
Will create a ticket and get onto it
On Tue, Mar 3, 2009 at 6:04 PM, Claus Ibsen wrot
Hi
Did we see which type it tries to convert to? You have only said it
throws 10 exceptions but it should log which type it wanted to convert
it to.
That will also help.
On Tue, Mar 3, 2009 at 4:35 PM, Claus Ibsen wrote:
> On Tue, Mar 3, 2009 at 4:19 PM, paquettd wrote:
>>
>> Not only avoiding
On Tue, Mar 3, 2009 at 4:19 PM, paquettd wrote:
>
> Not only avoiding the try..catch but just running through all the reflection
> code over and over again can't be cheap either.
It has a local cache so the lookup will be fast as its a map.
But its the throws .. catch exception that is expensive
Not only avoiding the try..catch but just running through all the reflection
code over and over again can't be cheap either.
willem.jiang wrote:
>
> Maybe we could add some kind of type converter cache to avoid the try
> ... catch work to improve the performance.
>
> Willem
>
> paquettd wrot
Maybe we could add some kind of type converter cache to avoid the try
... catch work to improve the performance.
Willem
paquettd wrote:
> Thank you for trying to help. I'm attaching my config file here. As you can
> see this is a contrived example I made to test performance (I used a similar
> e
Thank you for trying to help. I'm attaching my config file here. As you can
see this is a contrived example I made to test performance (I used a similar
example with some other products).
Essentially what's happening is a String is being sent with the
ProducerTemplate send method; setting the typ
On Tue, Mar 3, 2009 at 1:17 AM, Willem Jiang wrote:
> Hi,
>
> If you don't want the TypeConverter to get invovled , you could use
> MessageSupport.getBody() directly.
Yes I am wondering if he has a .convertBodyTo in the route, so we need
to see this.
Or some other endpoint/producer trying to get
Hi,
If you don't want the TypeConverter to get invovled , you could use
MessageSupport.getBody() directly.
Willem
On Tue, Mar 3, 2009 at 1:43 AM, paquettd wrote:
>
> 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".
>
On Mon, Mar 2, 2009 at 6:43 PM, paquettd wrote:
>
> 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?
Can you show yo
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 wrot
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.findTypeConver
13 matches
Mail list logo
