Re: ActiveMQ NMS and Failure Recovery

2016-10-13 Thread magmasystems
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

2016-10-13 Thread magmasystems
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

2016-10-13 Thread magmasystems
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
get automatic failover out of a single instance, I would love to know about
it. Could you do something like:

failover:(tcp://localhost:61616,tcp://remotehost:61616)

H ... according to
http://activemq.apache.org/failover-transport-reference.html, you should be
able to. But, will that work with ActiveMQ NMS?

-marc



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704p4717859.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: ActiveMQ NMS and Failure Recovery

2016-10-12 Thread magmasystems
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.


Re: ActiveMQ NMS and Failure Recovery

2016-10-10 Thread magmasystems
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.


ActiveMQ NMS and Failure Recovery

2016-10-09 Thread 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=falseamp;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: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-NMS-and-Failure-Recovery-tp4717704.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.