This documentation is for WSO2 Message Broker 3.0.0. View documentation for the latest release.
Due to a known issue do not use JDK1.8.0_151 with WSO2 products. Use JDK 1.8.0_144 until JDK 1.8.0_162-ea is released.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Setting up MB instances in different machines

  1. Download the latest version of MB and extract it into a folder.
  2. Make an exact copy of that folder in three separate machines. Let's assume MB1 is in the machine with IP1, MB2 in the machine with IP2 and MB3 in the machine with IP3.
  3. Start all the above instances by running one of the following commands:
    • <MB_HOME>/bin/wso2server.sh (on Linux) 
    • <MB_HOME>/bin/wso2server.bat (on Windows) 
    All severs will start with port offset 0, which is 5672.

Setting up a WSO2 ESB instance

  1. Start ESB in the default port (port offset 0). This is possible if you used the single machine setup above, as those servers were started with different port offsets. If you are using different machines, use another machine to start WSO2 ESB. Instructions can be found in Configure with WSO2 Message Broker.

    Info

    It is not possible to start multiple WSO2 products with their default configurations simultaneously in the same environment. Since all WSO2 products use the same port in their default configuration, there will be port conflicts.

  2. There is only a single difference to enable failover across the three brokers we have setup. That is when specifying the following:

    Code Block
    connectionfactory.ConnectionFactory
    
    connectionfactory.QueueConnectionFactory
    
    connectionfactory.TopicConnectionFactory

    For example, if you hope to use a single machine MB setup as described above,

    Code Block
    connectionfactory.QueueConnectionFactory = amqp://admin:[email protected]/carbon?failover='roundrobin'&cyclecount='2'&brokerlist='tcp://localhost:5673? retries='5'&connectdelay='30000';tcp://localhost:5674?retries='5'&connectdelay='30000';tcp://localhost:5675?retries='5'&connectdelay='30000''

    If you hope to use the broker setup made across several machines as described above,

    Code Block
    connectionfactory.QueueConnectionFactory = amqp://admin:[email protected]/carbon?failover='roundrobin'&cyclecount='2'&brokerlist='tcp://IP1:5672? retries='5'&connectdelay='30000';tcp://IP2:5672?retries='5'&connectdelay='30000';tcp://IP3:5672?retries='5'&connectdelay='30000''

     The parameters used above are described in detail below:

    Brokerlist option
    Code Block
    brokerlist='<broker url>[;<broker url>]'

    The broker list defines the various brokers that can be used for this connection. A minimum of one broker URL is required. Additional URLs are semi-colon(';') delimited.

    Broker URL format


    Code Block
    <transport>://<host>[:<port>][?<option>='<value>'[&<option>='<value>']]
    OptionDefaultDescription
    retries1The number of times to retry connection to this Broker
    sslfalseUse ssl on the connection
    connecttimeout30000How long in (milliseconds) to wait for the connection to succeed
    connectdelay30000noneHow long in (milliseconds) to wait before attempting to reconnect
    Brokerlist failover option


    Code Block
    failover='<method>[?<options>]'
    MethodDescription
    singlebrokerThis will only use the first broker in the list.
    roundrobinThis method tries each broker in turn.
    nofailover[New in 0.5] This method disables all retry and failover logic.

    The current default is to use the singlebroker method when only one broker is present, and the roundrobin method with multiple brokers. The method value in the URL may also be any valid class on the classpath that implements the FailoverMethod interface.
    Options
    OptionDefaultDescription
    cyclecount1The number of times to loop through the list of available brokers before failure.

Testing the setup

When sending messages to a queue (you can configure SOAP UI to send messages continuously one after the other) using the setup described above, kill MB1. You will notice that failover happens at ESB to the second broker i.e MB2. The logs at the ESB side will indicate that failover occurred. 

If there were any previous messages at MB1, they will not be delivered. 

Usually, the solution for that (and many other problems) is broker clustering. For information on the advantages of clustering and WSO2 Message Broker's support on clustering, see Clustering Message Broker