Contained Within
Find More DocumentationFeatured Support Resources | Descargar este libro en PDF (1347 KB)
Chapter 9 Java Message Service Load Balancing and FailoverThis 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 ServiceThe 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 ApplicationThe 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 InformationFor 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 ServiceThe 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:
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. Note – 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 IntegrationMQ 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 ServiceWhen 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 ServiceWhen 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 ListA 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. Note – In the Sun Java System Message Queue software, the AddressList property is called imqAddressList. Default JMS HostOne 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 HostsYou can create additional JMS hosts in the following ways:
Connection Pooling and FailoverApplication 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:
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 InflowApplication 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 ServerMQ 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.
|
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:
Navigate to the JMS Hosts node (Configurations > config-name > Java Message Service > JMS Hosts)
Delete the default broker (default_JMS_host).
Select the checkbox next to it, and then click Delete.
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.
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" |
Start the Application Server instances in the cluster.
Create JMS resources on the cluster:
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:
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:
Navigate to the JMS Connection Factories page (Resources > JMS Resources > Connection Factories).
To create each connection factory, click New.
The Create JMS Connection Factory page opens.
For each connection factory, enter JNDI Name (for example jms/MyQcf) and Type, javax.jms.QueueConnectionFactory
Select the cluster from the list of available targets at the bottom of the page and click Add.
Click OK to create the connection factory.
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:
Navigate to the JMS Destination Resources page (Resources > JMS Resources > Connection Factories).
To create each destination resource, click New.
The Create JMS Destination Resource page opens.
For each destination resource, enter JNDI Name (for example jms/MyQueue) and Type javax.jms.Queue.
Select the cluster from the list of available targets at the bottom of the page and click Add.
Click OK to create the destination resource.
Deploy the applications with the – retrieve option for application clients. For example:
asadmin deploy --target cluster1 --retrieve /opt/work/MQapp/mdb-simple3.ear |
Access the application and test it to ensure it is behaving as expected.
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.
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