Mindmajix

Configuring JBoss clustering

JBoss AS comes out of the box with clustering support. There is no all-in-one library that deals with clustering, but rather a set of libraries, which cover different kind of aspects.

he following diagram shows the basic clustering architecture adopted by JBoss AS 7:

Screenshot_36

The backbone of JBoss clustering is the JGroups library, which provides the communication between members of the cluster using a multicast transmission.

The next building block is Infinispan , which handles the consistency of your application across the cluster by means of a replicated and transactional JSR-107 compatible cache.

Configuring the JGroups subsystem

The JGroups API handles the communication between nodes in the cluster using a set of reliable communication protocols. Processes can join a group, send messages to all members or single members, and receive messages from members in the group. The system keeps track of the members in every group, and notifies group members when a
new member joins, or an existing member leaves or crashes.

Member processes of a group can be located on the same host, within the same Local Area Network (LAN), or across a Wide Area Network (WAN). A member can be in turn part of multiple groups.

The following diagram illustrates a detailed view of JGroups architecture :

Screenshot_37

A JGroups process consists basically of three parts, namely the Channel, Building Blocks, and the Protocol Stack.

The Channel is a simple socket-like interface used by application programmers to build reliable group communication applications.

Building Blocks are an abstraction interface layered on top of Channels, which can be used instead of Channels whenever a higher-level interface is required.

The Protocol Stack contains a list of layers protocols, which need to be crossed by the message. A layer does not necessarily correspond to a transport protocol. For example, a layer might take care to fragment the message or to assemble it. What’s important is to understand that when a message is sent, it travels down in the stack, while when it’s received it traces the way back.

For example, in the previous diagram PING protocol would be executed first, then the MERGE2, followed by FD_SOCK, and finally, the FD protocol. Vice versa, when the message is received, it would meet the FD protocol first, then FD_SOCK, up to PING.

As we said, the JGroups API was already used in earlier JBoss AS releases where developers used to define the JGroups channels in a set of specific configuration files. In JBoss AS 7, the JGroups configuration is embedded into the main standalone.xml/domain.xml configuration file, to be precise into the jgroups subsystem.

There you can find the list of available transport stacks; we’ll include here the default
UDP stack that is used for communication between nodes.
<subsystem xmlns=”urn:jboss:domain:jgroups:1.0″ default-stack=”udp”>
<stack name=”udp”>
<transport type=”UDP” socket-binding=”jgroups-udp” diagnosticssocket-
binding=”jgroups-diagnostics”/>
<protocol type=”PING”/>
<protocol type=”MERGE2″/>
<protocol type=”FD_SOCK” socket-binding=”jgroups-udp-fd”/>
<protocol type=”FD”/>
<protocol type=”VERIFY_SUSPECT”/>
<protocol type=”BARRIER”/>
<protocol type=”pbcast.NAKACK”/>
<protocol type=”UNICAST”/>
<protocol type=”pbcast.STABLE”/>
<protocol type=”VIEW_SYNC”/>
<protocol type=”pbcast.GMS”/>
<protocol type=”UFC”/>
<protocol type=”MFC”/>
<protocol type=”FRAG2″/>
<protocol type=”pbcast.STREAMING_STATE_TRANSFER”/>
<protocol type=”pbcast.FLUSH”/>

</stack>
<stack name=”tcp”>
. . . . .
</stack>
</subsystem>

UDP is the default protocol for JGroups and uses multicast (or, if not available, multiple unicast messages) to send and receive messages.

A multicast UDP socket can send and receive datagrams from multiple clients. The interesting and useful feature of multicast is that a client can contact multiple servers with a single packet, without knowing the specific IP address of any of the hosts.

AS 7 migration note

In the AS 5/6 releases, you used to switch between protocol stacks adding to your command line, the property: -Djboss.default.jgroups.stack=tcp One reason why we love AS 7 is that things are much simpler to do. All you have to do is changing the default-stack attribute. For example, you could switch to the TCP protocol with as little change as:
<subsystem xmlns=”urn:jboss:domain:jgroups:1.0″ default-stack=”tcp”>

AS 7 migration note

In the AS 5/6 releases, you used to switch between protocol stacks adding to your command line, the property: -Djboss.default.jgroups.stack=tcp

One reason why we love AS 7 is that things are much simpler to do. All you have to do is changing the default-stack attribute. For example, you could switch to the TCP protocol with as little change as:

<subsystem xmlns=”urn:jboss:domain:jgroups:1.0″ default-stack=”tcp”>

Screenshot_38

Screenshot_39

Customizing the protocol stack

If you want to customize your transport configuration at the lowest level, then you could override the default properties used by JGroups or even the single protocol properties. For example, the following configuration snippet can be used to change the default send or receive buffer used by the JGroups UDP stack:

<subsystem xmlns=”urn:jboss:domain:jgroups:1.0″ default-stack=”udp”>
<stack name=”udp”>
<transport type=”UDP” socket-binding=”jgroups-udp” diagnosticssocket-
binding=”jgroups-diagnostics”>
<property name=”ucast_recv_buf_size”>50000000</property>
<property name=”ucast_send_buf_size”>1280000</property>
<property name=”mcast_recv_buf_size”>50000000</property>
<property name=”mcast_send_buf_size”>1280000</property>
</transport>
. . . . . . . .
</stack>
</subsystem>

Note

To change the send or receive buffer of the UDP-based JGroups channel, it is important to limit the need for JGroups to retransmit messages by limiting UDP datagram loss. However, the actual size of the buffer the OS will provide is limited by OS-level maximums. So, as a rule of thumb, you should always configure your OS to take
advantage of the JGroups’ transport configuration.

If you want to have a look at all the available properties which can be used either at transport level or at the protocol level, consult the JGroups XSD file which is available in the JBOSS_HOME/docs/schema folder of your server distribution.

Configuring the Infinispan subsystem

One of the requisites of a cluster is that data is synchronized across its members so that, in case of failure of a node, the application and its session can continue on other members of the cluster, also known as High Availability . Like JBoss AS 6, the new AS 7 uses Infinispan as the distributed caching solution behind its clustering functionality.

The Infinispan API replaces the earlier JBoss Cache library and can be either used as standalone data-grid platform (using its native implementation), or it can be embedded into the application server. As we are interested in the latter option, we will quickly have a look at its configuration, which is contained within the main standalone ha.xml/domain.xml configuration file.

The following is the backbone of the Infinispan configuration:
<subsystem xmlns=”urn:jboss:domain:infinispan:1.1″ default-cachecontainer=”
cluster”>
<cache-container name=”cluster” default-cache=”default”>
<alias>ha-partition</alias>
<replicated-cache mode=”SYNC” name=”default” batching=”true”>
<locking isolation=”REPEATABLE_READ”/>
</replicated-cache>
</cache-container>
<cache-container name=”web” default-cache=”repl”>
. . . . .
</cache-container>
<cache-container name=”sfsb” default-cache=”repl”

</cache-container>
<cache-container name=”hibernate” default-cache=”local-query”>
. . . . .
</cache-container>
</subsystem>

One of the key differences with the standalone Infinispan configuration is that the AS 7 Infinispan subsystem exposes multiple cache-container elements, while a native Infinispan configuration file contains cache configurations for a single cache container.

Each cache-container element, in turn, contains one or more caching policies, which ultimately define how data is synchronized for that specific cache container. The following caching strategies can be used by cache containers:

Local: The entries are stored on the local node only, regardless of whether a cluster has formed. In this mode, Infinispan is typically operating as a local cache.

Replication: Using this, all entries are replicated to all nodes. In this mode, Infinispan is typically operating as a temporary data store and doesn’t offer an increased heap space.

Distribution: The entries are distributed to a subset of the nodes only. In this mode, Infinispan is typically operating as a data grid providing an increased heap space.

Invalidation: The entries are stored into a cache store (such as a database) only, and invalidated from all nodes. When a node needs the entry, it will load it from a cache store. In this mode, Infinispan is operating as a distributed cache, backed by a canonical data store such as a database.

In the following sections, we will have a look at some cache configurations which are essential to configure your clustered applications properly, such as session caches (the web cache and the sfsb cache) and the hibernate cache.

0 Responses on Configuring JBoss clustering"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.
Course Adviser

Fill your details, course adviser will reach you.