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
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
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
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
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
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
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
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.
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
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
>
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
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
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
13 matches
Mail list logo