New Features in Message Queue 4.1

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:

High-Availability Broker Clusters

Message Queue 4.1 introduced a new, enhanced broker cluster. As compared
to a conventional broker cluster, which provides only messaging
service availability (if a broker fails, another broker is available
to provide messaging service), the enhanced broker cluster also provides 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 message 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 enhanced broker cluster, you specify
the following broker properties for each broker in the cluster:

Cluster membership properties, which
specify that the broker is in an enhanced 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 enhanced 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.

If you have been using a highly available database with Message Queue 4.0
and want to switch to an enhanced 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.

JAAS Support

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.

Persistent Data Store Format Change

Message Queue 4.1 changed the JDBC-based data store to support enhanced
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.

Broker Environment Configuration

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.

Java ES Monitoring Framework Support

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.

Enhanced Transaction Management

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.

Fixed Ports for C Client Connections

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:

MQ_SERVICE_PORT_PROPERTY=1756

MQ_CONNECTION_TYPE_PROPERTY=SSL

On the broker side, set the imq.serviceName.protocolType.port property as follows:

imq.ssljms.tls.port=1756

Note –

The MQ_SERVICE_PORT_PROPERTY connection property
has been backported to Message Queue 3.7 Update 2.