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
supports the ability to let background threads continue to run and only
break certain threads for debugging.

However, even though you client gets kicked off, it should go into failover
mode and attempt to reconnect once you start running your application
again. It will need a certain amount of time in order to accomplish this,
so hitting Step Over line-by-line debugging won't give it enough time to
reconnect. You don't have to try to reestablish all of the connections
inside of your exception handler. That would be redundant to what the
failover code already does. It just needs processor time in order to do it.

This seems like a debugging issue, and not really a bug in the client.

On Wed, Oct 12, 2016, 6:16 AM Tim Bain <> wrote:

> 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 about the symptoms of the failed reconnect, it might
> be possible for someone to figure out what's causing the behavior and fix
> it.  As always when debugging something with no obvious cause, the more
> detail you can provide, the better the odds of someone figuring out what
> the problem is.
> Also: tell your developers to stop getting coffee while they're debugging!
> The clock is ticking when you hit your first breakpoint, because as you've
> seen, there's a pretty narrow timeout window before the broker declares
> your client dead and disconnects you.  Do your thing and then detach, as
> quickly as you can.
> One technique I use (which might or might not be available in Visual
> Studio; I use Eclipse) is to use custom code in the condition of
> conditional breakpoints that will add a custom log line (to see the value
> of a variable, for example) but then always return false (i.e. don't stop
> at this breakpoint), which lets me add custom logging anywhere I want it
> without causing timeouts.  Obviously there are some technology differences
> between our setups, so YMMV.
> Tim
> On Oct 10, 2016 8:32 AM, "magmasystems" <>
> wrote:
> > 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 NMSException.
> >
> > The pseudo-code for what we are trying to do is below. Let's assume that
> > the
> > developer is working on his own laptop, with a locally-installed single
> > instance of ActiveMQ.
> >
> >     // When initially creating a connection, we set the NMS
> > ExceptionListener handler
> >     this.TheConnection.ExceptionListener += this.OnConnectionException;
> >
> >     // This will get called when we get a break in the connection
> >     public virtual void OnConnectionException(Exception exception)
> >     {
> >       if (exception is NMSException)
> >           this.TryExceptionRepair(exception as NMSException);
> >     }
> >
> >     private void TryExceptionRepair(NMSException nmsException)
> >     {
> >        // This is where we want to try to re-establish connections,
> > sessions, etc
> >     }
> >
> >
> > Let's say that we have a single Connection, a single Session that is
> > associated with the connection, and a number of MessageConsumers and
> > MessageProducers that were created by that Session.
> >
> > Is there a well-known pattern for re-establishing the environment when
> the
> > connection is broker?
> >
> > Also, any advice regarding the URI is welcome.
> >
> > Thanks,
> >
> > Marc
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.
> >
> > Sent from the ActiveMQ - User mailing list archive at
> >

Reply via email to