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. The default value for the Address List Behavior attribute is priority, if the JMS type is of type LOCAL.
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 JMS Connection Factories in Sun Java System Application Server 9.1 Administration Guide.
You can configure ActivationSpec properties of the jmsra resource adapter in the sun-ejb-jar.xml file for a message-driven bean using activation-config-property elements. Whenever a message-driven bean (EndPointFactory) is deployed, the connector runtime engine finds these properties and configures them accordingly in the resource adapter. See activation-config-property in Sun Java System Application Server 9.1 Application Deployment Guide.
The Application Server transparently enables messages to be delivered randomly to message-driven beans having the 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 message-driven bean that subscribe to same topic are considered equal. When a message-driven bean is deployed to multiple instances of the Application Server, only one of the message-driven beans receives the message. If multiple distinct message-driven beans subscribe to same topic, one instance of each message-driven bean 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, the Sun Java System Message Queue software allows up to that number of message-driven beans to consume messages from same queue. The message is delivered randomly to the message-driven beans. If maxNumActiveConsumers is set to -1, there is no limit to the number of consumers.
To ensure that local delivery is preferred, set addresslist-behavior to priority. This setting specifies that the first broker in the AddressList is selected first. This first broker is the local colocated Message Queue instance. If this broker is unavailable, connection attempts are made to brokers in the order in which they are listed in the AddressList. This setting is the default for Application Server instances that belong to a cluster.
Clustering features are not available in the developer profile. For information about profiles, see Usage Profiles in Sun Java System Application Server 9.1 Administration Guide.
There are two levels of availability for JMS components:
Service availability – At this level, availability of the JMS service matters, but it's not important if messages are not available for a while. As long as a connection gets failed over to a new available instance providing the service, the JMS component considers that the service is available and functions normally. This level of availability is described in Connection Failover in Sun Java System Application Server 9.1 Developer’s Guide.
Data availability – At this level, both availability of the service and persistent messages are required. JMS semantics of once and only once delivery and message ordering are also handled at this level.
You can enable data availability in the Sun Java System Message Queue cluster that comprises the Java Message Service (JMS). Messages are persisted to the common persistence store and are available from all the other broker instances in the cluster or from the high-availability database (HADB) if it is installed and the enterprise profile is selected. For information about profiles, see Usage Profiles in Sun Java System Application Server 9.1 Administration Guide. You must enable availability for the Application Server instances before you can enable data availability for the corresponding brokers.
Individual applications and modules cannot control or override JMS availability.
To enable data availability, select the Availability Service component under the relevant configuration in the Admin Console. Check the Availability Service box. To enable availability for the JMS service, select the JMS Availability tab, then check the Availability Service box. All instances in an Application Server cluster should have the same instance availability and JMS availability settings to ensure consistent behavior. For details, see the Sun Java System Application Server 9.1 High Availability Administration Guide.
Clustering features are not available in the developer profile. For information about profiles, see Usage Profiles in Sun Java System Application Server 9.1 Administration Guide.