This section reviews the most important cluster configuration properties, grouped into the following categories:
A complete list of cluster configuration properties can be found in Table 16–11
The following properties are used to configure the cluster connection service used for internal communication between brokers in the cluster. These properties are used by both conventional and enhanced clusters.
imq.cluster.transport specifies the transport protocol used by the cluster connection service, such as tcp or ssl.
imq.cluster.port specifies the port number for the cluster connection service. You might need to set this property, for instance, to specify a static port number for connecting to the broker through a firewall.
imq.cluster.hostname specifies the host name or IP address for the cluster connection service, used for internal communication between brokers in the cluster. The default setting works fine, however, explicitly setting the property can be useful if there is more than one network interface card installed in a computer. If you set the value of this property to localhost, the value will be ignored and the default will be used.
The following properties, in addition to those listed in Cluster Connection Service Properties, are used to configure conventional clusters:
imq.cluster.brokerlist specifies a list of broker addresses defining the membership of the cluster; all brokers in the cluster must have the same value for this property.
For example, to create a conventional cluster consisting of brokers at port 9876 on host1, port 5000 on host2, and the default port (7676) on ctrlhost, use the following value:
imq.cluster.brokerlist=host1:9876,host2:5000,ctrlhost
imq.cluster.masterbroker specifies which broker in a conventional cluster is the master broker that maintains the configuration change record that tracks the addition and deletion of destinations and durable subscribers. For example:
imq.cluster.masterbroker=host2:5000
While specifying a master broker using the imq.cluster.masterbroker is not mandatory for a conventional cluster to function, it guarantees that persistent information propagated across brokers (destinations and durable subscriptions) is always synchronized. See Conventional Clusters in Sun Java System Message Queue 4.3 Technical Overview.
Enhanced broker clusters, which share a JDBC-based data store, require more configuration than do conventional broker clusters. In addition to the properties listed in Cluster Connection Service Properties, the following categories of properties are used to configure an enhanced cluster:
imq.cluster.ha is a boolean value that specifies if the cluster is an enhanced cluster (true) or a conventional broker (false). The default value is false.
If set to true, mechanisms for failure detection and takeover of a failed broker are enabled. Enhanced clusters are self-configuring: any broker configured to use the cluster’s shared data store is automatically registered as part of the cluster, without further action on your part. If the conventional cluster property, imq.cluster.brokerlist, is specified for a high–availability broker, the property is ignored and a warning message is logged at broker startup.
imq.persist.store specifies the model for a broker's persistent data store. This property must be set to the value jdbc for every broker in an enhanced cluster.
imq.cluster.clusterid specifies the cluster identifier, which will be appended to the names of all database tables in the cluster’s shared persistent store. The value of this property must be the same for all brokers in a given cluster, but must be unique for each cluster: no two running clusters may have the same cluster identifier.
imq.brokerid is a broker identifier that must be unique for each broker in the cluster. Hence, this property must be set in each broker's instance configuration file rather than in a cluster configuration file.
The persistent data store for an enhanced cluster is maintained on a highly-available JDBC database.
The highly-availabile database may be Sun’s MySQL Cluster Edition or High Availability Session Store (HADB), or it may be an open-source or third-party product such as Oracle Corporation’s Real Application Clusters (RAC). As described in JDBC-Based Persistence Properties, the imq.persist.jdbc.dbVendor broker property specifies the name of the database vendor, and all of the remaining JDBC-related properties are qualified with this vendor name.
The JDBC-related properties are discussed under JDBC-Based Persistence Properties and summarized in Table 16–6. See the example configurations for MySQL and HADB in Example 8–1 and Example 8–2, respectively.
In setting JDBC-related properties for an enhanced cluster, note the following vendor-specific issues:
MySQL Cluster Edition
When using MySQL Cluster Edition as a highly-available database, you must specify the NDB Storage Engine rather than the InnoDB Storage Engine set by Message Queue by default. To specify the NDB Storage Engine, set the following broker property for all brokers in the cluster:
imq.persist.jdbc.mysql.tableoption=ENGINE=NDBCLUSTER
HADB
When using HADB in a Sun Java Application Server environment, if the integration between Message Queue and Application Server is local (that is, there is a one-to-one relationship between Application Server instances and Message Queue brokers), the Application Server will automatically propagate HADB-related properties to each broker in the cluster. However, if the integration is remote (a single Application Server instance using an externally configured broker cluster), then it is your responsibility to configure the needed HADB properties explicitly.
The following configuration properties (listed in Table 16–11) specify the parameters for the exchange of heartbeat and status information within an enhanced cluster:
imq.cluster.heartbeat.hostname specifies the host name (or IP address) for the heartbeat connection service.
imq.cluster.heartbeat.port specifies the port number for the heartbeat connection service.
imq.cluster.heartbeat.interval specifies the interval, in seconds, at which heartbeat packets are transmitted.
imq.cluster.heartbeat.threshold specifies the number of missed heartbeat intervals after which a broker is considered suspect of failure.
imq.cluster.monitor.interval specifies the interval, in seconds, at which to monitor a suspect broker’s state information to determine whether it has failed.
imq.cluster.monitor.threshold specifies the number of elapsed monitor intervals after which a suspect broker is considered to have failed.
Smaller values for these heartbeat and monitoring intervals will result in quicker reaction to broker failure, but at the cost of reduced performance and increased likelihood of false suspicions and erroneous failure detection.