activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gomes <>
Subject Re: ActiveMQ NMS and Failure Recovery
Date Mon, 10 Oct 2016 00:17:01 GMT
The first thing I notice is that you haven't actually enabled failover. The
connection URI should be based on this:


The inclusion of failover: is important.

Beyond that, if you break inside of a debugger, you most likely will be
disconnected by the broker. So I'm not sure what you are asking. Do you
want to survive breakpoints in a debugger, or do you want normal failover
in production?

On Sun, Oct 9, 2016, 9:00 AM magmasystems <>

> Hello all,
> As we prepare to ship our new product that uses ActiveMQ NMS heavily, I am
> trying to harden the code against possible failures. One of the things that
> our developers have noticed (and others in this group may have noticed) is
> that it is common to get NMSExceptions when you are stopped at a breakpoint
> for a while in Visual Studio. The connection is lost, and often times, we
> need to restart our services.
> Our typical connection string is this:
> activemq:tcp://myserver:61616?transport.useInactivityMonitor=false&amp;amp;keepAlive=true
> I have a few questions:
> 1) Let's say that we have a few cached consumers. If a connection faulted,
> and we need to open a new connection, I assume that we also need to create
> new sessions and therefore, create new consumers and producers? Or is there
> any way to take an existing session and associate it with a new connection?
> 2) What are the best patterns for failure recovery, especially when a
> connection goes down because of a "keep-alive" violation? Do we need to
> only
> create a new connection? Do we need to recreate all sessions? Do we need to
> recreate all consumers and producers?
> 3) Are there any other parameters that you feel that I should add to my
> URI?
> I see that there are parameters like:
> wireFormat.maxInactivityDuration (set to either a large number or to -1 ...
> people have tried both)
> maxInactivityDurationInitalDelay
> Thanks very much for any advice.
> -marc
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message