New Features in Message Queue 4.0

Message Queue 4.0 was a minor release limited to supporting Application Server 9 PE. It included a few new features, some feature enhancements, and bug fixes. This section includes a description of new features in this release:

• Support for JMX Administration API

• Client Runtime Logging

• Connection Event Notification API

• Broker Administration Enhancements

• Displaying Information About a JDBC-Based Data Store

• JDBC Provider Support

• Persistent Data Store Format Changes

• Additional Message Properties

• SSL Support

One of the minor but potentially disruptive changes introduced with version 4.0 was the deprecation of the command-line option to specify a password. Henceforth, you must store all passwords in a file as described in Deprecated Password Option, or enter them when prompted.

Support for JMX Administration API

A new API was added in Message Queue 4.0 for configuring and monitoring Message Queue brokers in conformance with the Java Management Extensions (JMX) specification. Using this API, you can configure and monitor broker functions programmatically from within a Java application. In earlier versions of Message Queue, these functions were accessible only from the command line administration utilities or the Administration Console.

For more information see the Sun Java System Message Queue 4.2 Developer’s Guide for JMX Clients.

Client Runtime Logging

Message Queue 4.0 introduced support for client runtime logging of connection and session-related events.

Fore information regarding client runtime logging and how to configure it, see the Java Dev Guide pag 137.

Connection Event Notification API

Message Queue 4.0 introduced an event notification API that allows the client runtime to inform an application about changes in connection state. Connection event notifications allow a Message Queue client to listen for closure and re-connection events and to take appropriate action based on the notification type and the connection state. For example, when a failover occurs and the client is reconnected to another broker, an application might want to clean up its transaction state and proceed with a new transaction.

For information about connection events and how to create an event listener, see the Java Dev Guide, page 96.

Broker Administration Enhancements

In Message Queue 4.0, a new subcommand and several command options were added to the Command utility (imqcmd) to allow administrators to quiesce a broker, to shutdown a broker after a specified interval, to destroy a connection, or to set java system properties (for example, connection related properties).

• Quiescing a broker moves it into a quiet state, which allows messages to be drained before the broker is shut down or restarted. No new connections can be created to a broker that is being quiesced. To quiesce the broker, enter a command like the following.

  imqcmd quiesce bkr -b Wolfgang:1756

• To shut down the broker after a specified interval, enter a command like the following. (The time interval specifies the number of seconds to wait before the broker is shut down.)

  imqcmd shutdown bkr -b Hastings:1066 -time 90

  If you specify a time interval, the broker will log a message indicating when shutdown will occur. For example,

  Shutting down the broker in 29 seconds (29996 milliseconds)

  While the broker is waiting to shut down, its behavior is affected in the following ways.

  • Administrative jms connections will continue to be accepted.

  • No new jms connections will be accepted.

  • Existing jms connections will continue to work.

  • The broker will not be able to take over for any other broker in a high-availability broker cluster.

  • The imqcmd utility will not block, it will send the request to shut down to the broker and return right away.

• To destroy a connection, enter a command like the following.

  imqcmd destroy cxn -n 2691475382197166336

  Use the command imqcmd list cxn or imqcmd query cxn to obtain the connection ID.

• To set a system property using imqcmd, use the new –D option. This is useful for setting or overriding JMS connection factory properties or connection-related java system properties. For example:

  imqcmd list svc -secure -DimqSSLIsHostTrusted=true
  imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore 
              -Djavax.net.ssl.trustStorePassword=mytrustword

For complete information about the syntax of the imqcmd command, see Chapter 15, Command Line Reference, in Sun Java System Message Queue 4.2 Administration Guide.

Displaying Information About a JDBC-Based Data Store

In Message Queue 4.0 a new query subcommand was added to the Database Manager utility, imqdbmgr. This subcommand is used to display information about a JDBC-based data store, including the database version, the database user, and whether the database tables have been created.

The following is an example of the information displayed by the command.

imqdbmgr query

[04/Oct/2005:15:30:20 PDT] Using plugged-in persistent store:
        version=400
        brokerid=Mozart1756
        database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb
        database user=scott
Running in standalone mode.
Database tables have already been created.

JDBC Provider Support

In Message Queue 4.0, Apache Derby Version 10.1.1 is now supported as a JDBC-based data store provider.

Persistent Data Store Format Changes

Message Queue 4.0 introduced changes to the JDBC-based data store for optimization and to support future enhancements. For this reason the format of the JDBC-based data store was increased to version 400. Note that in Message Queue 4.0, the file-based data store version remains 370 because no changes were made to it.

Additional Message Properties

Message Queue 4.0 added two new properties which are set on all messages that are placed in the dead message queue.

• JMS_SUN_DMQ_PRODUCING_BROKER indicates the broker where the message was produced.

• JMS_SUN_DMQ_DEAD_BROKER indicates the broker who marked the message dead.

SSL Support

Starting with Message Queue 4.0, the default value for the client connection factory property imqSSLIsHostTrusted is false. If your application depends on the prior default value of true, you need to reconfigure and to set the property explicitly to true.

You might choose to trust the host when the broker is configured to use self-signed certificates. In this case, in addition to specifying that the connection should use an SSL-based connection service (using the imqConnectionType property), you should set the imqSSLIsHostTrusted property to true.

For example, to run client applications securely when the broker uses self-signed certificates, use a command like the following.

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true ClientAppName

To use the Command utility (imqcmd) securely when the broker uses self-signed certificates, use a command like the following (for listing connector services).

imqcmd list svc -secure -DimqSSLIsHostTrusted=true