This documentation is for older WSO2 products. View documentation for the latest release.
Page Comparison - Clustering the Gateway (v.12 vs v.13) - Clustering Guide 4.2.0 - WSO2 Documentation

Versions Compared


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


  1. Open the <GATEWAY_WORKER_HOME>/repository/conf/axis2/axis2.xml file.
  2. Locate the clustering section and verify or configure the properties as follows (some of these properties are already set correctly by default):
    1. Enable clustering for this node: 
      <clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="true">
    2. Set the membership scheme to  wka  to enable the Well Known Address registration method (this node will send cluster initiation messages to WKA members that we will define later): 
      <parameter name="membershipScheme">wka</parameter>
    3. Specify the name of the cluster this node will join: 
      <parameter name="domain"></parameter>
    4. Specify the host used to communicate cluster messages. This is the IP address of the Gateway worker.
      <parameter name="localMemberHost"></parameter> 

    5. Specify the port used to communicate cluster messages (if this node is on the same server as the ELB, manager the manager node, or another worker node, be sure to set this to a unique value, such as 4000 and 4001 for worker nodes 1 and 2). 
      <parameter name="localMemberPort">4200</parameter>


      This port number will not be affected by the port offset in carbon.xml. If this port number is already assigned to another server, the clustering framework will automatically increment this port number. However, if two servers are running on the same machine, you must ensure that a unique port is set for each server.

    6. Define the sub-domain as worker by adding the following property under the  <parameter name="properties">  element: 
      <property name="subDomain" value="worker"/>
    7. Define the manager and worker nodes as well-known members of the cluster by providing their host name and localMemberPort values. The manager node is defined here because it is required for the Deployment Synchronizer to function in an efficient manner. The deployment synchronizer uses this configuration to identify the manager and synchronize deployment artifacts across the nodes of a cluster.

      Code Block

      it is recommended to add at least two well-known members here. This is done to ensure that there is high availability for the cluster.

      You can also use IP address ranges for the hostName. For example, This should ensure that the cluster eventually recovers after failures. One shortcoming of doing this is that you can define a range only for the last portion of the IP address. You should also keep in mind that the smaller the range, the faster the time it takes to discover members, since each node has to scan a lesser number of potential members.