Cluster Configuration Properties

As shown above, the most important cluster configuration property in a conventional cluster is imq.cluster.brokerlist, a list of broker addresses defining the membership of the cluster; all brokers in the cluster must have the same value for this property. (By contrast, high-availability clusters are self-configuring: any broker configured to use the cluster’s shared store is automatically registered as part of the cluster, without further action on your part. If imq.cluster.brokerlist is specified for an HA broker, it is ignored and a warning message is logged at broker startup.)

Additional cluster configuration properties include the following:

• imq.cluster.ha is a boolean flag specifying whether the broker is a high-availability broker.

• imq.cluster.url specifies the location of the cluster configuration file, if any.

• imq.cluster.hostname gives the host name or IP address for the cluster connection service, used for internal communication between brokers in the cluster. This setting can be useful if more than one host is available: for example, if there is more than one network interface card installed in a computer.

• imq.cluster.port gives 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.transport specifies the transport protocol used by the cluster connection service, such as tcp or ssl.

• imq.cluster.masterbroker (conventional clusters only) designates which broker (if any) is the master broker that keeps track of state changes.

• imq.cluster.clusterid (HA clusters only) gives 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.

While the hostname and port properties can be set independently for each individual broker, all of the other properties listed above must have the same values for all brokers in the cluster. In addition, in an HA cluster, you must specify a unique broker identifier for each broker by setting the broker’s imq.brokerid property (see Table 14–1); this value must be different for each broker in the cluster.

Brokers in a high-availability cluster have additional properties relating to persistent store configuration, failure detection, and takeover, which are discussed in the following sections.

JDBC Configuration Properties for HA Clusters

The persistent data store for an HA cluster is maintained on a high-availability database server, using the Java Database Connectivity (JDBC) API (see JDBC-Based Persistence). All brokers belonging to such a cluster must therefore have their imq.persist.store property (see Table 14–4) set to jdbc. The remaining persistent store properties are discussed under JDBC-Based Persistence and summarized in Table 14–6.

The database server may be Sun’s own High Availability Database (HADB) server, or it may be an open-source or third-party product such as Apache Software Foundation’s Derby (Java DB) or Oracle Corporation’s Real Application Clusters (RAC). As described in JDBC-Based Persistence, 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: for instance, when using Sun’s HADB for the HA server, the Java class name of the JDBC driver is specified by a property named imq.persist.jdbc.hadb.driver.

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 message brokers), the Application Server will automatically propagate these properties to each broker in the HA 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 properties explicitly for each broker.

After setting all of the needed JDBC configuration properties for the brokers in an HA cluster, you must also install your JDBC driver’s .jar file in the appropriate directory location, depending on your operating-system platform (as listed in Appendix A, Platform-Specific Locations of Message Queue Data) and then execute the Database Manager command

   imqdbmgr create tbl

to create the database schema for the HA persistent data store.

Failure Detection and Takeover Properties for HA Clusters

The following configuration properties (listed in Table 14–10) specify the parameters for the exchange of heartbeat and status information within an HA cluster:

• imq.cluster.heartbeat.hostname gives the host name (or IP address) for the heartbeat connection service.

• imq.cluster.heartbeat.port gives the port number for the heartbeat connection service.

• imq.cluster.heartbeat.interval defines 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 defines 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.