Message Queue 4.1 was a minor release that included a number of new features, some feature enhancements, and bug fixes. This section describes the new features in the 4.1 release and provides further references for your use:
For information about features introduced in Message Queue 4.0, see New Features in Message Queue 4.0.
Message Queue 4.1 introduced high-availability broker clusters. As compared to conventional broker clusters, which provide only messaging service availability (if a broker fails, another broker is available to provide messaging service), high-availability broker clusters also provide data availability (if a broker fails, its persistent messages and state data are available to another broker to use to take over message delivery).
The high-availability implementation introduced in Message Queue 4.1 uses a shared JDBC-based data store: instead of each broker in a broker cluster having its own persistent data store, all brokers in the cluster share the same JDBC-compliant database. If a particular broker fails, another broker within the cluster takes over the message routing and delivery for the failed broker. In doing so, the failover broker uses data and state information in the shared data store. Messaging clients of the failed broker reconnect to the failover broker, which provides uninterrupted messaging service.
The shared JDBC-based store used in the Message Queue 4.1 high-availability implementation must itself be highly available. If you do not have a highly available database or if uninterrupted message delivery is not important to you, you can continue to use conventional clusters, which provide service availability without data availability.
To configure a Message Queue 4.1 high-availability broker cluster, you specify the following broker properties for each broker in the cluster:
Cluster membership properties, which specify that the broker is in a high-availability broker cluster, the ID of the cluster, and the ID of the broker within the cluster.
Highly available database properties, which specify the persistent data model (JDBC), the name of the database vendor, and vendor-specific configuration properties.
Failure detection and failover properties, which specify how broker failure is detected and handled using a failover broker.
To use the high-availability broker cluster implementation, you must do the following:
Install a highly available database.
Install the JDBC driver .jar file.
Create the database schema for the highly available persistent data store.
Set high-availability properties for each broker in the cluster.
Start each broker in the cluster.
For a conceptual discussion of high-availability broker clusters and how they compare to conventional clusters, see Chapter 4, Broker Clusters, in Sun Java System Message Queue 4.2 Technical Overview. For procedural and reference information about high-availability broker clusters, see Chapter 10, Configuring and Managing Broker Clusters, in Sun Java System Message Queue 4.2 Administration Guide and Cluster Configuration Properties in Sun Java System Message Queue 4.2 Administration Guide.
If you have been using a highly available database with Message Queue 4.0 and want to switch to a high-availability broker cluster, you can use the Database Manager utility (imqdbmgr to convert to a shared persistent data store. Also see Broker Clusters for more known issues and limitations.
In addition to the file-based and LDAP-based built-in authentication mechanisms, Message Queue 4.1 introduced support for the Java Authentication and Authorization Service (JAAS), which allows you to plug an external authentication mechanism into the broker to authenticate Message Queue clients.
For a description of the information that a broker makes available to a JAAS-compliant authentication service and an explanation of how to configure the broker to use such a service, see Using JAAS-Based Authentication in Sun Java System Message Queue 4.2 Administration Guide.
Message Queue 4.1 changed the JDBC-based data store to support high-availability broker clusters. For this reason the format of the JDBC—based data store is increased to version 410. Format versions 350, 370, and 400 are automatically migrated to the 410 version.
Please note that the format of the file-based persistent data store remains at version 370 because no changes were made to it.
The property IMQ_DEFAULT_EXT_JARS has been added to the Message Queue 4.1 environment configuration file, imqenv.conf. You can set this property to specify the path names of external .jar files to be included in CLASSPATH when the broker starts up. If you use this property to specify the location of external .jar files, you no longer need to copy these files to the lib/ext directory. External .jar files can refer to JDBC drivers or to JAAS login modules. The following sample poperty, specifies the location of JDBC drivers.
Message Queue 4.1 introduced support for the Sun Java Enterprise System (Java ES) Monitoring Framework, which allows Java ES components to be monitored using a common graphical interface. This interface is implemented by a web-based console called the Sun Java System Monitoring Console. Administrators can use the Console to view performance statistics, reate rules for automatic monitoring, and acknowledge alarms. If you are running Message Queue along with other Java ES components, you might find it more convenient to use a single interface to manage all of them.
For information on using the Java ES monitoring framework to monitor Message Queue, see XREF.
Previously, only transactions in a PREPARED state were allowed to be rolled back administratively. That is, if a session that was part of a distributed transaction did not terminate gracefully, the transaction remained in a state that could not be cleaned up by an administrator. In Message Queue 4.1, you can now use the Command utility (imqcmd) to clean up (roll back) transactions that are in the following states: STARTED, FAILED, INCOMPLETE, COMPLETE, and PREPARED.
To help you determine whether a particular transaction can be rolled back (especially when it is not in a PREPARED state), the Command utility provides additional data as part of theimqcmd query txn output: it provides the connection id for the connection that started the transaction and specifies the time when the transaction was created. Using this information, an administrator can decide whether the transaction needs to be rolled back. In general, the administrator should avoid rolling back a transaction prematurely.
In Message Queue 4.1, C clients, like Java clients, can now connect to a fixed broker port rather than to a port dynamically assigned by the broker's Port Mapper service. Fixed port connections are useful if you're trying to get through a firewall or if you need to bypass the Port Mapper service for some other reason.
To configure a fixed port connection you need to configure both the broker and the C client run time (both ends of the connection). For example, if you want to connect your client via ssljms to port 1756, you would do the following:
On the client side, set the following properties:
On the broker side, set the imq.serviceName.protocolType.port property as follows:
The MQ_SERVICE_PORT_PROPERTY connection property has been backported to Message Queue 3.7 Update 2.