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
practice are the same thing..."

Also, I'd be cautious about that proxy object layer.  If that layer is
performing reconnections outside the context of breakpoints that mess
things up, it probably means something else is wrong with your
configuration (since the failover transport should be taking care of it
seamlessly for you), and you risk having your proxy object layer mask those
configuration problems.  So I'd recommend including a way to tell when the
proxy layer has to do a reconnect (it should never happen), and if you see
it happening, dig in to why the failover transport isn't doing that for
you.  I'm not saying you shouldn't use it, but monitor it and dig in as
necessary.

Tim

On Wed, Oct 12, 2016 at 2:16 PM, Jim Gomes <jgo...@apache.org> wrote:

> 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 <mad...@quantifisolutions.com>
> wrote:
>
> > 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
> > native MessageConsumers and MessageProducers. When we detect a broker
> > failure, we instantiate a new connection and new sessions, and we
> recreate
> > the MessageConsumers and MessageProducers that the application was using.
> > Not the most elegant solution, but it was accomplished in a few lines of
> > code and seems to work.
> >
> > The most difficult thing to do (which is not too difficult, and only
> > involved finding the correct combination of BindingFlags to use) is to
> copy
> > the listener from the old MessageConsumer to the new MessageConsumer.
> >
> >     var handler = typeof(MessageConsumer).GetField("listener",
> > BindingFlags.DeclaredOnly | BindingFlags.Instance |
> BindingFlags.NonPublic
> > |
> > BindingFlags.GetField).GetValue(nativeMessageConsumer);
> >     newMessageConsumer.Listener += handler;
> >
> > So
> >
> >
> >
> > --
> > View this message in context:
> > http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-
> tp4717704p4717848.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>

Reply via email to