ActiveMQ consumer remains after shutdown
I have routes defined in an OSGi bundle. The routes use activemq component to process data. To be exact, I have camel listen into 3 different queue with concurrency = 10. As I started it in servicemix (apache-servicemix-4.4.0-fuse-00-27), I see in the Active MQ Web console that the queues are consumed as expected: - queue.a = 10 concurrent consumers - queue.b = 10 concurrent consumers - queue.c = 10 concurrent consumers Without doing any transaction, I stop the bundle. But strangely I have the following fact: - queue.a = 10 concurrent consumers - queue.b = 9 concurrent consumers - queue.c = 1 concurrent consumers where I expect all of them to be 0 concurrent consumers. This is a big problem, since when I start the bundle back, it creates more than 10 concurrent consumers for each queue. And my transaction can not run properly, because the old consumers (which remains), interfere the transaction messages. My question is, what's wrong here? Is a bug? Or I should do something to make it as expected? FYI, this is my ActiveMQ log level = INFO on Servicemix: http://pastebin.com/AcgQApDK Thanks -- ~The best men are men who benefit to others http://www.michsan.web.id 一緒に勉強しましょう! Yang berkualitas memang beda rasanya! http://rizqi-cookies.com
Re: ActiveMQ consumer remains after shutdown
If you use a connection pool then make sure that this pool is also shutdown when you stop the bundle. eg usually that is to ensure the pool start|stop methods is invoked. See details at: http://camel.apache.org/activemq On Fri, Jan 3, 2014 at 12:07 PM, Muhammad Ichsan ich...@gmail.com wrote: I have routes defined in an OSGi bundle. The routes use activemq component to process data. To be exact, I have camel listen into 3 different queue with concurrency = 10. As I started it in servicemix (apache-servicemix-4.4.0-fuse-00-27), I see in the Active MQ Web console that the queues are consumed as expected: - queue.a = 10 concurrent consumers - queue.b = 10 concurrent consumers - queue.c = 10 concurrent consumers Without doing any transaction, I stop the bundle. But strangely I have the following fact: - queue.a = 10 concurrent consumers - queue.b = 9 concurrent consumers - queue.c = 1 concurrent consumers where I expect all of them to be 0 concurrent consumers. This is a big problem, since when I start the bundle back, it creates more than 10 concurrent consumers for each queue. And my transaction can not run properly, because the old consumers (which remains), interfere the transaction messages. My question is, what's wrong here? Is a bug? Or I should do something to make it as expected? FYI, this is my ActiveMQ log level = INFO on Servicemix: http://pastebin.com/AcgQApDK Thanks -- ~The best men are men who benefit to others http://www.michsan.web.id 一緒に勉強しましょう! Yang berkualitas memang beda rasanya! http://rizqi-cookies.com -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen Make your Camel applications look hawt, try: http://hawt.io
Re: ActiveMQ consumer remains after shutdown
My question is: is it true that CachingConnectionFactory causes problem in Camel OSGi environment? On Jan 3, 2014 7:21 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Jan 3, 2014 at 1:18 PM, Muhammad Ichsan ich...@gmail.com wrote: I'm using org.springframework.jms.connection.CachingConnectionFactory instead of org.apache.activemq.pool.PooledConnectionFactory. Is that problem? If you are using blueprint, then yeah you need to call its start|stop method also - the method names may be destroy / init or whatever, so you need to check that out. If you use spring xml file, then spring automatic should call its start|stop methods. But in blueprint this does not happen. While using org.apache.activemq.pool.PooledConnectionFactory with proper start and stop (init-method=start destroy-method=stop), I have no problem. On Fri, Jan 3, 2014 at 6:32 PM, Claus Ibsen claus.ib...@gmail.com wrote: If you use a connection pool then make sure that this pool is also shutdown when you stop the bundle. eg usually that is to ensure the pool start|stop methods is invoked. See details at: http://camel.apache.org/activemq On Fri, Jan 3, 2014 at 12:07 PM, Muhammad Ichsan ich...@gmail.com wrote: I have routes defined in an OSGi bundle. The routes use activemq component to process data. To be exact, I have camel listen into 3 different queue with concurrency = 10. As I started it in servicemix (apache-servicemix-4.4.0-fuse-00-27), I see in the Active MQ Web console that the queues are consumed as expected: - queue.a = 10 concurrent consumers - queue.b = 10 concurrent consumers - queue.c = 10 concurrent consumers Without doing any transaction, I stop the bundle. But strangely I have the following fact: - queue.a = 10 concurrent consumers - queue.b = 9 concurrent consumers - queue.c = 1 concurrent consumers where I expect all of them to be 0 concurrent consumers. This is a big problem, since when I start the bundle back, it creates more than 10 concurrent consumers for each queue. And my transaction can not run properly, because the old consumers (which remains), interfere the transaction messages. My question is, what's wrong here? Is a bug? Or I should do something to make it as expected? FYI, this is my ActiveMQ log level = INFO on Servicemix: http://pastebin.com/AcgQApDK Thanks -- ~The best men are men who benefit to others http://www.michsan.web.id 一緒に勉強しましょう! Yang berkualitas memang beda rasanya! http://rizqi-cookies.com -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen Make your Camel applications look hawt, try: http://hawt.io -- ~The best men are men who benefit to others http://www.michsan.web.id 一緒に勉強しましょう! Yang berkualitas memang beda rasanya! http://rizqi-cookies.com -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen Make your Camel applications look hawt, try: http://hawt.io