Hi I created a ticket to not forget https://issues.apache.org/jira/browse/CAMEL-15587
I wonder if you would add a readme.txt file to your sample code with some instructions about this and how to run, and capture data etc, so others can also take a look. And where you think there is some bottleneck. On Mon, Sep 21, 2020 at 2:23 PM Andrea Cosentino <anco...@gmail.com> wrote: > > Thanks a lot! > > Il giorno lun 21 set 2020 alle ore 14:22 Denis Chirov > <denis.chi...@computaris.com.invalid> ha scritto: > > > Hi, > > > > The sample and a Java Flight recording were uploaded on GitHub: > > https://github.com/dchirov/camel-performance-sample.git > > > > Best Regards, Denis > > > > -----Original Message----- > > From: Claus Ibsen <claus.ib...@gmail.com> > > Sent: Saturday, September 19, 2020 6:28 PM > > To: users@camel.apache.org > > Subject: Re: Performance regression with bean and ognl expressions in > > Simple language version 3.4.x > > > > Hi > > > > Many things have changed of course when you go from a major version v2 to > > v3. > > Can you put together a very small example application that can run > > standalone that can be used to reproduce the issue. And if it can run > > outside Spring Boot with just a basic public static void main then its > > maybe even easier. > > > > And then put the sample somewhere like on github or create a JIRA ticket > > and attach as .zip. > > > > > > On Thu, Sep 17, 2020 at 2:32 AM Corneliu Chitic > > <corneliu.chi...@computaris.com.invalid> wrote: > > > > > > Hi, > > > > > > we've identified a performance regression while running same code with > > Apache Camel 3.4.3 + Spring Boot vs Apache Camel 2.24.2 with Spring > > framework 5.1.9. We've migrated one application to this LTS version and we > > face this impact. > > > The main bottleneck is the synchronized block from: > > org.apache.camel.impl.engine.AbstractCamelContext.resolveLanguage(String). > > The root cause is the time spent to validate Simple expressions when using > > bean language (${bean:name?method=something}) or OGNL like calls to POJO > > methods (${exchangeProperty.pojo.method}). According to the stack traces > > the new version spends time to allocate the bean + full setup of it. > > Blocking times are quite high (average 100ms, max could be ~300ms) and as > > the number of parallel processing threads increases it goes up steadily. > > > > > > Has anything changed in version 3.x (or more precisely 3.4.x)? The > > changelogs and upgrade tutorial didn't suggested anything in this area. > > > Is there any configuration flag that would allow us to switch back to > > version 2.x mode of working for this functionality? > > > > > > We have run repeated trials and have consistent results with both > > versions; we have a project setup to demo this and also some Java Flight > > recordings for comparison. I don't think I can attach anything to this > > maillist, please let me know how I can provide any additional input if > > needed. > > > > > > Thank you, Corneliu > > > This email is subject to Computaris email terms of use: > > > https://www.computaris.com/email-terms-use/ > > > > > > > > -- > > Claus Ibsen > > ----------------- > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > This email is subject to Computaris email terms of use: > > https://www.computaris.com/email-terms-use/ > > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
