The new features in Message Queue 4.4 and previous releases in the Message Queue 4.x family are described in the following sections:
Message Queue 4.4 is a minor release that includes a number of feature enhancements and bug fixes. This section describes the new features included in this release:
Because the JMS specification does not define a wire protocol for communication between brokers and clients, each JMS provider (including Message Queue) has defined and uses its own propriety protocol. This situation has led to non-interoperability across JMS providers.
The JMS bridge service in Message Queue 4.4 closes this gap by enabling a Message Queue broker to map its destinations to destinations in external JMS providers. This mapping effectively allows the Message Queue broker to communicate with clients of the external JMS provider.
The JMS bridge service supports mapping destinations in external JMS providers that:
Are JMS 1.1 compliant
Support JNDI administrative objects
Use connection factories of type javax.jms.ConnectionFactory or javax.jms.XAConnectionFactory
For transacted mapping, support the XA interfaces as a resource manager
Many open source and commercial JMS providers meet these requirements, which makes the JMS bridge service an effective way to integrate Message Queue into an existing messaging environment that employs other JMS providers.
For more information about the JMS bridge service see:
For information about the architecture, subcomponents, and capabilities of the JMS bridge service, see JMS Bridge Service in Sun GlassFish Message Queue 4.4 Technical Overview.
For information about configuring and managing JMS bridges in a broker, see Configuring and Managing JMS Bridge Services in Sun GlassFish Message Queue 4.4 Administration Guide.
As mentioned earlier, the JMS specification does not define a wire protocol for communication between brokers and clients. The STOMP (Streaming Text Oriented Messaging Protocol) open source project at http://stomp.codehaus.org defines a simple wire protocol that clients written in any language can use to communicate with any messaging provider that supports the STOMP protocol.
Message Queue 4.4 provides support for the STOMP protocol through the STOMP bridge service. This service enables a Message Queue broker communicate with STOMP clients.
For more information about the STOMP bridge service see:
For information about the architecture and capabilities of the STOMP bridge service, see STOMP Bridge Service in Sun GlassFish Message Queue 4.4 Technical Overview.
For information about configuring and managing a STOMP bridge in a broker, see Configuring and Managing STOMP Bridge Services in Sun GlassFish Message Queue 4.4 Administration Guide.
The following additional enhancements are also provided in Message Queue 4.4:
The UMS now provides functions that use HTTP GET to offer several services:
getBrokerInfo: retrieves information about the broker.
getConfiguration: retrieves information about the UMS configuration.
debug: turns debug logging in the UMS server on and off.
ping: communicates with the broker to confirm that it is running.
For information about these new features, see Query and utility functions using HTTP GET in https://mq.dev.java.net/4.4-content/imqums/protocol.html.
For an overview of UMS, see Universal Message Service (UMS). For documentation of the UMS API, see https://mq.dev.java.net/4.4-content/imqums/protocol.html. For programming examples in several languages, see https://mq.dev.java.net/4.4-content/imqums/examples/README.html.
Message Queue is now packaged for distribution using the open source Image Packaging System (IPS), also known as the pkg(5) system. This packaging method has been added in order for Message Queue to integrate with Sun GlassFish Enterprise Server 2.1.1.
Message Queue 3.7 provided an audit logging feature that was removed in Message Queue 4.0. This feature has been reinstated in Message Queue 4.4. For information about this feature, see Audit Logging in Sun GlassFish Message Queue 4.4 Administration Guide.
Message Queue 4.3 was a minor release that included a number of feature enhancements and bug fixes. This section describes the new features included in this release:
Message Queue 4.3 introduces a new universal messaging service (UMS) and messaging API that provides access to Message Queue from any http-enabled device. As a result, almost any application can communicate with any other application and benefit from the reliability and guaranteed delivery of JMS messaging. In addition, the UMS provides enhanced scalability for JMS messaging, allowing the number of messaging clients to reach internet-scale proportions.
The basic UMS architecture is shown in the following figure:
The UMS, which runs in a web server, is language neutral and platform independent. The UMS serves as a gateway between any non-JMS client application and a JMS provider. It receives messages sent using the UMS API, transforms them into JMS messages, and produces them to destinations in the JMS provider by way of the provider's native protocol. Similarly, it retrieves messages from destinations in the JMS provider, transforms them into text or SOAP messages, and sends the messages to non-JMS clients as requested by the clients through the UMS API.
The simple, language-independent, protocol-based UMS API supports both Web-based and non-Web-based applications, and can be used with both scripting and programming languages. The API is offered in two styles: a simple messaging API that uses a Representational State Transfer (REST)-style protocol, and an XML messaging API that embeds the protocol in a SOAP message header. In both cases, however, the API requires only a single http request to send or receive a message.
The simplicity and flexibility of the UMS API means that AJAX, .NET, Python, C, Java, and many other applications can send text message and/or SOAP (with attachment) messages to JMS destinations or receive messages from JMS destinations. For example, Python applications can communicate with .NET applications, iPhone can communicate with Java applications, and so forth.
For Message Queue 4.3, the UMS supports only Message Queue as a JMS provider.
The UMS serves as more than the simple gateway described above. It supports stateful as well as stateless client sessions. If requested by the client, the UMS will maintain session state for the client application across multiple service requests. The UMS can use container-managed authentication, or be configured to authenticate clients with the Message Queue broker, or both. The UMS also supports transactions, enabling client applications to commit or roll back multiple service requests as a single atomic unit.
Because the UMS can support a large number of clients on a single connection to the Message Queue broker, it eases the load on the broker's connection services, allowing for maximum scalability. In addition, UMS capacity can be increased by horizontal scaling, allowing for internet-scale messaging loads.
On the client side, because of the simplicity of the protocol-based UMS API, no client libraries are required. As a result, the API can be extended in the future to implement additional JMS features without any need to upgrade client applications.
To use the UMS, you deploy the UMS into a web container that supports Servlet 2.4 or later specifications, start the Message Queue broker, create the appropriate destinations, and write a messaging application that uses the UMS API to send or receive messages.
The UMS imqums.war file, contained in the Message Queue 4.3 distribution, is installed in the following location, depending on platform:
You can rename the .war file as appropriate.Table 1–5 Location of imqums.war file
Location of imqums.war
After you have deployed the imqums.war into a web container at localhost:port, you can find UMS documentation at:
Otherwise you can find UMS documentation as follows:
For information on configuring the UMS, see https://mq.dev.java.net/4.3-content/ums/config.html.
For documentation of the UMS API, see https://mq.dev.java.net/4.3-content/ums/protocol.html.
For programming examples in several languages, see https://mq.dev.java.net/4.3-content/ums/examples/README.html.
UMS is currently supported on the following web containers:
Sun GlassFish Enterprise Server, Version 2.1 and Version 3 Prelude
Tomcat, Versions 5.5 and 6.0
Message Queue 4.3 provides AIX platform packages and an Installer for installing them).
The Message Queue AIX implementation supports the following software:
AIX v 6.1 or higher (earlier versions of AIX are supported via the Unix/Java Only bundle)
IBM XL C/C++ Compiler V9.0
JDK 1.5 or better
For installation instructions, see Chapter 4, AIX Installation, in Sun Java System Message Queue 4.3 Installation Guide.
On the AIX platform, Message Queue files are installed under a single Message Queue home directory, IMQ_HOME. IMQ_HOME denotes the directory mqInstallHome/mq, where mqInstallHome is the installation home directory you specify when installing the product (by default, home-directory/MessageQueue).
The resulting Message Queue directory structure is the same as that for the Windows platform (see the Windows section of Appendix A, Platform-Specific Locations of Message Queue Data, in Sun GlassFish Message Queue 4.4 Administration Guide.)
Message Queue support for the AIX platform includes support for the Message Queue C-API. For instructions on building and compiling C applications on the AIX platform, see XREF.
Message Queue 4.3 introduces a new installer for Zip-based distributions, as opposed to native package distributions. The installer is used to install the new Message Queue .zip distributions for the AIX platform.
The new installer extracts Message Queue .zip files to any directory for which you have write access (you do not need root privileges) and it also enables you to register your Message Queue installation with Sun Connection.
To minimize the size of download bundles, the Java Runtime is no longer be included in the zip-based distribution (most sites will already have it). As a result, the installer command requires that a JDK or JRE be specified, either by using the JAVA_HOME environment variable or by using the -j option on the command line, as follows:
$ installer -j JDK/JRE-path
where JDK/JRE-path is the path of the specified JDK or JRE.
The following updated platform support will be certified for Message Queue 4.3:
Windows Server 2008
The following additional enhancements are included in Message Queue 4.3:
The installed directory structure for Message Queue on the Windows platform has been modified from previous versions to match that of the AIX platform. This directory structure will be adopted as well by the Solaris and Linux platforms in the future, to facilitate multiple installations on single computer and automatic update of Message Queue through Sun Connection, a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software (see Installer Support for Sun Connection Registration).
The following new properties are available for configuring a broker:Table 1–6 Broker Routing and Delivery Properties
The maximum number of messages that a producer can process in a single transaction. It is recommended that the value be less than 5000 to prevent the exhausting of resources.
The maximum number of messages that a consumer can process in a single transaction. It is recommended that the value be less than 1000 to prevent the exhausting of resources.
The maximum number of connections that can be opened to the database.
A new attribute and composite data keys have been added to the JMX API as follows:
A NextMessageID attribute has been added to the Destination Monitor MBean to provide the JMS message ID of the next message to be delivered to a consumer.
A NextMessageID key for composite date has been added to the Consumer Manager Monitor MBean to provide the JMS message ID of the next message to be delivered to the consumer.
A NumMsgsPending key for composite date has been added to the Consumer Manager Monitor MBean to provide the number of messages that have been dispatched to the consumer.
The command for listing durable subscriptions:
list dur [-d topicName]
has been enhanced to make specification of the topic name optional. If the topic is not specified, the command lists all durable subscriptions for all topics (including those with wildcard naming conventions)
Message Queue 4.2 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.2 release and provides further references for your use:
With Message Queue 4.2, a publisher can publish messages to multiple topic destinations and a subscriber can consume messages from multiple topic destinations. This capability is achieved by using a topic destination name that includes wildcard characters, representing multiple destinations. Using such symbolic names allows administrators to create additional topic destinations, as needed, consistent with the wildcard naming scheme. Publishers and subscribers automatically publish to and consume from the added destinations. (Wildcard topic subscribers are more common than publishers.)
This feature does not apply to queue destinations.
The format of symbolic topic destination names and examples of their use is described in Supported Topic Destination Names in Sun GlassFish Message Queue 4.4 Administration Guide.
This feature, introduced in Message Queue 4.2, enables validation of the content of a text (not object) XML message against an XML schema at the point the message is sent to the broker. The location of the XML schema (XSD) is specified as a property of a Message Queue destination. If no XSD location is specified, the DTD declaration within the XML document is used to perform DTD validation. (XSD validation, which includes data type and value range validation, is more rigorous than DTD validation.)
For information on the use of this feature, see Schema Validation of XML Payload Messages in Sun GlassFish Message Queue 4.4 Developer’s Guide for Java Clients.
According to the X/Open distributed transaction model, support for distributed transactions relies upon a distributed transaction manager which tracks and manages operations performed by one or more resource managers. With Message Queue 4.2, the Message Queue C-API supports the XA interface (between a distributed transaction manager and Message Queue as a XA-compliant resource manager), allowing Message Queue C-API clients running in a distributed transaction processing environment (such as BEA Tuxedo) to participate in distributed transactions.
This distributed transaction support consists of the following new C-API functions (and new parameters and error codes) used to implement the XA interface specification:
If a C-client application is to be used in the context of a distributed transaction, then it must obtain a connection by using MQGetXAConnection() and create a session for producing and consuming messages by using MQCreateXASession(). The start, commit, and rollback, of any distributed transaction is managed through APIs provided by the distributed transaction manager.
For details of using the distributed transaction functions, see Working With Distributed Transactions in Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.
Message Queue 4.2 provides programming examples based on the Tuxedo transaction manager. For information on the use of these sample programs, see Distributed Transaction Sample Programs in Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.
The distributed transaction functionality is supported on Solaris, Linux, and Windows platforms, however, to date it has only been certified on the Solaris platform.
The Message Queue installer has been enhanced to allow for registration of Message Queue with Sun Connection, a Sun-hosted service that helps you track, organize, and maintain Sun hardware and software.
As part of Message Queue installation, you can choose to register Message Queue with Sun Connection. Information about the installed Message Queue, such as the release version, host name, operating system, installation date, and other such basic information is securely transmitted to the Sun Connection database. The Sun Connection inventory service can help you organize your Sun hardware and software, while the update service can inform you of the latest available security fixes, recommended updates, and feature enhancements.
For details of registering Message Queue with Sun Connection, see Sun Java System Message Queue 4.3 Installation Guide.
Message Queue 4.2 introduced support for MySQL database as a JDBC-based data store. MySQL Cluster Edition can be used as a JDBC database for a standalone broker, and MySQL Cluster Edition can be used as the highly-available shared data store needed for an enhanced broker cluster. For information on configuring Message Queue to use MySQL, see Configuring a JDBC-Based Data Store in Sun GlassFish Message Queue 4.4 Administration Guide and also Enhanced Broker Cluster Properties in Sun GlassFish Message Queue 4.4 Administration Guide.
In addition to the features described above, Message Queue 4.2 included the following enhancements:
Remotely Produced Message Metrics
Message Queue 4.2 introduced new destination metrics that can be useful in monitoring destinations in a broker cluster. In a broker cluster, the messages stored in a given destination on a given broker in the cluster, consist of messages produced directly to the destination as well as messages sent to the destination from remote brokers in the cluster. In analyzing message routing and delivery in a broker cluster, it is sometimes helpful to know how many messages in a destination are local (locally produced) and how many are remote (remotely produced).
Two new physical destination metric quantities are included in Message Queue 4.2: Num messages remote and Total Message bytes remote. The new metric quantities are available through the imqcmd list dst and imqcmd query dst commands (see Viewing Physical Destination Information in Sun GlassFish Message Queue 4.4 Administration Guide) and through new JMX attributes (see Destination Monitor in Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients).
Wildcard Producer and Wildcard Consumer Information
Information to support the use of wildcard characters in destination names (see Multiple Destinations for a Publisher or Subscriber) is provided through new monitoring data. For example, the number of wildcard producers or consumers associated with a destination are available through the imqcmd query dst command (see Viewing Physical Destination Information in Sun GlassFish Message Queue 4.4 Administration Guide) and through new JMX attributes (see Destination Monitor in Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients). Also, wildcard information is available through the ConsumerManager Monitor and ProducerManager Monitor MBeans.
Support for DN Username Format for Client Authentication
Message Queue 4.2 introduced support for DN username format in client connection authentication against an LDAP user repository. The support involves the following new broker property (and value):
This property lets the broker authenticate a client user against an entry in an LDAP user repository by extracting from the DN username format the value of the attribute specified by the following property:
The broker uses the value of the above attribute as the name of the user in access control operations.
For example, if imq.user_repository.ldap.uidattr=udi and a client authentication username is in the format udi=mquser,ou=People,dc=red,dc=sun,dc=com, then “mquser” would be extracted for performing access control.
JAAS Authentication Enhancement
Message Queue 4.2 introduced JAAS authentication by IP address as well as by username.
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 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.
Set high-availability properties for each broker in the cluster.
Start each broker in the cluster.
For a conceptual discussion of enhanced broker clusters and how they compare to conventional clusters, see Chapter 4, Broker Clusters, in Sun GlassFish Message Queue 4.4 Technical Overview. For procedural and reference information about enhanced broker clusters, see Chapter 10, Configuring and Managing Broker Clusters, in Sun GlassFish Message Queue 4.4 Administration Guide and Cluster Configuration Properties in Sun GlassFish Message Queue 4.4 Administration Guide.
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.
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 GlassFish Message Queue 4.4 Administration Guide.
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.
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.
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:
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.
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 GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients.
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.
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.
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 an enhanced 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 16, Command Line Reference, in Sun GlassFish Message Queue 4.4 Administration Guide.
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.
[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.
In Message Queue 4.0, Apache Derby Version 10.1.1 is now supported as a JDBC-based data store provider.
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.
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.
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