Seems to be working great - thanks!
Marko
Justin Bertram wrote:
> I believe you should just need to specify a non-zero value for
reconnectAttempts, e.g.:
>
>
ActiveMQClient.createServerLocator("tcp://myhost:61616?reconnectAttempts=10");
>
> Or you can invoke setReconnectAttempts() on the Server
Hi, we also encountered the ClassCastException from
AbstractStoreCursor.fillBatch() method. We're running ActiveMQ 5.13.3 on
linux RedHat 7.2, and the persistent dataDirectory points to a Windows
Server 2012. I attached the debugger to catch the exception. Below is the
screenshot. I hope this p
I believe you should just need to specify a non-zero value for
reconnectAttempts, e.g.:
ActiveMQClient.createServerLocator("tcp://myhost:61616?reconnectAttempts=10");
Or you can invoke setReconnectAttempts() on the ServerLocator object before you
use it.
There's a couple of other parameters
Hi,
How do I get an Artemis client session to automatically reconnect after a
transient network disconnect or a server restart?
Messages are consumed using the Artemis Core API message handler, so
consumer processes are long-running and only create an Artemis client
session at startup.
Currently,
If you publish to a queue without any consumers using that code, you can
then browse the messages via the web console to see if they have the
JMSExpiration header set. If not, the question is why it's not getting set
by your producer code. If it is set, then the question is why the broker
isn't a
Also, the process your analyzing is the JVM itself. If Task Manager and
Process Explorer show a leak but Yourkit Profiler, JConsole, or JVisualVM
do not, then the leak is in the JVM, and you'd need to direct your question
to the maker of whichever JRE you're using.
Tim
On Oct 20, 2016 11:36 AM,
