Chapter 30. Configure JGroups
JGroups is the underlying group communication library used to connect Red Hat JBoss Data Grid instances. For a full list of JGroups protocols supported in JBoss Data Grid, see Section A.1, “Supported JGroups Protocols”
30.1. Configure Red Hat JBoss Data Grid Interface Binding (Remote Client-Server Mode)
30.1.1. Interfaces
Red Hat JBoss Data Grid allows users to specify an interface type rather than a specific (unknown) IP address.
link-local: Uses a169.x.x.xor254.x.x.xaddress. This suits the traffic within one box.<interfaces> <interface name="link-local"> <link-local-address/> </interface> <!-- Additional configuration elements here --> </interfaces>site-local: Uses a private IP address, for example192.168.x.x. This prevents extra bandwidth charged from GoGrid, and similar providers.<interfaces> <interface name="site-local"> <site-local-address/> </interface> <!-- Additional configuration elements here --> </interfaces>global: Picks a public IP address. This should be avoided for replication traffic.<interfaces> <interface name="global"> <any-address/> </interface> <!-- Additional configuration elements here --> </interfaces>non-loopback: Uses the first address found on an active interface that is not a127.x.x.xaddress.<interfaces> <interface name="non-loopback"> <not> <loopback /> </not> </interface> </interfaces>
30.1.2. Binding Sockets
Socket bindings provide a method of associating a name with networking details, such as an interface, a port, a multicast-address, or other details. Sockets may be bound to the interface either individually or using a socket binding group.
30.1.2.1. Binding a Single Socket Example
The following is an example depicting the use of JGroups interface socket binding to bind an individual socket using the
socket-binding element.
Example 30.1. Socket Binding
<socket-binding name="jgroups-udp" <!-- Additional configuration elements here --> interface="site-local"/>
30.1.2.2. Binding a Group of Sockets Example
The following is an example depicting the use of Groups interface socket bindings to bind a group, using the
socket-binding-group element:
Example 30.2. Bind a Group
<socket-binding-group name="ha-sockets" default-interface="global"> <!-- Additional configuration elements here --> <socket-binding name="jgroups-tcp" port="7600"/> <socket-binding name="jgroups-tcp-fd" port="57600"/> <!-- Additional configuration elements here --> </socket-binding-group>
The two sample socket bindings in the example are bound to the same
default-interface (global), therefore the interface attribute does not need to be specified.
30.1.3. Configure JGroups Socket Binding
Each JGroups stack, configured in the JGroups subsystem, uses a specific socket binding. Set up the socket binding as follows:
Example 30.3. JGroups UDP Socket Binding Configuration
The following example utilizes UDP automatically form the cluster. In this example the
jgroups-udp socket binding is defined for the transport:
<subsystem xmlns="urn:jboss:domain:jgroups:3.0" default-stack="udp">
<stack name="udp">
<transport type="UDP" socket-binding="jgroups-udp">
<!-- Additional configuration elements here -->
</transport>
<protocol type="PING"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</subsystem>Example 30.4. JGroups TCP Socket Binding Configuration
The following example uses TCP to establish direct communication between two clusters nodes. In the example below node1 is located at 192.168.1.2:7600, and node2 is located at 192.168.1.3:7600. The port in use will be defined by the jgroups-tcp property in the
socket-binding section.
<subsystem xmlns="urn:infinispan:server:jgroups:8.0" default-stack="tcp">
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="TCPPING">
<property name="initial_hosts">192.168.1.2[7600],192.168.1.3[7600]</property>
<property name="num_initial_members">2</property>
<property name="port_range">0</property>
<property name="timeout">2000</property>
</protocol>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2">
<property name="use_mcast_xmit">false</property>
</protocol>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</subsystem>
The decision of UDP vs TCP must be made in each environment. By default JGroups uses UDP, as it allows for dynamic detection of clustered members and scales better in larger clusters due to a smaller network footprint. In addition, when using UDP only one packet per cluster is required, as multicast packets are received by all subscribers to the multicast address; however, in environments where multicast traffic is prohibited, or if UDP traffic can not reach the remote cluster nodes, such as when cluster members are on separate VLANs, TCP traffic can be used to create a cluster.
Important
When using UDP as the JGroups transport, the socket binding has to specify the regular (unicast) port, multicast address, and multicast port.
