Tuesday, February 7, 2012

ActiveMQ: Master/Slave Broker Configuration

This is a followup to my previous post on configuring multiple instances of the ActiveMQ web console into a single instance of Jetty.  In this post I'll show how the pair of brokers were configured to enable them to be highly available in the event that one of the brokers should fail.  The master/slave configuration used in this example is referred to as the Pure Master Slave.  There several different types of master/slave configurations including Shared File System Master Slave and JDBC Master Slave, the latter of which I will look at in a later post.

Pure Master/Slave Configuration

There is not much to configuring a master/slave pair with ActiveMQ, in fact the configuration needed is a single attribute added to the slave broker.  In the slave broker's configuration file (activemq.xml) you will need to add the masterConnectorURI attribute to the broker element as follows:
 <broker xmlns="http://activemq.apache.org/schema/core" masterConnectorURI="tcp://localhost:61616" brokerName="amq1S" dataDirectory="${activemq.base}/data">  

Essentially, all you need is the one attribute above.  However, if you need to provide credentials for the connection, then you can use the following alternative configuration to connect to the master:
   <masterConnector remoteURI="tcp://localhost:61616" userName="User1" password="pass1"/>  

The URI specified should be the connection URI for the master broker.  This allows the slave to make a connection to master as shown below:
  INFO | ActiveMQ 5.5.1-fuse-01-13 JMS Message Broker (amq1S) is starting   
  INFO | For help or more information please see: http://activemq.apache.org/   
  INFO | Connector vm://amq1S Started   
  INFO | Starting a slave connection between vm://amq1S#0 and tcp://localhost:61616   
  INFO | Slave connection between vm://amq1S#0 and tcp://localhost/ has been established.   
  INFO | ActiveMQ JMS Message Broker (amq1S, ID:macbookpro-251a.home-53545-1328657220277-1:1) started  

From the output you can see the slave is aware of the master broker and has made a connection.  This connection allows the slave broker to stay in sync with the master by replicating the master broker's data store.  Once the slave detects the master has failed it will complete it's start up process by starting all it's connectors:
  ERROR | Network connection between vm://amq1S#0 and tcp://localhost/ shutdown: null  
      at java.io.DataInputStream.readInt(DataInputStream.java:375)  
      at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275)  
      at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:228)  
      at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:220)  
      at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:203)  
      at java.lang.Thread.run(Thread.java:680)  
  WARN | Master Failed - starting all connectors  
  INFO | Listening for connections at: tcp://macbookpro-251a.home:62616  
  INFO | Connector openwire Started  

At this point, the slave is knowledgable about all events processed by the master and additional processing can continue without interruption.

The documentation on configuring a pure master slave ActiveMQ instance also contains some optional parameters that you may find useful if you plan to implement this type of master/slave configuration that will ensure the master and slave broker's data stores stay in sync.  Hit the link to see these additional parameters, and how they are used.


Want to give this a try?  Download the latest FuseSource distribution of ActiveMQ.


Configuring a Master/Slave ActiveMQ instance is easy.  With one simple attribute you can create a highly available ActiveMQ messaging platform.


  1. This comment has been removed by the author.

  2. How would you configure master/slave pairs for the client? Would you just specify it using the failover scheme : failover:(tcp://master1:6010,tcp://slave1:6010,tcp://master2:6020,tcp://slave2:6010)?randomize=false

    1. @ Hiral

      Yes, for the client to also sustain a broker or network failover it would also have to be configured with the failover protocol such as: failover(tcp://host1:port,tcp://host2:port,...). This will allow the client to randomly select an active broker. If you specify the ?randomize=false option it will guarantee the order in which the brokers are tried. If none of the brokers are available, the connection will go into a retry mode until it is able to make a connection. This retry strategy is configurable and can be customized using the useExponentialBackOff, backOffMultiplier, maxReconnectAttempts, etc. options.

  3. Hi Jason,

    unfortunately, this configuration was dropped in the version 5.8.

    In this case how would be the Master/Slave setup in this new version using a shared message store?


    Sergio Fantin

  4. Positive site, where did u come up with the information on this posting?I have read a few of the articles on your website now, and I really like your style. Thanks a million and please keep up the effective work. south african brokerage firms

  5. With global interest in cryptocurrency trading at an all-time high, a number of investors are looking to cash in on the ongoing crypto boom that is sweeping the world right now. And even though the market seems to have stabilized over the course of the past few days, many pundits are of the opinion that currencies like Ethereum, XRP, Bitcoin Cash, Litecoin will scale past their ATH values with ease by the end of 2020. Auto crypto bot.