test

Sun GlassFish Enterprise Server v2.1.1 Deployment Planning Guide

Planning Message Queue Broker Deployment

The Java Message Service (JMS) API is a messaging standard that allows Java EE applications and components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous. The Sun Java System Message Queue, which implements JMS, is integrated with Enterprise Server, enabling you to create components such as message-driven beans (MDBs).

Sun Java System Message Queue (MQ) is integrated with Enterprise Server using a connector module, also known as a resource adapter, as defined by the Java EE Connector Architecture Specification (JCA) 1.5. A connector module is a standardized way to add functionality to the Enterprise Server. Java EE components deployed to the Enterprise Server exchange JMS messages using the JMS provider integrated via the connector module. By default, the JMS provider is the Sun Java System Message Queue, but if you wish you can use a different JMS provider, as long as it implements JCA 1.5.

Creating a JMS resource in Enterprise Server creates a connector resource in the background. So, each JMS operation invokes the connector runtime and uses the MQ resource adapter in the background.

In addition to using resource adapter APIs, Enterprise Server uses additional MQ APIs to provide better integration with MQ. This tight integration enables features such as connector failover, load balancing of outbound connections, and load balancing of inbound messages to MDBs. These features enable you to make messaging traffic fault-tolerant and highly available.

Multi-Broker Clusters

MQ supports using multiple interconnected broker instances known as a broker cluster. With broker clusters, client connections are distributed across all the brokers in the cluster. Clustering provides horizontal scalability and improves availability.

A single message broker scales to about eight CPUs and provides sufficient throughput for typical applications. If a broker process fails, it is automatically restarted. However, as the number of clients connected to a broker increases, and as the number of messages being delivered increases, a broker will eventually exceed limitations such as number of file descriptors and memory.

Having multiple brokers in a cluster rather than a single broker enables you to:

However, having multiple brokers does not ensure that transactions in progress at the time of a broker failure will continue on the alternate broker. While MQ will re-establish a failed connection with a different broker in a cluster, it will lose transactional messaging and roll back transactions in progress. User applications will not be affected, except for transactions that could not be completed. Service failover is assured since connections continue to be usable.

Thus, MQ does not support high availability persistent messaging in a cluster. If a broker restarts after failure, it will automatically recover and complete delivery of persistent messages. Persistent messages may be stored in a database or on the file system. However if the machine hosting the broker does not recover from a hard failure, messages may be lost.

The Solaris platform with Sun Cluster Data Service for Sun Message Queue supports transparent failover of persistent messages. This configuration leverages Sun Cluster’s global file system and IP failover to deliver true high availability and is included with Java Enterprise System.

Master Broker and Client Synchronization

In a multi-broker configuration, each destination is replicated on all of the brokers in a cluster. Each broker knows about message consumers that are registered for destinations on all other brokers. Each broker can therefore route messages from its own directly-connected message producers to remote message consumers, and deliver messages from remote producers to its own directly-connected consumers.

In a cluster configuration, the broker to which each message producer is directly connected performs the routing for messages sent to it by that producer. Hence, a persistent message is both stored and routed by the message’s home broker.

Whenever an administrator creates or destroys a destination on a broker, this information is automatically propagated to all other brokers in a cluster. Similarly, whenever a message consumer is registered with its home broker, or whenever a consumer is disconnected from its home broker—either explicitly or because of a client or network failure, or because its home broker goes down—the relevant information about the consumer is propagated throughout the cluster. In a similar fashion, information about durable subscriptions is also propagated to all brokers in a cluster.

Configuring Application Server to Use Message Queue Brokers

The Enterprise Server’s Java Message Service represents the connector module (resource adapter) for the Message Queue. You can manage the Java Message Service through the Admin Console or the asadmin command-line utility.

MQ brokers (JMS hosts) run in a separate JVM from the Enterprise Server process. This allows multiple Enterprise Server instances or clusters to share the same set of MQ brokers.

In Enterprise Server, a JMS host refers to an MQ broker. The Enterprise Server’s Java Message Service configuration contains a JMS Host List (also called AddressList) that contains all the JMS hosts that will be used.

Managing JMS with Admin Console

In the Admin Console, you can set JMS properties using the Java Message Service node for a particular configuration. You can set properties such as Reconnect Interval and Reconnect Attempts. For more information, see Chapter 4, Configuring Java Message Service Resources, in Sun GlassFish Enterprise Server v2.1.1 Administration Guide.

The JMS Hosts node under the Java Message Service node contains a list of JMS hosts. You can add and remove hosts from the list. For each host, you can set the host name, port number, and the administration user name and password. By default, the JMS Hosts list contains one MQ broker, called “default_JMS_host,” that represents the local MQ broker integrated with the Enterprise Server.

Configure the JMS Hosts list to contain all the MQ brokers in the cluster. For example, to set up a cluster containing three MQ brokers, add a JMS host within the Java Message Service for each one. Message Queue clients use the configuration information in the Java Message Service to communicate with MQ broker.

Managing JMS with asadmin

In addition to the Admin Console, you can use the asadmin command-line utility to manage the Java Message Service and JMS hosts. Use the following asadmin commands:

Java Message Service Type

There are two types of integration between Enterprise Server and MQ brokers: local and remote. You can set this type attribute on the Admin Console’s Java Message Service page.

Local Java Message Service

If the Type attribute is LOCAL, the Enterprise Server will start and stop the MQ broker. When Enterprise Server starts up, it will start the MQ broker specified as the Default JMS host. Likewise, when the Enterprise Server instance shuts down, it shuts down the MQ broker. LOCAL type is most suitable for standalone Enterprise Server instances.

With LOCAL type, use the Start Arguments attribute to specify MQ broker startup parameters.

Remote Java Message Service

If the Type attribute is REMOTE, Enterprise Server will use an externally configured broker or broker cluster. In this case, you must start and stop MQ brokers separately from Enterprise Server, and use MQ tools to configure and tune the broker or broker cluster. REMOTE type is most suitable for Enterprise Server clusters.

With REMOTE type, you must specify MQ broker startup parameters using MQ tools. The Start Arguments attribute is ignored.

Default JMS Host

You can specify the default JMS Host in the Admin Console Java Message Service page. If the Java Message Service type is LOCAL, then Enterprise Server will start the default JMS host when the Enterprise Server instance starts.

To use an MQ broker cluster, delete the default JMS host, then add all the MQ brokers in the cluster as JMS hosts. In this case, the default JMS host becomes the first JMS host in the JMS host list.

You can also explicitly set the default JMS host to one of the JMS hosts. When the Enterprise Server uses a Message Queue cluster, the default JMS host executes MQ-specific commands. For example, when a physical destination is created for a MQ broker cluster, the default JMS host executes the command to create the physical destinations, but all brokers in the cluster use the physical destination.

Example Deployment Scenarios

To accommodate your messaging needs, modify the Java Message Service and JMS host list to suit your deployment, performance, and availability needs. The following sections describe some typical scenarios.

For best availability, deploy MQ brokers and Enterprise Servers on different machines, if messaging needs are not just with Enterprise Server. Another option is to run an Enterprise Server instance and an MQ broker instance on each machine until there is sufficient messaging capacity.

Default Deployment

Installing the Enterprise Server automatically creates a domain administration server (DAS). By default, the Java Message Service type for the DAS is LOCAL. So, starting DAS will also start its default MQ broker.

Creating a new domain will also create a new broker. By default, when you add a standalone server instance or a cluster to the domain, its Java Message Service will be configured as REMOTE and its default JMS host will be the broker started by DAS.

Default Deployment illustrates an example default deployment with an Enterprise Server cluster containing three instances.

Using an MQ Broker Cluster with an Application Server Cluster

To configure an Enterprise Server cluster to use an MQ broker cluster, add all the MQ brokers as JMS hosts in the Enterprise Server’s Java Message Service. Any JMS connection factories created and MDBs deployed will then use the JMS configuration specified.

The following figure illustrates an example deployment with three MQ brokers in an broker cluster and three Enterprise Server instances in a cluster.

Specifying an Application-Specific MQ Broker Cluster

In some cases, an application may need to use a different MQ broker cluster than the one used by the Enterprise Server cluster. Specifying an Application-Specific MQ Broker Cluster illustrates an example of such a scenario. To do so, use the AddressList property of a JMS connection factory or the activation-config element in an MDB deployment descriptor to specify the MQ broker cluster.

For more information about configuring connection factories, see JMS Connection Factories in Sun GlassFish Enterprise Server v2.1.1 Administration Guide. For more information about MDBs, see Using Message-Driven Beans in Sun GlassFish Enterprise Server v2.1.1 Developer’s Guide.

Application Clients

When an application client or standalone application accesses a JMS administered object for the first time, the client JVM retrieves the Java Message Service configuration from the server. Further changes to the JMS service will not be available to the client JVM until it is restarted.