RE: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-10-12 Thread Corneliu Chitic
on't want to start a debate. Maybe it's worth adding a note for others to be aware of the current issue with version 3.(0->5).x? Thank you and regards, Corneliu -Original Message- From: Claus Ibsen Sent: Monday, October 12, 2020 14:31 To: users@camel.apache.org Subject: Re:

Re: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-10-12 Thread Claus Ibsen
ions, not in 3.4.x. > Thank you, Corneliu > > -Original Message- > From: Claus Ibsen > Sent: Monday, October 5, 2020 15:43 > To: users@camel.apache.org > Subject: Re: Performance regression with bean and ognl expressions in Simple > language version 3.4.x >

RE: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-10-12 Thread Corneliu Chitic
APSHOT version if I understood correctly and will post an update. Definitely we won't migrate to 3.6.x, we'll stick to 3.4.x for some time. Thank you, Corneliu -Original Message- From: Claus Ibsen Sent: Monday, October 5, 2020 15:43 To: users@camel.apache.org Subject: Re: Pe

Re: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-10-05 Thread Claus Ibsen
Hi Corneliu Thanks for the reproducer. We have fixed a bunch of stuff and you are welcome to try with SNAPSHOT and do profiling again and report back if you can find improvements too. Or if you dont have time then test again when Camel 3.6.0 comes out later in October On Thu, Sep 17, 2020 at 2:32

Re: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-09-28 Thread Claus Ibsen
b.com/dchirov/camel-performance-sample.git > > > > Best Regards, Denis > > > > -Original Message- > > From: Claus Ibsen > > Sent: Saturday, September 19, 2020 6:28 PM > > To: users@camel.apache.org > > Subject: Re: Performance regression with bea

Re: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-09-21 Thread Andrea Cosentino
; From: Claus Ibsen > 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 vers

RE: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-09-21 Thread Denis Chirov
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 Sent: Saturday, September 19, 2020 6:28 PM To: users@camel.apache.org Subject: Re: Performance regression

Re: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-09-19 Thread Claus Ibsen
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 eve

RE: Performance regression with bean and ognl expressions in Simple language version 3.4.x

2020-09-18 Thread Corneliu Chitic
Hi, I have one correction to do: the difference is between Apache Camel 3.4.3 + Spring Boot 2.3.2 vs Apache Camel 2.24.2 with Spring Boot 2.1.8. Thank you -Original Message- From: Corneliu Chitic Sent: Thursday, September 17, 2020 03:32 To: users@camel.apache.org Subject: Performance re

Re: Performance issue in Camel SFTP component

2017-04-09 Thread Onder SEZGIN
blem. Regards On Mon, Apr 10, 2017 at 8:12 AM, Ayush Dixit wrote: > Hi > > Any luck in solving the problem? > > Regards > Ayush > > -Original Message- > From: Ayush Dixit > Sent: Thursday, April 6, 2017 11:01 AM > To: 'users@camel.apache.org'

RE: Performance issue in Camel SFTP component

2017-04-09 Thread Ayush Dixit
Hi Any luck in solving the problem? Regards Ayush -Original Message- From: Ayush Dixit Sent: Thursday, April 6, 2017 11:01 AM To: 'users@camel.apache.org' Subject: RE: Performance issue in Camel SFTP component Should I raise a JIRA for that? -Original Message- F

RE: Performance issue in Camel SFTP component

2017-04-05 Thread Ayush Dixit
Should I raise a JIRA for that? -Original Message- From: Ayush Dixit Sent: Wednesday, April 5, 2017 1:22 PM To: users@camel.apache.org Subject: RE: Performance issue in Camel SFTP component Hi Claus, Already tried that , See below endpoint configuration . No luck :( to("

RE: Performance issue in Camel SFTP component

2017-04-05 Thread Ayush Dixit
: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Wednesday, April 5, 2017 1:08 PM To: users@camel.apache.org Subject: Re: Performance issue in Camel SFTP component Try with maxMessagesPerPoll to set an upper limit. On Tue, Apr 4, 2017 at 12:10 PM, Ayush Dixit wrote: > > Thanks Claus ,

Re: Performance issue in Camel SFTP component

2017-04-05 Thread Claus Ibsen
April 4, 2017 1:35 PM > To: users@camel.apache.org > Cc: users-subscr...@camel.apache.org > Subject: Re: Performance issue in Camel SFTP component > > Please spend more time to read the documentation and you can find options to > tweak the options to use or not use FTP list etc,

RE: Performance issue in Camel SFTP component

2017-04-05 Thread Ayush Dixit
et) Thanks Ayush -Original Message- From: souciance [mailto:souciance.eqdam.ras...@gmail.com] Sent: Wednesday, April 5, 2017 12:29 PM To: users@camel.apache.org Subject: Re: Performance issue in Camel SFTP component Well, have you transferred the same amount of files with some other FTP cli

Re: Performance issue in Camel SFTP component

2017-04-04 Thread souciance
om: Ayush Dixit > Sent: Tuesday, April 4, 2017 3:40 PM > To: [hidden email] <http:///user/SendEmail.jtp?type=node&node=5796945&i=0> > Cc: '[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5796945&i=1>' <[hidden email] > <http:///user

RE: Performance issue in Camel SFTP component

2017-04-04 Thread Ayush Dixit
@camel.apache.org Cc: 'claus.ib...@gmail.com' Subject: RE: Performance issue in Camel SFTP component Thanks Claus , I've tried stepwise=false in camel producer . No such luck Also, I have tried download=false and useList=false. Still the performance is same. I am referring the

RE: Performance issue in Camel SFTP component

2017-04-04 Thread Ayush Dixit
I can try? Thanks Ayush -Original Message- From: Claus Ibsen [mailto:claus.ib...@gmail.com] Sent: Tuesday, April 4, 2017 1:35 PM To: users@camel.apache.org Cc: users-subscr...@camel.apache.org Subject: Re: Performance issue in Camel SFTP component Please spend more time to rea

Re: Performance issue in Camel SFTP component

2017-04-04 Thread Claus Ibsen
Please spend more time to read the documentation and you can find options to tweak the options to use or not use FTP list etc, and there is also a stepwise option On Tue, Apr 4, 2017 at 9:16 AM, Ayush Dixit wrote: > > > Hi , > > > > > > We have implemented a camel route where we are having camel

Re: Performance puzzle. Slow splitter on object array?

2015-07-22 Thread prem5038
I am also having this issue with Camel Splitter. I am using Splitter to split a List> and direct to another route which would write to file. I found that splitter is taking 7-8 seconds to split each item in the List. select * from emp

Re: Performance puzzle. Slow splitter on object array?

2014-09-24 Thread srinivas_vsk
Have you been able to resolve the slowness, im noticing similar issue splitting a List, Hawtio shows couple of seconds to split Thanks -- View this message in context: http://camel.465427.n5.nabble.com/Performance-puzzle-Slow-splitter-on-object-array-tp5729867p5756978.html Sent from the Camel

Re: Performance degradation on consumer side when switching Camel from 2.11.0 to 2.12.1v

2014-02-13 Thread Claus Ibsen
Hi I have logged a ticket to improve this https://issues.apache.org/jira/browse/CAMEL-7203 On Tue, Feb 11, 2014 at 2:19 PM, Rosen Spasov wrote: > It seems the performance regression is caused by a change triggered due to > this defect: CAMEL-6541

Re: Performance degradation on consumer side when switching Camel from 2.11.0 to 2.12.1v

2014-02-11 Thread Rosen Spasov
It seems the performance regression is caused by a change triggered due to this defect: CAMEL-6541 . The excessive copy of message headers seems to be causing ~10% degradation. Any ideas how to overcome this? -- View this message in context:

Re: Performance impact of using streamCache="true" in a route

2013-11-08 Thread Claus Ibsen
I guess only when the original stream is cached there may be a need for more memory when the conversion undergoes. Though from that point onwards you only keep one representation of the data in-memory. Its just a CachedStream from Camel instead of InputStream. Mind that Camel will overflow big st

Re: Performance impact of using streamCache="true" in a route

2013-11-07 Thread Edwin
Apologies, I should have been more specific on the concerns I have around performance. My route won't be writing any data to disk. I'm more concerned about the impact on the memory footprint of the route while stream cache is enabled. -- View this message in context: http://camel.465427.n5.nab

Re: Performance impact of using streamCache="true" in a route

2013-11-07 Thread Claus Ibsen
Hi Not sure if you can say as there is much of an overhead, as you need to access the data 2 times. And the incoming message is streamed so you can only access it once. So to support the use-case you would have to convert the data into a format you can re-read it. The overhead comes if you spool

Re: Performance degradation on consumer side when switching Camel from 2.11.0 to 2.12.1v

2013-10-30 Thread marioradev
Thanks for the prompt reply. I am going to attach a project that could reproduce the degradation. Will need some time to do such project and isolate it from our current scenario. Regards, Mario. -- View this message in context: http://camel.465427.n5.nabble.com/Performance-degradation-on-consu

Re: Performance degradation on consumer side when switching Camel from 2.11.0 to 2.12.1v

2013-10-28 Thread Raul Kripalani
Hello, The code base of the camel-jms component hasn't varied considerably [1] and I don't outright see any cause why this component would be the culprit of the slowdown. I did spot a change in the JmsHeaderFilterStrategy to introduce the includeAllJMSXProperties option. But this defaults to fals

Re: Performance degradation on consumer side when switching Camel from 2.11.0 to 2.12.1v

2013-10-28 Thread marioradev
Hi, More details about the scenario. We are creating message only once and sent it 50 times. We have an emitter which route is configured from a vm channel to JMS topic. Consumer is receiving messages from this JMS topic. In the original test, emitting is configured with concurrentConsumers=30.

Re: Performance Degradation due to Reverse DNS Lookups

2013-10-25 Thread Claus Ibsen
Hi I logged a ticket to not forget about this https://issues.apache.org/jira/browse/CAMEL-6898 On Tue, Jun 25, 2013 at 11:19 AM, Claus Ibsen wrote: > On Tue, Jun 18, 2013 at 3:39 PM, rouble wrote: >> We already do something similar: >> >> SSLContext ctx = SSLContext.getInstance

Re: Performance degradation on consumer side when switching Camel from 2.11.0 to 2.12.1v

2013-10-24 Thread Claus Ibsen
Hi You should tell more about your Camel application, as Camel has 100s of components so not sure which you use etc, that can possible cause a slowdown in your situation. On Thu, Oct 24, 2013 at 2:40 PM, marioradev wrote: > Hi there. > > Last week we have switched our product to use Apache Cam

Re: Performance difference between Camel spring redis and standalone Jedis

2013-09-09 Thread Christian Müller
May be Jedis is much more faster than Spring Redis? Can you compare these both (without using Camel)? Jedis is Apache license 2.0 [1], so we could offer a component for Jedis too... [1] http://code.google.com/p/jedis/ Best, Christian - Software Integration Specialist Apache Came

Re: Performance Degradation due to Reverse DNS Lookups

2013-06-25 Thread Claus Ibsen
On Tue, Jun 18, 2013 at 3:39 PM, rouble wrote: > We already do something similar: > > SSLContext ctx = SSLContext.getInstance("SSL"); > ctx.init(null, new TrustManager[] { new > TrustAllTrustManager() }, null); > SSLSocketFactory ssf = new SSLSocket

Re: Performance Degradation due to Reverse DNS Lookups

2013-06-18 Thread rouble
We already do something similar: SSLContext ctx = SSLContext.getInstance("SSL"); ctx.init(null, new TrustManager[] { new TrustAllTrustManager() }, null); SSLSocketFactory ssf = new SSLSocketFactory(ctx, SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Re: Performance Degradation due to Reverse DNS Lookups

2013-06-03 Thread Willem jiang
Hi, I'm not sure if setting the dummy implementation of X509HostnameVerifier can resolve the issue. Can you try it to see if it work? -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (

Re: Performance Degradation due to Reverse DNS Lookups

2013-06-03 Thread rouble
In my router configuration I am specifying "https4" - is that what you wanted to know? cheers rouble On Mon, Jun 3, 2013 at 9:59 PM, Willem jiang wrote: > Hi, > > There are lots of http related components can provide the https connection, > it could be helpful if you can tell us which http comp

Re: Performance Degradation due to Reverse DNS Lookups

2013-06-03 Thread Willem jiang
Hi, There are lots of http related components can provide the https connection, it could be helpful if you can tell us which http component you are using. -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://will

Re: Performance puzzle. Slow splitter on object array?

2013-04-01 Thread Christian Müller
To be honest, I don't understand how your body gets splitted... The body which your splitter receives is the GernericPayload object, right? Best, Christian On Tue, Mar 26, 2013 at 10:58 PM, MarkD wrote: > Of course, i'll paste the entire route: > > > > > uri="netty:{{broadcastTmProtoc

Re: Performance puzzle. Slow splitter on object array?

2013-03-26 Thread MarkD
Of course, i'll paste the entire route: ${body} You'll notice this is slightly different to the hawtio diagram. The from seda:udp endpoint which star

Re: Performance puzzle. Slow splitter on object array?

2013-03-26 Thread Christian Müller
Can you share your splitter definition? Best, Christian On Tue, Mar 26, 2013 at 8:31 PM, MarkD wrote: > Hi all, > > We have a very strange performace issue that we think we have narrowed down > to a splitter using the hawtio tool (Which is awesome by the way). > > In the image below the mean pr

Re: Performance problem uploading to remote FTP using Stream

2013-03-15 Thread Claus Ibsen
Hi I added a debug logging that logs how long time it takes to upload the file in Camel 2.11. As well what input stream is being used as source. Though in the trace logging below there is no logs about using a charset, as you upload binary data. Though if you force use a special charset then Came

Re: Performance problem uploading to remote FTP using Stream

2013-03-13 Thread GarethHughes
The only options that I could see on the ftpClient http://commons.apache.org/proper/commons-net//apidocs/org/apache/commons/net/ftp/FTPClient.html to adjust the buffer size are 'setBufferSize' and

Re: Performance problem uploading to remote FTP using Stream

2013-03-13 Thread Claus Ibsen
Hi Not sure if setting a sentBufferSize on the client helps? ftpClient.sentBufferSize=8192 Its -1 by default. Check the API of Commons Net FTP to see if it has any impact. org.apache.commons.net.ftp.FTPClient And maybe there is other options you can set on the ftpClient to speedup upload. Al

RE: Performance issue with Camel JMS publish/subscribe

2011-12-12 Thread RadoslavStoyanov
Hi Sven, Thanks for the hint! We'll investigate further... Thanks once more for the nice assistance! Regards, Rado -- View this message in context: http://camel.465427.n5.nabble.com/Performance-issue-with-Camel-JMS-publish-subscribe-tp5049909p5068422.html Sent from the Camel - Users mailing li

RE: Performance issue with Camel JMS publish/subscribe

2011-12-08 Thread Sven Zethelius
@camel.apache.org Subject: RE: Performance issue with Camel JMS publish/subscribe Hi Sven, Adding the cached factory wrapper increased the performance with 800%! Now I have another issue, when I do threaded send - 10 threads publish to the same endpoint and one consumer - it happens that some of the

RE: Performance issue with Camel JMS publish/subscribe

2011-12-08 Thread RadoslavStoyanov
Hi Sven, Adding the cached factory wrapper increased the performance with 800%! Now I have another issue, when I do threaded send - 10 threads publish to the same endpoint and one consumer - it happens that some of the messages are lost (didn't reach the consumer) - not a big number, but there are

RE: Performance issue with Camel JMS publish/subscribe

2011-12-07 Thread RadoslavStoyanov
Hi Sven, Thanks a lot! This explains the current behavior, I'll try the proposed solution and will give you a feedback if the problem is still present or is solved. Regards, Rado -- View this message in context: http://camel.465427.n5.nabble.com/Performance-issue-with-Camel-JMS-publish-subscribe

RE: Performance issue with Camel JMS publish/subscribe

2011-12-06 Thread Sven Zethelius
From: RadoslavStoyanov [mailto:radoslav.stoya...@softwareag.com] Sent: Tuesday, December 06, 2011 5:54 AM To: users@camel.apache.org Subject: RE: Performance issue with Camel JMS publish/subscribe Hi Sven, This is code snippet of my publish functionality: Producer pro

RE: Performance issue with Camel JMS publish/subscribe

2011-12-06 Thread RadoslavStoyanov
Sorry I mean producer, not publisher -- View this message in context: http://camel.465427.n5.nabble.com/Performance-issue-with-Camel-JMS-publish-subscribe-tp5049909p5052134.html Sent from the Camel - Users mailing list archive at Nabble.com.

RE: Performance issue with Camel JMS publish/subscribe

2011-12-06 Thread RadoslavStoyanov
Hi Sven, This is code snippet of my publish functionality: Producer producer = producers.get(eventTypeID); if(producer == null) { String inChannel = resolveEventTypeToInChannel(eventTypeID);

RE: Performance issue with Camel JMS publish/subscribe

2011-12-05 Thread Sven Zethelius
I suspect you aren't caching the connection/sessions. Try wrapping the connectionfactory with a org.springframework.jms.connection.SingleConnectionFactory or org.springframework.jms.connection.CachingConnectionFactory. In your direct case, you have a persisted connections, and most likely a s

RE: Performance issue

2011-11-09 Thread ebinsingh
Thanks a lot. Yes it is the granularity. I also saw the below in the logs which I guess decreases the performance. What I am doing is 1. reading a file 2. Spliting them using token "\n" 3. Unmarshaling each line using the "|" delimiter (.unmarshal(csv).convertBodyTo(List.class).aggregate(constan

RE: Performance issue

2011-11-07 Thread Sven Zethelius
onwireless.com] Sent: Monday, November 07, 2011 5:51 AM To: users@camel.apache.org Subject: Re: Performance issue Looks like this happens in a random sequence. I passed in 5 files and below are the logs. I guess it's to do with some cpu action like garbage collection. Is there a way to make

Re: Performance issue

2011-11-07 Thread ebinsingh
Looks like this happens in a random sequence. I passed in 5 files and below are the logs. I guess it's to do with some cpu action like garbage collection. Is there a way to make it consistant except for the first read? 2011-11-07 08:45:53,553 INFO [Camel (camel-1) thread #0 - file://C:camelProje

Re: Performance issue

2011-11-05 Thread Claus Ibsen
On Fri, Nov 4, 2011 at 8:37 PM, ebinsingh wrote: > I also tried the below. For some reason tie time taken from printing the > "Starting to process big file" to calling the bean method "parseMarsData" > takes an average of 15 milli seconds. Do you see the 15 millis on the 2nd+ files? > > The in

Re: Performance test ShutdownCompleteAllTasksTest

2011-11-04 Thread alexey-s
Hi. I got it. I changed the timeout to terminate a process. -- View this message in context: http://camel.465427.n5.nabble.com/Performance-test-ShutdownCompleteAllTasksTest-tp4965388p4965898.html Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Performance issue

2011-11-04 Thread ebinsingh
I also tried the below. For some reason tie time taken from printing the "Starting to process big file" to calling the bean method "parseMarsData" takes an average of 15 milli seconds. The input file has 2000 lines of data. I am just passing them as a string to the method "parseMarsData" which do

Re: Performance

2011-01-12 Thread Claus Ibsen
y, 11 January 2011 8:08 AM > To: users@camel.apache.org > Subject: RE: Performance > > Claus, > > I'm using 2.5. I'll pull down the latest and try that. > > Is my understanding correct in that these settings should allow for this > number of concurrent users?

RE: Performance

2011-01-12 Thread Damian Harvey
y, 11 January 2011 8:08 AM To: users@camel.apache.org Subject: RE: Performance Claus, I'm using 2.5. I'll pull down the latest and try that. Is my understanding correct in that these settings should allow for this number of concurrent users? Thanks, Damian. -Original Message--

RE: Performance

2011-01-10 Thread Damian Harvey
2011 1:16 AM To: users@camel.apache.org Subject: Re: Performance What version of Camel do you use? I found an issue in Camel 2.5 with the seda component. There is some special logic if you use the option multipleConsumers which is used to multicast messages to multiple consumers. And this requi

Re: Performance

2011-01-10 Thread Claus Ibsen
What version of Camel do you use? I found an issue in Camel 2.5 with the seda component. There is some special logic if you use the option multipleConsumers which is used to multicast messages to multiple consumers. And this requires thread pool in the work doing that, as its parallel processing t

RE: Performance

2011-01-09 Thread Damian Harvey
ll take it immediately. Regards, Damian. -Original Message- From: Willem Jiang [mailto:willem.ji...@gmail.com] Sent: Monday, 10 January 2011 11:45 AM To: users@camel.apache.org Subject: Re: Performance If you take a look at the SedaConsumer.run()[1] method, you will find it pull the q

Re: Performance

2011-01-09 Thread Willem Jiang
If you take a look at the SedaConsumer.run()[1] method, you will find it pull the queue every second, maybe we could introduce some configuration for it to seda to short the delay. [1]https://svn.apache.org/repos/asf/camel/trunk/camel-core/src/main/java/org/apache/camel/component/seda/SedaCon

Re: Performance issues when using camel-activemq and transactions.

2010-12-13 Thread Ioannis Canellos
Thanks Claus! On Mon, Dec 13, 2010 at 4:53 PM, Claus Ibsen wrote: > Hi > > See also AMQ FAQs > http://activemq.apache.org/should-i-use-transactions.html > > > > On Thu, Dec 9, 2010 at 2:07 PM, Ioannis Canellos > wrote: > > Hi Claus, > > > > Here are the results of the tests I run: > > > > Produ

Re: Performance issues when using camel-activemq and transactions.

2010-12-13 Thread Claus Ibsen
Hi See also AMQ FAQs http://activemq.apache.org/should-i-use-transactions.html On Thu, Dec 9, 2010 at 2:07 PM, Ioannis Canellos wrote: > Hi Claus, > > Here are the results of the tests I run: > > Producer Only:  10msg/sec (transacted=true) / 2800 msg/sec > (transacted=false). > Consumer Only:

Re: Performance issues when using camel-activemq and transactions.

2010-12-09 Thread Ioannis Canellos
Hi Claus, Here are the results of the tests I run: Producer Only: 10msg/sec (transacted=true) / 2800 msg/sec (transacted=false). Consumer Only: 10msg/sec transacted=true) / ~500 msg/sec (transacted=false). The results of the mixed is the ones I initially posted. The difference is so big and I

Re: Performance issues when using camel-activemq and transactions.

2010-12-09 Thread Claus Ibsen
When using transacted=true then the commit is sync, and thus the consumer side is impacted. So you should be able to send as fast as you can. But the consumer side is slower due the begin/commit pair in the transaction is synchronous. If you use camel-jms on the consumer side to consume and proce

Re: Performance issues when using camel-activemq and transactions.

2010-12-09 Thread Ioannis Canellos
I think that when I set "transacted=true" then it ignores the property "useAsyncSend=true" set on the connection factory. I am not sure if those two properties can be used together, but they probably can't and this why I have performance issues. On Tue, Dec 7, 2010 at 3:46 PM, Ioannis Canellos

Re: Performance issues when using camel-activemq and transactions.

2010-12-07 Thread Ioannis Canellos
I will do so. I will also check the tx scenarios described in the "Camel in Action". On Tue, Dec 7, 2010 at 3:36 PM, Claus Ibsen wrote: > Check some of the TX unit tets in camel-jms and compare notes. > > > On Tue, Dec 7, 2010 at 2:20 PM, Ioannis Canellos > wrote: > > Hi Claus, > > > > thanks

Re: Performance issues when using camel-activemq and transactions.

2010-12-07 Thread Claus Ibsen
Check some of the TX unit tets in camel-jms and compare notes. On Tue, Dec 7, 2010 at 2:20 PM, Ioannis Canellos wrote: > Hi Claus, > > thanks for your response. > > I had the luck to watch that webinar and I also have the slides, the do help > in increasing the overall performance. But when I se

Re: Performance issues when using camel-activemq and transactions.

2010-12-07 Thread Ioannis Canellos
Hi Claus, thanks for your response. I had the luck to watch that webinar and I also have the slides, the do help in increasing the overall performance. But when I set transaction=true on the activemq component, the performance can degrade form 2000 msg/sec to 5 msg/sec. Regarding the number of c

Re: Performance issues when using camel-activemq and transactions.

2010-12-07 Thread Claus Ibsen
Ask at AMQ forum as its generally how to optimize and setup AMQ. Also check out maybe some of the webinars by Rob Davies on advanced and high performance AMQ stuff The webinars is avail at fusesource website. And it looks like you only got 1 connection in your pool? maxConnections=1 On Mon, No

Re: Performance issues when using camel-activemq and transactions.

2010-12-07 Thread Ioannis Canellos
Thanks Charles for your response! Even though the links you sent me are indeed useful, they didn't provide a solution to my problem. On Mon, Dec 6, 2010 at 1:54 PM, Charles Moulliard wrote: > > Hi Ioannis, > > Here are some links that could help you : > > > http://fusesource.com/wiki/display/Pro

Re: Performance issues when using camel-activemq and transactions.

2010-12-06 Thread Charles Moulliard
Hi Ioannis, Here are some links that could help you : http://fusesource.com/wiki/display/ProdInfo/FUSE+Message+Broker+Performance+Tuning+Guide http://fusesource.com/collateral/23/ But using persistence really reduces performance on ActiveMq Regards, Charles -- View this message in context:

Re: Performance issues when using camel-activemq and transactions.

2010-12-06 Thread iocanel
Anyone? - Ioannis Canellos http://iocanel.blogspot.com http://iocanel.blogspot.com -- View this message in context: http://camel.465427.n5.nabble.com/Performance-issues-when-using-camel-activemq-and-transactions-tp3284122p3293861.html Sent from the Camel - Users mailing list archive at Na

Re: Performance loss observed when using the ProducerTemplate to send an exchange to an endpoint

2010-06-28 Thread Claus Ibsen
Hi Nick Did you have time to do any profiling or running some tests generating logging output? On Wed, Jun 23, 2010 at 4:43 PM, Claus Ibsen wrote: > Hi > > Maybe you could enable more logging and use that to see if you can > spot an obvious time gap between the two? > > org.apache.camel.impl.Pr

Re: Performance loss observed when using the ProducerTemplate to send an exchange to an endpoint

2010-06-23 Thread Claus Ibsen
Hi Maybe you could enable more logging and use that to see if you can spot an obvious time gap between the two? org.apache.camel.impl.ProducerCache=TRACE org.apache.camel.util.ServiceHelper=TRACE The ServiceHelper logs when producers/consumers etc. is being started stopped. You can also use an

Re: Performance loss observed when using the ProducerTemplate to send an exchange to an endpoint

2010-06-23 Thread NickWK
Hi Claus, Thanks for your quick response. I using WebSphere MQ queues and a SQL Server 2005 database table as my endpoints. I have made a code change this morning to cache the endpoints once they have been created from the CamelContext using: Endpoint endpoint = camelContext.getEndpoint(uri) T

Re: Performance loss observed when using the ProducerTemplate to send an exchange to an endpoint

2010-06-23 Thread Claus Ibsen
Hi Can you show a bit more how you use the template and how you obtain those endpoints. And what kind of endpoints are those? Are you sending to a MQ or the likes? Under the covers the Java DSL uses the same foundation as the template so it ought to be able to run on par in speed. On Wed, Jun 2

Re: Performance - Camel JPA

2010-02-03 Thread Claus Ibsen
Hi On Thu, Feb 4, 2010 at 3:26 AM, vcheruvu wrote: > > We needed near realtime to extract data from old table and persist in new > table in different database for downstream processing. So we are using camel > and java as solution to get something going for now. > > Yes using direct jdbc is idea

Re: Performance - Camel JPA

2010-02-03 Thread vcheruvu
We needed near realtime to extract data from old table and persist in new table in different database for downstream processing. So we are using camel and java as solution to get something going for now. Yes using direct jdbc is ideal. However I still have to map rows to an object. I thought i w

Re: Performance - Camel JPA

2010-02-02 Thread Claus Ibsen
On Tue, Feb 2, 2010 at 6:30 AM, Kevin Jackson wrote: > Hi, > [snip] > >> I have ensured that index are put in place for old table and new table. >> There is no need of second level cache in this scenario. I have used UUID to >> generate unique key when inserting new record. Yet this apps take 30 m

Re: Performance - Camel JPA

2010-02-01 Thread Kevin Jackson
Hi, [snip] > I have ensured that index are put in place for old table and new table. > There is no need of second level cache in this scenario. I have used UUID to > generate unique key when inserting new record. Yet this apps take 30 mins > for 40,000. Indexes on the new table are going to hurt

Re: performance issues with JMS transacted route...

2009-12-03 Thread Claus Ibsen
On Thu, Dec 3, 2009 at 1:27 AM, boday wrote: > > Claus, I tried the following... > > -disabled the message groups > -setup the Spring JmsTransactionManager as follows... > > ... > ActiveMQPrefetchPolicy prefetchPolicy = new ActiveMQPrefetchPolicy(); > prefetchPolicy.setQueuePrefetch(50);   //tried

Re: performance issues with JMS transacted route...

2009-12-02 Thread boday
Claus, I tried the following... -disabled the message groups -setup the Spring JmsTransactionManager as follows... ... ActiveMQPrefetchPolicy prefetchPolicy = new ActiveMQPrefetchPolicy(); prefetchPolicy.setQueuePrefetch(50); //tried 0, 10, 1000, 5000 ActiveMQConnectionFactory connFactory = n

Re: performance issues with JMS transacted route...

2009-12-02 Thread Claus Ibsen
Hi I wonder that JMSXGroupID does affect performance. > amq.setAcknowledgementModeName("AUTO_ACKNOWLEDGE"); That one should be TRANSACTED And there should be a setter for transacted on the AMQ as well. AMQComponent ... setTransacted(true); Use Spring JmsTransactionManager btw Camel in Action,

Re: performance issues with JMS transacted route...

2009-12-01 Thread boday
thanks Claus, that is exactly what I wanted to hear... here is my setup...any advice would be appreciated... JDK 1.6, ServiceMix 3.3.1, Camel 2.0 (patched the /hotdeploy/servicemix-camel.zip) AMQ 5.2 (persistent, small 1k messages, 250+ msg/second, no XA Tx) Jenks AMQ pool 2.1, Spring 2.5.6 htt

Re: performance issues with JMS transacted route...

2009-12-01 Thread Claus Ibsen
Hi Also which version of spring are you using? spring-jms is not really performing well until late 2.5.x versions. There is a bit snippet about caching and spring issues at http://camel.apache.org/jms.html And if using AMQ it has a ton of tuning parameters. prefretch buffer need to be adjusted t

Re: performance issues with JMS transacted route...

2009-12-01 Thread Claus Ibsen
Hi You need to post more details about your JMS and TX setup. Which TX manager are you using? Do you use XA or not. And the JMS broker I assume its AMQ but if not what is it? BTW: The xpath thingy should be faster in 2.1 as we have removed a hotspot which let it perform much better under concurre

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-05 Thread paquettd
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-04 Thread Claus Ibsen
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-04 Thread Claus Ibsen
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-03 Thread Claus Ibsen
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-03 Thread Claus Ibsen
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-03 Thread paquettd
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-03 Thread Willem Jiang
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-03 Thread paquettd
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-02 Thread Claus Ibsen
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

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-02 Thread Willem Jiang
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". >

Re: Performance and MessageSupport.getBody (1.6.0)

2009-03-02 Thread Claus Ibsen
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

  1   2   >