The developer or the administrator can enable automatic reconnection by setting the connection factory imqReconnectEnabled attribute to true. The connection factory administered object must also be configured to specify the following:
A list of message-service addresses (using the imqAddressList attribute). When the client runtime needs to establish or reestablish a connection to a message service, it attempts to connect to the brokers in the list until it finds (or fails to find) an available broker. If you specify only a single broker instance on the imqAddressList attribute, the configuration won’t support recovery from hardware failure.
When you specify more than one broker, you can decide whether to use parallel brokers or a broker cluster. In a parallel configuration, there is no communication between brokers, while in a broker cluster, the brokers interact to distribute message delivery loads. (Refer to Chapter 4, Broker Clusters, in Sun Java System Message Queue 3.7 UR1 Technical Overview for more information on broker clusters.)
To enable parallel-broker reconnection, set theimqReconnectListBehavior attribute to PRIORITY . Typically, you would specify no more than a pair of brokers for this type of reconnection. This way, the messages are published to one broker, and all clients fail over together from the first broker to the second.
To enable clustered-broker reconnection, set the imqReconnectListBehavior attribute to RANDOM. This way, the client runtime randomizes connection attempts across the list, and client connections are distributed evenly across the broker cluster.
Each broker in a cluster uses its own separate persistent store (which means that undelivered persistent messages are unavailable until a failed broker is back online). If one broker crashes, its client connections are reestablished on other brokers.
The number of iterations to be made over the list of brokers (using the imqAddressListIterations attribute) when attempting to create a connection or to reconnect.
The number of attempts to reconnect to a broker if the first connection fails (using the imqReconnectAttempts attribute).
The interval, in milliseconds, between reconnect attempts, using the imqReconnectInterval attribute.
Configure your connection-factory object as follows:
imqobjmgr add -t cf -l "cn=myConnectionFactory" \ -o "imqAddressList=mq://jpgserv/jms" \ -o "imqReconnect=true" \ -o "imqReconnectAttempts=10" |
This command creates a connection-factory object with a single address in the broker address list. If connection fails, the client runtime will try to reconnect with the broker 10 times. If an attempt to reconnect fails, the client runtime will sleep for three seconds (the default value for the imqReconnectInterval attribute) before trying again. After 10 unsuccessful attempts, the application will receive a JMSException .
You can ensure that the broker starts automatically with at system start-up time. See Sun Java System Message Queue 3.7 UR1 Installation Guide for information on how to configure automatic broker start-up. For example, on the Solaris platform, you can use /etc/rc.d scripts.
Configure your connection-factory objects as follows:
imqobjmgr add -t cf -l "cn=myCF" \ -o "imqAddressList=myhost1, mqtcp://myhost2:12345/jms" \ -o "imqReconnect=true" \ -o "imqReconnectRetries=5" |
This command creates a connection factory object with two addresses in the broker list. The first address describes a broker instance running on the host myhost1 with a standard port number (7676). The second address describes a jms connection service running at a statically configured port number (12345).
Configure your connection-factory objects as follows:
imqobjmgr add -t cf -l "cn=myConnectionFactory" \ -o "imqAddressList=mq://myhost1/ssljms, \ mq://myhost2/ssljms, \ mq://myhost3/ssljms, \ mq://myhost4/ssljms” \ -o "imqReconnect=true" \ -o "imqReconnectRetries=5" \ -o "imqAddressListBehavior=RANDOM" |
This command creates a connection factory object with four addresses in the imqAddressList. All the addresses point to jms services running on SSL transport on different hosts. Since the imqAddressListBehavior attribute is set to RANDOM, the client connections that are established using this connection factory object will be distributed randomly among the four brokers in the address list.
This is a clustered broker configuration, so you must configure one of the brokers in the cluster as the master broker. In the connection-factory address list, you can also specify a subset of all the brokers in the cluster.