Sun Java System Message Queue 3.7 Update 2 Release Notes

About Message Queue 3.7 UR1

Message Queue 3.7 UR1 is a maintenance release to Message Queue 3.6. It includes bug fixes and a small number of minor enhancements. This section includes the following information:

What’s New in This Release

Message Queue 3.7 UR1 includes the following new features:

These are described in the following subsections.

Combining Platform and Enterprise Features in One Edition

In an effort to streamline our product delivery, we are combining the Platform and Enterprise Edition of Sun Java Message Queue. Beginning with Message Queue 3.7 UR1, there will only be a single edition available, which effectively removes the feature restrictions in the stand-alone distribution. We hope this will simplify your experience with this product.

Combining editions also aligns Message Queue better with Solaris Enterprise System and provides a perpetual broad-based right to use Enterprise Edition features, with no support, maintenance, or indemnity. As with previous releases, we will continue to offer several licensing options for support and maintenance services. Message Queue will continue to be packaged with Java Enterprise System and the Application Platform Suite. Please check the online store at http://www.sun.com or consult your sales representative to find an option that best suits your needs. The next table describes the upgrade paths to the new single edition of Message Queue.

Table 1–2 Upgrade Paths for Message Queue 3.7 UR1


Prior Edition	Upgrade Path	Comments
Platform Edition	Sun Java System Message Queue 3.7 UR1	All features (Platform and Enterprise) are now available to 3.7 UR1 customers. Support options are available with license purchase.
Enterprise Edition	Sun Java System Message Queue 3.7 UR1	No feature changes. A range of licensing and support options are available.
Platform Edition support contracts	Upgrade to Enterprise Edition support contract	Existing support contracts for prior releases of Platform Edition will continue to be renewed. No new Platform Edition contracts will be issued for prior Platform Edition releases.
Enterprise Edition support contracts	No change	Existing contracts will continue to be renewed. New contracts will be issued.

The following table describes the changes in delivery sources for various Message Queue products.

Table 1–3 Changes in Delivery Sources for Message Queue Products


Product	Prior Delivery Source	New Delivery Source	Comments
Open Message Queue	Not applicable	Sun download center product page	Standalone download. Community support only. No support contracts available.
Message Queue Platform Edition	Sun download center via the Message Queue product page	No longer available	Only the single edition of Message Queue that combines Platform and Enterprise features is now available.
Message Queue Enterprise Edition trial (via Platform Edition)	Sun download center via the Message Queue product page	Trial license no longer needed	No longer needed
Message Queue Enterprise Edition 90 day Trial (via Java Enterprise System download or CD)	Java Enterprise System download center, prior to version 3 GA (March 2006)	Solaris Enterprise System download center	Solaris Enterprise System license. Support options are available with product license. (A 90 day trial license is no longer needed.)
Message Queue Enterprise Edition via SunStore, CD, individual license, Java Enterprise System license, Suite license, delivered via Java Enterprise System	Java Enterprise System or Suite download center, media	Solaris Enterprise System or Suite download center, media fulfillment	No change.

Interface Changes to the C-API and C Client Runtime

New function: MQGetDestinationName()
MQGetDestinationName (const MQDestinationHandle destinationHandle, MQString * destinationName);
Use this function to get the name of a destination. The returned destinationName is a copy that the caller is responsible for freeing by calling the MQFreeString() function.

Parameters

destinationHandle

A handle to the destination whose name you want to know.

destinationName

The output parameter for the name.

This function is useful when using the reply-to pattern. You can use the MQGetMessageReplyTo function to obtain a handle to the destination where the message should be sent. You can then use the MQGetDestinationName to get the name of that destination. Having obtained the destination name, you can do message processing based on the name.

New enumerated value: MQ_MESSAGE

The new MQMessageType, MQ_MESSAGE, allows C clients to exchange JMS messages of type Message with other Message Queue clients (both C and Java):

typedef enum _MQMessageType {MQ_TEXT_MESSAGE = 0, 
                             MQ_BYTES_MESSAGE = 1,
                             MQ_MESSAGE = 3, 
                             MQ_UNSUPPORTED_MESSAGE = 2} MQMessageType;

The MQ_MESSAGE type identifies messages that have a header and properties but no message body. You use the MQCreateMessage() function to create a message of this type.

A new connection property, MQ_UPDATE_RELEASE_PROPERTY, that specifies the update release version for the installed version of Message Queue. Use the MQGetMetaData() function to obtain version information.

Persistent Store Format Changes

Two changes to the Message Queue persistent store format have been made to improve performance. One change is to the file store, the other to the JDBC store.

Transaction Information in the file store

The format of transaction state information stored in the Message Queue file-based persistent store has been changed to reduce disk I/O and improve the performance of JMS transactions.
Oracle JDBC Store

In previous versions of Message Queue, the store schema used with Oracle used the LONG RAW data type to store message data. In Oracle 8, Oracle introduced the BLOB data types and deprecated the LONG RAW type. Message Queue 3.7 UR1 switches to the BLOB data type to improve performance and supportability.

Because these changes impact store compatibility, the store version has been changed from 350 to 370. Message Queue 3.7 UR1 supports automatic conversion of the persistent store from the older 200 and 350 versions to the 370 version - both for JDBC and for file based stores. The first time imqbrokerd starts, if the utility detects an older store it will migrate the store to the new format, leaving the old store behind.

If you should need to roll back this upgrade, you can uninstall Message Queue 3.7 UR1 and then reinstall the version you were previously running. Since the older copy of the store is left intact, the broker can run with the older copy of the store.

Hardware and Software Requirements

Hardware and software requirements for Message Queue are provided in the Sun Java Enterprise System Installation Guide.

Working with Solaris 10 Zones

A zone is a Solaris Container technology that provides separate environments on a machine and logically isolates applications from one another. Zones allow you to create virtual operating system environments within an instance of the Solaris operating system. Running applications in different zones allows you to run different instances or different versions of the same application on the same machine while, at the same time, permitting centralized administration and efficient sharing of resources.

This section provides a brief description of zones and describes their use with Message Queue 3.7 UR1.

Zones Basics

A zone environment includes a global zone and one or more non-global zones. When Solaris 10 is first installed on a system there is only one global zone. An administrator can create other non-global zones as children of the global zone. Each zone appears as an independent system running Solaris. Each zone has its own IP address, own system configuration, own instances of running applications, and its own area on the file system.

The global zone contains resources that can be shared among non global zones; this allows the centralization of certain administrative functions. For example, packages installed in the global zone are available (propagated) to all existing non-global zones. This enables you to centralize life-cycle management like installation, upgrade, and uninstallation. At the same time, the isolation provided by non-global zones results in greater security and allows you to have differently configured instances or different versions of the same application running on the same machine.

Non-global zones are either whole root zones or sparse root zones: which of these you choose as an environment for an application depends on how you want to balance administrative control with resource optimization.

Whole root zones contain a read/write copy of the file system on the global zone. Packages installed in the global zone are automatically copied (with their registry information) to the whole root zones. This maximizes administrative control, at the expense of resources.
Sparse root zones contain a read/write copy of a portion of the file system on the global zone; other file systems are mounted as read-only file systems. Packages installed in the global zone are available to sparse root zones by means of read-only file systems and through the automatic synchronization of registry information. Sparse root zones optimize resource sharing at the cost of centralized administration.

Java Enterprise System Zones Limitations

The components that make up the Java Enterprise System depend on some shared components; this creates some limitations in working with zones. In a zones environment, shared components are governed by the following rules.

All shared components within a zone must be of the same JES version. This requirement has three consequences.
- If you want to install different versions of shared components, each version must reside in a separate zone.
- Within a zone, if a shared component is upgraded or a later version is installed then all shared components must be upgraded.
- When you install shared components in the global zone, you must take care that shared components in non global zones are upgraded if necessary.
Shared components cannot be installed in sparse root zones because of the read/only file system in sparse root zones. Instead, they must be installed in the global zone. Those product components that depend on shared components must first be installed in the global zone and then propagated into non-global zones.

These requirements affect the installation of Message Queue because it is a component product of Java Enterprise System and, as such, is limited in its use of zones.

Note –

The Message Queue product is installed into the /usr directory and must therefore be installed or upgraded in the global zone first.

Message Queue Cases

When Message Queue is installed in the global zone, it is set to propagate into all of the non-global zones. After installing Message Queue in the global zone, you will have the same version of Message Queue installed in all zones: if you log into any zone and run the command pkginfo -l SUNWiqu, you will see it installed, and it will be the same version as in the global zone. You can then run independent instances of the Message Queue broker in each zone since they do not share the instance and configuration data kept in the /var and /etc directories. (Most other Java Enterprise System components are not propagated if they are installed in the global zone.)

Because Message Queue is propagated into non-global zones, the global instance is forever linked to the installations in the non-global zones. Therefore, any time you uninstall or upgrade Message Queue in the global zone it will impact instances running in the non-global zones. The following example shows how this might cause unintended results.

You install Message Queue 3.7 UR1 in the global zone. This results in the Message Queue 3.7 UR1 packages also being installed into all non-global zones.
You uninstall Message Queue 3.7 UR1 in a whole root zone. Then, you install Message Queue 3.6 in the whole root zone.

You now have different versions of Message Queue running in different zones, which is a set up you might find useful.
You uninstall Message Queue 3.7 UR1 in the global zone. This will uninstall Message Queue from all other zones - including the Message Queue 3.6 instance in the whole root zone.

Always be aware of the cascading effect of installing or uninstalling Message Queue in the global zone.

The following two use-cases explain how you install different instances and different versions of Message Queue in different zones.

Note –

If you want to install Message Queue in a whole root zone on Solaris 10, Solaris 10U1, or Solaris 10U2, you must upgrade Lockhart in the global zone first. See the workaround for bug 645030 for additional information.

To Install the Same Version of Message Queue in Different Zones

Install the desired version of Message Queue in the global zone.

These versions will be propagated into any existing non-global zone. If you create additional non-global zones, Message Queue will also be propagated into these zones. (You can install different instances in whole root zones as well as sparse root zones, but using sparse root zones allows you to make more efficient use of disk space and other resources).

If you want Message Queue to be propagated into any other non-global zones, create these zones now.

Run an instance of Message Queue in each non-global zone.

To Install Different Versions of Message Queue in Different Zones

Uninstall Message Queue from the global zone.

Create whole root zones and configure each zone not to share the /usr directory by using the following directive when you create the zone
```
remove inherit-pkg-dir dir=/usr
```

Install different versions of Message Queue in each whole root zone.

Note –
Remember that installing or uninstalling Message Queue in the global zone will affect all instances (and versions) of Message Queue running in whole root zones.