Consumers to ActiveMQ shotdown but not reconnecting, even when failover is used

hi there, Having a machine running an ActiveMQ (5.5.1) broker. Another machine runs our Camel (2.9.0) context. The connection between the 2 is set exactly as described in *Using connection pooling* in http://camel.apache.org/activemq.html http://camel.apache.org/activemq.html , with the followi

Re: Consumers to ActiveMQ shotdown but not reconnecting, even when failover is used

We noticed that *after an idle period* (around 40 minutes), during which no new message is put in MyQueue, *when finally a message is sent* over the queue, a *SocketException *is reported in the broker's log. We were able to verify this by the second, from examining the producer log, the broker lo

Re: Consumers to ActiveMQ shotdown but not reconnecting, even when failover is used

The broker's *activemq.xml* has the transportConnector set with /uri="tcp://*0.0.0.0*:61616?wireFormat.maxInactivityDuration=0"/. Is 0.0.0.0 a problem? Should it be the actual IP/machine name of the broker? We are not running any other brokers. This configuration never caused problems in the pa

Re: Consumers to ActiveMQ shotdown but not reconnecting, even when failover is used

Miguel, thanks for the reply. I added it to the configuration this way: /failover:(tcp://BROKER:61616*?keepAlive=true*)?jms.useAsyncSend=true&maxReconnectDelay=1000&useExponentialBackOff=false&initialReconnectDelay=1000/, and the application started. I haven't reproduced the problem again (as I s

Re: Consumers to ActiveMQ shotdown but not reconnecting, even when failover is used

And what about the http://activemq.apache.org/tcp-transport-reference.html TCP's keepAlive parameter? When should I use it, if I get the keep alive from the inactivity monitor? SJ -- View this message in context: http://camel.465427.n5.nabble.com/Consumers-to-ActiveMQ-shotdown-but-not-recon

Re: Threads not consuming in parallel

27;t a consumer simply pass a message to a thread from the pool and be done with it, without having to wait for the thread to finish it run?* any thoughts? ShlomiJ -- View this message in context: http://camel.465427.n5.nabble.com/Threads-not-consuming-in-parallel-tp5482274p5482568.html

Concurrent problem with message Body using WireTap

expected. Is there a way to do a deep copy while wireTapping, so that our object is copied and its state is snapshot? Is there a better way of achieving what is described above? thanks ShlomiJ -- View this message in context: http://camel.465427.n5.nabble.com/Concurrent-problem-with-messag

Re: Concurrent problem with message Body using WireTap

hi, see what I've found! The wireTap receives the *onPrepareRef *property, which "/allows you to do any custom logic, such as *deep-cloning* the message payload/". Thanks you Camel 2.8.0! ShlomiJ -- View this message in context: http://camel.465427.n5.nabble.com/Concurre

Re: Camel crashes upon ActiveMQ shutdown

Claus Ibsen-2 wrote > Is Camel embedded in the same JVM as the ActiveMQ The broker service is not embedded in the same JVM. Christian Schneider wrote > You could try to set maxReconnectAttempts to e.g. 2. Then activemq will > try two times and then return to camel. Camel will then also try to >

Re: Camel crashes upon ActiveMQ shutdown

Tomcat A servlet, which is set to be initialized on startup using Tomcat's 1 in web.xml, initiates a singleton. That singleton holds a CamelContext member. This context is initialized exactly as described in my previous post, except for the try/catch (this is simply because that the method in the

WireTap threads number keeps on growing

quot;) Am I using the WireTap wrong? Am I not creating the thread pool correctly? thanks ShlomiJ -- View this message in context: http://camel.465427.n5.nabble.com/WireTap-threads-number-keeps-on-growing-tp5557827p5557827.html Sent from the Camel - Users mailing list archive at Nabble.com.

Re: WireTap threads number keeps on growing

OK, I'm a bit more knowledgeable now... The first issue is that I thought I created a pool of 1 thread. ShlomiJ wrote > ThreadPoolBuilder tpBuilder = new ThreadPoolBuilder(this.context); > ExecutorService wiretapThreadpool = > tpBuilder.poolSize(*1*).maxPoolSize(*1*).maxQueueS

Re: WireTap threads number keeps on growing

try. I would expect executorServiceRef to use the TP it is giving, not create a new TP. It will also allow me to use the registry-key to get hold of the TP and release it. ShlomiJ wrote > ThreadPoolBuilder tpBuilder = new ThreadPoolBuilder(this.context); > ExecutorService wiretapThreadpool = > tpBuil