If you are using conventional clusters, you enable automatic reconnection by setting the connection factory imqReconnectEnabled attribute to true. If you are using a high availability cluster, the imqReconnectEnabled attribute is ignored; the client runtime will automatically reconnect to a backup broker if the connection is lost and not regained after no more than imqReconnectAttempts attempts. This applies to all deployment configurations: whether Message Queue is used stand alone or whether the connection is created through a resource adapter.
A list of message-service addresses (using the imqAddressList attribute). Independently of the clustering model used, the client runtime uses this address list when it establishes the initial connection.
When you connect to a conventional cluster, the client runtime also uses the address list when it tries to reestablish a connection to the 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 Cluster Message Delivery in Oracle GlassFish Message Queue 4.4.2 Technical Overview for more information on broker clusters.)
To enable parallel-broker reconnection, set theimqAddressListBehavior 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 imqAddressListBehavior 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.
If you use the high availability clustering model, the address list is dynamically updated to include the brokers that are connected to the highly available database serving the cluster. In this case, the client runtime and the brokers use an internal protocol to determine which broker takes over the persistent data of the failed broker. Therefore the imqAddressListBehavior property does not apply to this model.
For high-availability clusters, the broker will attempt to reconnect forever (no matter what value you specify for this attribute). If the client does not want this behavior, it must explicitly close the connection.
imqobjmgr add -t cf -l "cn=myConnectionFactory" \ -o "imqAddressList=mq://jpgserv/jms" \ -o "imqReconnect=true" \ -o "imqReconnectAttempts=10" -j "java.naming.factory.initial = com.sun.jndi.fscontext.RefFSContextFactory -j "java.naming.provider.url= file:///home/foo/imq_admin_objects"
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 at system start-up time. See Starting Brokers Automatically in Oracle GlassFish Message Queue 4.4.2 Administration 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" -j "java.naming.factory.initial = com.sun.jndi.fscontext.RefFSContextFactory -j "java.naming.provider.url= file:///home/foo/imq_admin_objects"
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).
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" -j "java.naming.factory.initial = com.sun.jndi.fscontext.RefFSContextFactory -j "java.naming.provider.url= file:///home/foo/imq_admin_objects"
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. If you are using a high availability cluster, the RANDOM attribute is ignored during a failover reconnect after losing an existing connection to a broker.
For a conventional cluster, 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.