camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: BeanInfo performance issues
Date Tue, 05 Feb 2013 12:17:21 GMT
On Tue, Feb 5, 2013 at 8:40 AM, Antoine DESSAIGNE
<> wrote:
> Hi,
> I opened nabble and the archive in order to see if my message went through.
> It was the case but the attachment was removed. So you can find the patch
> right here:
> Have a nice day,

Hi Antonie

Thanks for sharing this.
I suggest to log a JIRA ticket with an improvement and attach your
code to the JIRA.
This is how ASF can accept contributions.

That said, caching is always comes with a price.
In a dynamic environment classes can come and go, and thus you would
need to keep your caches with weak references,
or a way to unload class types, so classloaders dont get stuck.

But having the JIRA allows us to take a look at this and find a better
caching solution.
We do have a LRUSoftCache in Camel that may be a better fit.

> Antoine.
> 2013/2/4 Antoine DESSAIGNE <>
>> Hi everyone,
>> We use Camel 2.10.3 in order to integrate our software with other products.
>> We noticed performance issues with Simple expressions like ${body[name]}
>> so we tried to analyse the root cause. It looks like a lot of BeanInfo
>> instances are created but for the same class type. Since each creation
>> introspects the underlying type, we end up introspecting the same class
>> over and over.
>> In order to see if our assessment was right we created some BeanInfo cache
>> in the Registry (because we didn't know where to put it).
>> In order to get some benchmarks we tried the following thing: execute a
>> loop that performs an evaluation 10000 times. We took the average of 5
>> executions without the first one. Here are the results:
>> ${body} without the cache: 359ms
>> ${body[name]} without the cache: 12220ms
>> ${body[name]} with the cache: 620ms
>> You'll find attached the patch of camel-core with our cache and test class.
>> It's far from being ready to integrate on the trunk because there is so
>> much we don't know:
>> * What are the concurrency issues with BeanInfo ?
>> * Is it a good idea to cache the BeanInfo instances ?
>> * If the cache is a good idea, what's the best place to put it ? what's
>> the right caching level (inside BeanInfo or outside) ?
>> Thanks a lot for your replies on this subject,
>> Have a nice day,
>> Antoine.

Claus Ibsen
Red Hat, Inc.
FuseSource is now part of Red Hat
Twitter: davsclaus
Author of Camel in Action:

View raw message