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" <mad...@quantifisolutions.com>
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.
> nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717707.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Reply via email to