Chapter 4. JEUS MQ Clustering

Table of Contents

4.1. Overview
4.2. Clustering Type
4.2.1. Connection Factory Clustering
4.2.2. Destination Clustering
4.3. How to Use Clustering
4.3.1. Server Configuration
4.3.2. Client Settings for Clustering
4.4. Example
4.4.1. Good JEUS MQ Clustering Practice Example
4.4.2. Bad JEUS MQ Clustering Practice Example

This chapter describes the clustering technology that groups multiple servers together to reduce JEUS MQ server loads and provide seamless services.

4.1. Overview

If you are using a single JEUS MQ server, it has to process too many stored messages or client connections, which increases the network load or server memory usage. This may cause performance degradation or server shutdowns. To prevent these problems, you can add and group JEUS MQ servers to work together like a single server. This process is called JEUS MQ clustering. A clustered server can be accessed by a client as it were a stand-alone server.

For more information, refer to "Chapter 5. JEUS MQ Failover".

4.2. Clustering Type

There are two types of clustering, connection factory clustering and destination clustering.

4.2.1. Connection Factory Clustering

When two or more JEUS MQ servers are clustered, client connections to the servers must be distributed. Because connection factories are used to make the connections between servers and clients, this distribution function must be provided by connection factories. This process is called connection factory clustering.

When a connection is created from a connection factory, the connection is assigned to a server using the round-robin method.

The following figure shows connection factory clustering.

[Figure 4.1] Connection Factory Clustering

Connection Factory Clustering

Note

A JEUS MQ client is connected to one server in the cluster, and the client does not need to be concerned about which server it is connected to.

4.2.2. Destination Clustering

Even if all client connections are distributed by connection factory clustering, messages that a server receives may exceed its capacity and the server may not be able to receive more messages, depending on the processing speed and network conditions.

To prevent this problem, excess messages are moved to the JEUS MQ servers that are holding fewer messages. This process is called destination clustering.

The following figure shows destination clustering.

[Figure 4.2] Destination Clustering

Destination Clustering

4.3. How to Use Clustering

This section describes the configurations required for JEUS MQ clustering.

4.3.1. Server Configuration

JEUS MQ clustering is configured based on JEUS server clustering configurations. For more information about JEUS server clustering, refer to JEUS Domain Guide. "Chapter 5. JEUS Clustering".

JEUS MQ Clustering Configuration Requirements

In the left pane of the main WebAdmin page, click the [Clusters] menu. By navigating from here, you can configure destinations and durable subscribers of JEUS MQ servers that are clustered. The configurations are applied to the servers in the cluster. Since each server has a different address, its connection factory is configured by using the [Servers] menu in the left pane, but all servers must have the same connection factory name.

To set a Destination or a Durable Subscriber in the cluster, go to [Clusters] > [Cluster Names] > [Engine] tab and click [JMS Engine]. The following configuration screen appears. For information about configuring individual Destination or Durable Subscriber, refer to "3.2. Configuring JMS Resources".

[Figure 4.3] Destination Configuration

Destination Configuration


Note

1. For more information about how to add a server to the cluster, refer to JEUS Domain Guide. "5.6.1. Adding a Server to the Cluster".

2. If a destination is set, the destination or durable subscriber settings will be ignored. However, duplicate names must be avoided so that the system can accurately operate.

4.3.2. Client Settings for Clustering

This section describes the client settings required for JEUS MQ clustering. To enable JEUS MQ clustering, the first thing to configure is a connection factory.

There are two types of connection factory clustering in JEUS MQ based on how a connection factory is obtained.

  • Using Clustered Connection Factory

    The clustered connection factory can be used in the same way as described in "2.2.2. Connection Factory", regardless of whether the JEUS MQ server is clustered or not. However, the name of the connection factory must be the same with the name of clustered server as described in Server Configuration section. A client creates only the connection by reusing an already obtained connection factory. The policy for selecting a JEUS MQ server can be set in Connection Factory Configuration, and the current round-robin and random methods are supported.

  • Using JEUS MQ API

    When you are creating a connection factory by using JEUS MQ API, If the JEUS MQ server is clustered, you need to perform an additional task besides those described in "2.2.2. Connection Factory".

    That is, you need to add information about all the clustered servers by using the JeusConnectionFactoryCreator.addBrokerAddress() method as in the following.

    jeus.jms.client.util.JeusConnectionFactoryCreator connectionFactoryCreator =
    new jeus.jms.client.util.JeusConnectionFactoryCreator();
    
    connectionFactoryCreator.setFactoryName("ConnectionFactory");
    connectionFactoryCreator.addServerAddress("192.168.1.2", 9741, <service-name>);
    connectionFactoryCreator.addServerAddress("192.168.1.3", 9741, <service-name>);
    connectionFactoryCreator.addServerAddress("192.168.1.4", 9741, <service-name>);
    
    ConnectionFactory connectionFactory = connectionFactoryCreator.createConnectionFactory();

4.4. Example

This section describes examples of good and bad JEUS MQ clustering practices.

4.4.1. Good JEUS MQ Clustering Practice Example

Suppose that there is an online shop that uses the JEUS MQ for processing product orders.

The orders are implemented as messages. The messages are queued in the JEUS MQ and processed on the business servers, and the JEUS MQ servers are clustered.

The following is an ideal example of a JEUS MQ server cluster. Each business server receives messages from its corresponding JEUS MQ server, and the request messages are evenly distributed to the JEUS MQ servers. If a particular business server processes its requests fast, its JEUS MQ server can clear the queue faster than others. In this case, the JEUS MQ server can receive messages from other JEUS MQ servers through destination clustering and pass them to its business server for processing.

[Figure 4.4] Good JEUS MQ Clustering Practice Example

Good JEUS MQ Clustering Practice Example

4.4.2. Bad JEUS MQ Clustering Practice Example

The following JEUS MQ server clustering configuration may reduce processing efficiency.

[Figure 4.5] Bad JEUS MQ Clustering Practice Example

Bad JEUS MQ Clustering Practice Example

If a JMS client continually reuses a connection with a particular JEUS MQ server, loads can be unevenly distributed across multiple connections causing unnecessary transmission of messages, which can significantly reduce the processing efficiency.