Chapter 9 Java Message Service Load Balancing and Failover

This chapter describes how to configure load balancing and failover of the Java Message Service (JMS) for use with the Application Server. It contains the following topics:

• Overview of Java Message Service

• Configuring the Java Message Service

• Connection Pooling and Failover

• Using MQ Clusters with Application Server

Overview of Java Message Service

The Java Message Service (JMS) API is a messaging standard that allows J2EE 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 3 2005Q1 (MQ), which implements JMS, is tightly integrated with Application Server, enabling you to create components such as message-driven beans (MDBs).

MQ is integrated with Application Server using a connector module, also known as a resource adapter, defined by the J2EE Connector Architecture Specification 1.5. J2EE components deployed to the Application Server exchange JMS messages using the JMS provider integrated via the connector module. Creating a JMS resource in Application 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.

You can manage the Java Message Service through the Admin Console or the asadmin command-line utility.

Sample Application

The mqfailover sample application demonstrates MQ failover with a Message Driven Bean receiving incoming messages from a JMS Topic. The sample contains an MDB and a application client. The Application Server makes the MDB highly available. If one broker goes down, the conversational state (the messages received by MDB) is migrated transparently to another available broker instance in the cluster.

The sample is installed to

install_dir/samples/ee-samples/failover/apps/mqfailover

Further Information

For more information on JMS, see Chapter 14, Using the Java Message Service, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide. For more information on connectors (resource adapters), see Chapter 9, Developing Connectors, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide.

For more information about the Sun Java System Message Queue, see the Sun Java System Message Queue documentation. For general information about the JMS API, see the JMS web page

Configuring the Java Message Service

The Java Message Service configuration is available to all inbound and outbound connections to the Sun Java System Application Server cluster or instance. You can configure the Java Message Service with:

• The Administration Console. Open the Java Message Service component under the relevant configuration. For details, see Chapter 4, Configuring Java Message Service Resources, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

• The asadmin set command. You can set the following attributes:

  server.jms-service.init-timeout-in-seconds = 60
  server.jms-service.type = LOCAL
  server.jms-service.start-args =
  server.jms-service.default-jms-host = default_JMS_host
  server.jms-service.reconnect-interval-in-seconds = 60
  server.jms-service.reconnect-attempts = 3
  server.jms-service.reconnect-enabled = true
  server.jms-service.addresslist-behavior = random
  server.jms-service.addresslist-iterations = 3
  server.jms-service.mq-scheme = mq
  server.jms-service.mq-service = jms

  You can also set these properties:

  server.jms-service.property.instance-name = imqbroker
  server.jms-service.property.instance-name-suffix =
  server.jms-service.property.append-version = false

  Use the asadmin getcommand to list all the Java Message Service attributes and properties. For more information on asadmin get, see get(1).  For more information on asadmin set, see set(1).

You can override the Java Message Service configuration using JMS connection factory settings. For details, see Admin Console Tasks for JMS Connection Factories in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

You must restart the Application Server instance after changing the configuration of the Java Message Service.

For more information about JMS administration, see Chapter 4, Configuring Java Message Service Resources, in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide

Java Message Service Integration

MQ can be integrated with Application Server in two ways: LOCAL and REMOTE, represented in Admin Console by the Java Message Service Type attribute.

LOCAL Java Message Service

When the Type attribute is LOCAL (the default for a stand-alone Application Server instances), the Application Server will start and stop the MQ broker specified as the Default JMS host. LOCAL type is most suitable for standalone Application Server instances.

To create a one-to-one relationship between Application Server instances and Message Queue brokers, set the type to LOCAL and give each Application Server instance a different default JMS host. You can do this regardless of whether clusters are defined in the Application Server or MQ.

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

REMOTE Java Message Service

When the Type attribute is REMOTE, the MQ broker must be started separately. This is the default if clusters are defined in the Application Server. For information about starting the broker, see the Sun Java System Message Queue Administration Guide.

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

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

JMS Hosts List

A JMS host represents an MQ broker. The Java Message Service contains a JMS Hosts list (also called AddressList) that contains all the JMS hosts that Application Server uses.

The JMS Hosts list is populated with the hosts and ports of the specified MQ brokers and is updated whenever a JMS host configuration changes. When you create JMS resources or deploy MDBs, they inherit the JMS Hosts list.

In the Sun Java System Message Queue software, the AddressList property is called imqAddressList.

Default JMS Host

One of the hosts in the JMS Hosts list is designated the default JMS host, named Default_JMS_host. The Application Server instance starts the default JMS host when the Java Message Service type is configured as LOCAL.

If you have created a multi-broker cluster in the Sun Java System Message Queue software, delete the default JMS host, then add the Message Queue cluster’s brokers as JMS hosts. In this case, the default JMS host becomes the first one in the JMS Hosts list.

When the Application Server uses a Message Queue cluster, it executes Message Queue specific commands on the default JMS host. For example, when a physical destination is created for a Message Queue cluster of three brokers, the command to create the physical destination is executed on the default JMS host, but the physical destination is used by all three brokers in the cluster.

Creating JMS Hosts

You can create additional JMS hosts in the following ways:

• Use the Administration Console. Open the Java Message Service component under the relevant configuration, select the JMS Hosts component, and then click New. For more information, see To create a JMS host in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

• Use the asadmin create-jms-host command. For details, see create-jms-host(1).

  The JMS Hosts list is updated whenever a JMS host configuration changes.

Connection Pooling and Failover

Application Server supports JMS connection pooling and failover. The Sun Java System Application Server pools JMS connections automatically. When the Address List Behavior attribute is random (the default), Application Server selects its primary broker randomly from the JMS host list. When failover occurs, MQ transparently transfers the load to another broker and maintains JMS semantics.

To specify whether the Application Server tries to reconnect to the primary broker when the connection is lost, select the Reconnect checkbox. If enabled and the primary broker goes down, Application Server tries to reconnect to another broker in the JMS Hosts list.

When Reconnect is enabled, also specify the following attributes:

• Address List Behavior: whether connection attempts are in the order of addresses in the JMS Hosts List (priority) or random order (random). If set to Priority, Java Message Service tries to connect to the first MQ broker specified in the JMS Hosts list and uses another one only if the first broker is not available. If set to Random, Java Message Service selects the MQ broker randomly from the JMS Hosts list. If there are many clients attempting a connection using the same connection factory, use this setting to prevent them from all attempting to connect to the same address.

• Address List Iterations: number of times the Java Message Service iterates through the JMS Hosts List in an effort to establish (or re-establish) a connection). A value of -1 indicates that the number of attempts is unlimited.

• Reconnect Attempts: the number of attempts to connect (or reconnect) for each address in the JMS hosts list before the client runtime tries the next address in the list. A value of -1 indicates that the number of reconnect attempts is unlimited (the client runtime attempts to connect to the first address until it succeeds).

• Reconnect Interval: number of seconds between reconnect attempts. This applies for attempts on each address in the JMS hosts list and for successive addresses in the list. If it is too short, this time interval does not give a broker time to recover. If it is too long, the reconnect might represent an unacceptable delay.

You can override these settings using JMS connection factory settings. For details, see Admin Console Tasks for JMS Connection Factories in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

Load-Balanced Message Inflow

Application Server delivers messages randomly to MDBs having same ClientID . The ClientID is required for durable subscribers.

For non-durable subscribers in which the ClientID is not configured, all instances of a specific MDB that subscribe to same topic are considered equal. When an MDB is deployed to multiple instances of the Application Server, only one of the MDBs receives the message. If multiple distinct MDBs subscribe to same topic, one instance of each MDB receives a copy of the message.

To support multiple consumers using the same queue, set the maxNumActiveConsumers property of the physical destination to a large value. If this property is set, MQ allows up to that number of MDBs to consume messages from same queue. The message is delivered randomly to the MDBs. If maxNumActiveConsumers is set to -1, there is no limit to the number of consumers.

Using MQ Clusters with Application Server

MQ Enterprise Edition supports 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.

This section describes how to configure Application Server to use highly available Sun Java System Message Queue clusters. It explains how to start and configure Message Queue clusters.

For more information about the topology of Application Server and MQ deployment, see Planning Message Queue Broker Deployment in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Deployment Planning Guide.

To Enable MQ clusters with Application Server Clusters

1. Create an Application Server cluster, if one does not already exist.

   For information on creating clusters, see To Create a Cluster.

2. Create an MQ broker cluster.

   First, delete the default JMS host that refers to the broker started by the Domain Administration Server, and then create three external brokers (JMS hosts) that will be in the MQ broker cluster.

   Create a JMS hosts with either the Admin Console or the asadmin command-line utility.

   To use asadmin, the commands are for example:

   asadmin delete-jms-host --target cluster1 default_JMS_host asadmin create-jms-host --target cluster1 --mqhost myhost1 --mqport 6769 --mquser admin --mqpassword admin broker1 asadmin create-jms-host --target cluster1 --mqhost myhost2 --mqport 6770 --mquser admin --mqpassword admin broker2 asadmin create-jms-host --target cluster1 --mqhost myhost3 --mqport 6771 --mquser admin --mqpassword admin broker3

   To create the hosts with Admin Console:

   1. Navigate to the JMS Hosts node (Configurations > config-name > Java Message Service > JMS Hosts)

   2. Delete the default broker (default_JMS_host).

      Select the checkbox next to it, and then click Delete.

   3. Click New to create each JMS host and enter its property values.

      Fill in the values for host name, DNS name or IP address, port number, administrative user name and password.

3. Start the master MQ broker and the other MQ brokers.

   In addition to the three external brokers started on JMS host machines, start one master broker on any machine. This master broker need not be part of a broker cluster. For example:

   /usr/bin/imqbrokerd -tty -name brokerm -port 6772 -cluster myhost1:6769,myhost2:6770,myhost2:6772,myhost3:6771 -D"imq.cluster.masterbroker=myhost2:6772"

4. Start the Application Server instances in the cluster.

5. Create JMS resources on the cluster:

   1. Create JMS physical destinations.

      For example, using asadmin:

      asadmin create-jmsdest --desttype queue --target cluster1 MyQueue asadmin create-jmsdest --desttype queue --target cluster1 MyQueue1

      To use Admin Console:

      1. Navigate to the JMS Hosts page (Configurations > config-name > Java Message Service > Physical Destinations).

      2. Click New to create each JMS physical destination.

      3. For each destination, enter its name and type (queue).

   2. Create JMS connection factories.

      For example, using asadmin:

      asadmin create-jms-resource --target cluster1 --restype javax.jms.QueueConnectionFactory jms/MyQcf asadmin create-jms-resource --target cluster1 --restype javax.jms.QueueConnectionFactory jms/MyQcf1

      To use Admin Console:

      1. Navigate to the JMS Connection Factories page (Resources > JMS Resources > Connection Factories).

      2. To create each connection factory, click New.

         The Create JMS Connection Factory page opens.

      3. For each connection factory, enter JNDI Name (for example jms/MyQcf) and Type, javax.jms.QueueConnectionFactory

      4. Select the cluster from the list of available targets at the bottom of the page and click Add.

      5. Click OK to create the connection factory.

   3. Create JMS destination resources.

      For example, using asadmin:

      asadmin create-jms-resource --target cluster1 --restype javax.jms.Queue --property imqDestinationName=MyQueue jms/MyQueue asadmin create-jms-resource --target cluster1 --restype javax.jms.Queue --property imqDestinationName=MyQueue1 jms/MyQueue1

      To use Admin Console:

      1. Navigate to the JMS Destination Resources page (Resources > JMS Resources > Connection Factories).

      2. To create each destination resource, click New.

         The Create JMS Destination Resource page opens.

      3. For each destination resource, enter JNDI Name (for example jms/MyQueue) and Type javax.jms.Queue.

      4. Select the cluster from the list of available targets at the bottom of the page and click Add.

      5. Click OK to create the destination resource.

6. Deploy the applications with the – retrieve option for application clients. For example:

   asadmin deploy --target cluster1 --retrieve /opt/work/MQapp/mdb-simple3.ear

7. Access the application and test it to ensure it is behaving as expected.

8. If you want to return the Application Server to its default JMS configuration, delete the JMS hosts you created and recreate the default. For example:

   asadmin delete-jms-host --target cluster1 broker1 asadmin delete-jms-host --target cluster1 broker2 asadmin delete-jms-host --target cluster1 broker3 asadmin create-jms-host --target cluster1 --mqhost myhost1 --mqport 7676 --mquser admin --mqpassword admin default_JMS_host

   You can also perform the equivalent operation with Admin Console.

Troubleshooting

If you encounter problems, consider the following:

• View the Application Server log file. If you see in the log file that an MQ broker does not respond to a message, stop the broker and then restart it.

• Always be sure to start MQ brokers first, then Application Server instances.

• When all MQ brokers are down, it takes 30 minutes for Application Server to go down or up, with the default values in Java Message Service. Tune Java Message Service values to get acceptable values for this timeout. For example:

  asadmin set --user admin --password administrator 
  cluster1.jms-service.reconnect-interval-in-seconds=5