Re: ActiveMQ NMS and Failure Recovery

That's a great idea! -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717873.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ NMS and Failure Recovery

I think you may be able to remove a lot of your exception handling code if you turn on failover:. It's so universal, I'm almost tempted to propose making it the default, and you would have to say nofailover: if you didn't want it. On Thu, Oct 13, 2016 at 8:53 AM magmasystems

Re: ActiveMQ NMS and Failure Recovery

Thanks, Jim. If failover works with a single instance, then I surely did reinvent the wheel :-) -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717869.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ NMS and Failure Recovery

Yes, failover works on a single instance. I think I mentioned that in my first reply. You don't need to list two brokers. You just need to have the failover: keyword in the connection URI. On Thu, Oct 13, 2016, 7:49 AM Tim Bain wrote: > Yes, the failover transport works

Re: ActiveMQ NMS and Failure Recovery

Yes, the failover transport works in all three dialects (Java, .NET, and C++). On Oct 13, 2016 7:08 AM, "magmasystems" wrote: > Thanks guys. As I mentioned, the devs tend to do stuff on their laptops > without running multiple instances of ActiveMQ. They basically

Re: ActiveMQ NMS and Failure Recovery

Thanks guys. As I mentioned, the devs tend to do stuff on their laptops without running multiple instances of ActiveMQ. They basically go to the ActiveMQ directory, run the activemq.bat file, do some debugging, and then CTRL+C out of ActiveMQ. If there are any patterns or tricks we could use to

Re: ActiveMQ NMS and Failure Recovery

Like Jim, I think that the failover transport should be capable of doing the reconnect for you when debugging (and it's definitely capable of doing it when there isn't a debugger in the mix), but it's possible that this is one of the situations that illustrate the saying, "In theory, theory and

Re: ActiveMQ NMS and Failure Recovery

It seems like you reinvented the wheel a little bit there, but I'm glad you got it to work for you. Cheers! On Wed, Oct 12, 2016, 8:36 AM magmasystems wrote: > Thanks Jim and Tim. I managed to hook up a poor-man's recover mechanism. > Our > application uses a

Re: ActiveMQ NMS and Failure Recovery

Thanks Jim and Tim. I managed to hook up a poor-man's recover mechanism. Our application uses a framework that sits over the various low-level messaging APIs, such ActiveMQ NMS, Tibco EMS .NET client, and the .NET RabbitMQ client. So we actually have thin "proxy objects" sitting on top of the

Re: ActiveMQ NMS and Failure Recovery

Another technique to try when hitting a breakpoint is to not freeze all of your threads. Let the NMS worker threads continue running in the background so they are able to respond to the KeepAlive requests from the broker. Otherwise, your client will be kicked off from the broker. Visual Studio

Re: ActiveMQ NMS and Failure Recovery

As Jim said, the failover transport should ensure that your client reconnects even if the broker disconnects the client due to a breakpoint-induced timeout. If you're able to isolate specific steps or sequences of events that result in that not happening, or to gather more detailed information

Re: ActiveMQ NMS and Failure Recovery

Thanks, Jim. I neglected to add that we are using the failover URI in production. The main problem seems to be around surviving debugging. For instance, I someone is debugging a service, and goes away for a cup of coffee for a few minutes, they will invariably find that the broker has send an

Re: ActiveMQ NMS and Failure Recovery

The first thing I notice is that you haven't actually enabled failover. The connection URI should be based on this: activemq:failover:tcp://hostname:61616 The inclusion of failover: is important. Beyond that, if you break inside of a debugger, you most likely will be disconnected by the broker.