On Wed, Jul 13, 2011 at 8:57 AM, lunchbox <[email protected]> wrote: > Hi Claus, > > Thanks for the info. But actually, the route is pulling messages from a JMS > channel if you check my first post on this thread :) > > Also, it will most likely be a co-located or embedded JMS broker, so I think > that will improve the performance quite a bit compared to a remote FTP > server. But yeah, I'll do some testing and see how it all goes. Overall > Camel's performance seems real nice so I'm quite optimistic. > > JMS is not listed in the batch consumer list so I guess that's off. I'm > using context.start/stopRoute, but looking at the other link you posted, > perhaps suspend/resume would be better? >
If you are going to do this more frequently then suspend/resume is more "gentle" as it keeps the connection warm etc. > And, although the JMS consumer is not batched, is there a way to know when > there are no more messages waiting in the queue? I'm using the > ActiveMQComponent if that makes any difference. > You can use JMX API on ActiveMQ to query the queue depth on queues etc. See this FAQ http://activemq.apache.org/how-do-i-find-the-size-of-a-queue.html You can also use the statistic plugin and do a request/reply and get a message back with details about the queue. See this blog: http://rajdavies.blogspot.com/2009/10/query-statistics-for-apache-activemq.html And Camel has an inflight repository which you can query how many in progress messages is from a given endpoint etc http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/InflightRepository.html > Thanks a lot, > Lunchbox > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Scheduled-Polling-Consumer-on-FTP-endpoint-tp472602p4581766.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
