Chapter 10 Message Queue

This chapter describes how to upgrade Message Queue software from previous Java ES versions to Java ES 5 (Release 5): Sun Java System Message Queue 3.7 UR1.

The chapter provides an overview of upgrade considerations for the different upgrade paths supported by Release 5. The chapter covers upgrades on both the Solaris and Linux operating systems:

Overview of Message Queue Upgrades

Upgrading Message Queue from Java ES Release 4

Upgrading Message Queue from Java ES Release 3

Upgrading Message Queue from Java ES Release 2



Note	File locations in this chapter are specified with respect to a fixed directory path referred to as MessageQueue-base. The value of MessageQueue-base depends on operating system platform:, as shown in the following table.

Table 10-1 Message Queue Directory Paths
Path Name Variable	Solaris OS	Linux OS
MessageQueue-base	/usr/bin	/opt/sun/mq/bin

Overview of Message Queue Upgrades

This section describes the following general aspects of Message Queue that impact upgrading to Java ES 5 (Release 5):

About Java ES Release 5 Message Queue

Java ES Release 5 Message Queue represents minor upgrade with respect to Release 4. It includes mostly code fixes with no minor features enhancements.

Message Queue software has historically included two editions, a Platform Edition and an Enterprise Edition, each corresponding to a different feature set and licensed capacity. Enterprise Edition was for deploying and running messaging applications in an enterprise production environment. Platform Edition was mainly for developing, debugging, and load testing messaging applications and components. With Release 5 Message Queue, the Platform Edition is deprecated and Message Queue includes all Enterprise Edition features. An upgrade from an earlier Java ES release version to Release 5 converts any installed Platform Edition to full Message Queue enterprise-level features.

Message Queue Upgrade Roadmap

Table 10-2 shows the supported Message Queue upgrade paths to Java ES Release 5. The table applies to both Solaris and Linux operating systems.

Table 10-2 Upgrade Paths to Java ES 5 (Release 5): Message Queue 3.7 UR1
Java ES Release	Message Queue Version	General Approach	Reconfiguration Required
Release 4	Sun Java System Message Queue 2005Q4 (3.6 SP3)) Enterprise Edition only	Direct upgrade: Performed using Java ES installer.	Data conversion performed automatically.
Release 3	Sun Java System Message Queue 2005Q1 (3.6) Enterprise Edition only	Direct upgrade: Performed using Java ES installer.	Data conversion performed automatically.
Release 2	Sun Java System Message Queue 2004Q2 (3.5 SP1) Platform and Enterprise Editions	Direct upgrade: Performed using the mqupgrade script.	Performed automatically on Solaris platforms, and an mqmigrate script is available on Linux platforms.
Release 1	Sun Java System Message Queue 2003Q4 (3.0.1 SP2) Platform and Enterprise Editions	Direct upgrade not certified: But can be performed using the mqupgrade script.1	Performed automatically on Solaris platforms, and an mqmigrate script is available on Linux platforms.
Pre-dates Java ES releases	Sun Java System Message Queue 3.0.x and earlier versions Platform and Enterprise Editions	Direct upgrade not certified: But can be performed using Java ES installer.

1Back up and then restoration of the following files might be required before and after running the mqupgrade script: for example (on Solaris OS): restoring /etc/imq/passwd and /etc/imq/accesscontrol.properties to /var/imq/instances/instanceName/etc/

In addition to the Java ES releases of Message Queue shown in Table 10-2, Message Queue is also bundled with Solaris OS software. Upgrade of the bundled versions of Message Queue to Release 5 can be performed using the Java ES installer.

Message Queue Data

Message Queue, like other Java ES components, makes use of various kinds of data that for any specific upgrade might need to be migrated to an upgraded version. The following table shows the type of data that could be impacted by an upgrade of Message Queue software.

Table 10-3 shows the location of data on Solaris systems. The location on Linux systems is similar, but depends on the version of Message Queue:

In Table 10-3, instanceName identifies the name of the Message Queue broker instance with which the data is associated.

Table 10-3 Message Queue Data Usage (Solaris OS)
Data Category	Location (on Solaris)	Usage
Broker instance configuration properties	/var/imq/instances/instanceName/props/ config.properties	Broker and related services configurations
Persistent store for dynamic application data	Release 2, Release 3, & Release 4: /var/imq/instances/instanceName/fs350/ Release 5: /var/imq/instances/instanceName/fs370/ or a JDBC-accessible data store	Stores messages, destinations, durable subscriptions, transactions, and other dynamic data
Administered objects (object store)	local directory of your choice or an LDAP Directory Server	Objects used to configure client/broker connections
Security: user repository	/var/imq/instances/instanceName/etc/passwd or an LDAP directory server	Stores user data used for authentication and authorization
Security: access control file (default location)	/var/imq/instances/instanceName/etc/ accesscontrol.properties	Sets the rules that authorize user access to destinations and related capabilities
Security: passfile directory (default location)	/var/imq/instances/instanceName/etc/	Stores encrypted password information.
Security: broker’s keystore file location	/etc/imq/	Stores encrypted certificate information for secure messaging.

Message Queue Upgrade Strategy

Your strategy for upgrading Message Queue generally depends on the many issues discussed in Chapter 1, "Planning for Upgrades": upgrade path, dependencies between Java ES components, selective upgrade versus upgrade all, multi-instance deployments, and so forth.

This section is to particularize that general discussion to Message Queue by presenting issues that might influence your Message Queue upgrade plan.

Compatibility Issues

Release 5 Message Queue introduces no new incompatibilities over Release 3 or Release 4. However, there are significant compatibility issues with respect to Release 2 and earlier versions. These are discussed in Release 2 Compatibility Issues.

In addition, as a general rule, if you mix Release 4 and earlier Message Queue brokers and Release 5 Message Queue brokers in a cluster, the master broker must be the earlier release broker, and the cluster will run as the earlier release Message Queue cluster.

Message Queue Dependencies

Message Queue dependencies on other Java ES components can impact the procedure for upgrading and re-configuring Message Queue software. Changes in Message Queue interfaces or functions, for example, could require upgraded version of components upon which Message Queue depends. The need to upgrade such components depends upon the specific upgrade path.

Shared components. Message Queue has dependencies on specific Java ES shared components (see Table 1-9).

Directory Server. Message Queue has an optional dependency on Directory Server: you can configure Message Queue to store administered objects and/or user data in an LDAP directory (Directory Server) rather than locally.

Web Container. Message Queue has an optional dependency on Web Server, Application Server, or a third-party web container to support HTTP messaging between client and broker.

Databases. Message Queue has an optional dependency on Java DB (or third-party databases) to provide JDBC-accessible data store, rather than a flat-file message store, for the Message Queue persistence layer.

Sun Cluster. Message Queue has an optional dependency on Sun Cluster to provide high availability support.

Dual Upgrade

Fresh Operating System Installation

Back up existing Message Queue data.

See Message Queue Data for the location of essential data.

Install the new operating system.

The operating system installation can be on a new system (or a Solaris 10 zone) or it can wipe out the existing file system.

Install Release 5 Message Queue.

Restore or migrate the Message Queue data that was backed up in Step 1.

When upgrading from Release 2 Message Queue on Linux, the data is restored to the Release 5 location.

In-place Operating System Upgrade

Back up existing Message Queue data.

See Message Queue Data for the location of essential data.

Upgrade the operating system.

The upgrade leaves the existing file system in place.

Upgrade to Release 5 Message Queue.

See the appropriate section of this chapter, depending on your upgrade path. the upgrade should leave the existing Message Queue data in tact.

When upgrading from Release 2 Message Queue on Linux, however, the data must be moved to the Release 5 location.

Upgrading Message Queue from Java ES Release 4

This section includes information about upgrading Message Queue from Java ES 2005Q4 (Release 4) to Java ES 5 (Release 5). The section covers the following topics:

Introduction

When upgrading Java ES Release 4 Message Queue to Release 5, consider the following aspects of the upgrade process:

General Upgrade Approach. The upgrade is performed using the Java ES installer. The installer migrates configuration data from Release 4 automatically. In addition, any dynamic application data associated with Release 4 will be converted automatically the first time imqbrokerd is run. For a file-based store, this means the contents of the fs350 directory will be copied to a new fs370 directory. For a JDBC store, a simple version update will occur to the existing database tables.

Upgrade Dependencies. Message Queue has dependencies on a number of Java ES shared components (see Table 1-9), all of which are automatically upgraded to Release 5 by the Java ES installer when you perform an upgrade of Message Queue.

Release 4 Message Queue Upgrade

This section describes how to perform a Message Queue upgrade from Java ES Release 4 to Java ES Release 5:

Pre-Upgrade Tasks

Before you upgrade Message Queue software you should perform the following tasks:

Verify Current Version Information

You can determine the version and edition of Message Queue installed on your system by starting the Message Queue broker with the -version option:

Table 10-4 Message Queue Version Verification Outputs
Java ES Release	Message Queue Version Number
Release 2	Sun Java(tm) System Message Queue 3 2004Q2 Version: 3.5
Release 3	Sun Java(tm) System Message Queue 3 2005Q1 Version: 3.6
Release 4	Sun Java(tm) System Message Queue 3 2005Q4 Version: 3.6 SP3
Release 5	Sun Java(tm) System Message Queue 3.7 Version: 3.7 UR1

Upgrade Message Queue Dependencies

It is generally recommended that all Java ES components on a computer system (and in a computing environment) be upgraded to Java ES Release 5. Message Queue has hard upgrade dependencies on only a couple of shared components.

When upgrading Message Queue dependencies, you should do so in the order below (skipping any that might already have been upgraded), before you upgrade Message Queue. Upgrade of shared components is achieved automatically by the Java ES installer.

Shared Components. Instructions for synchronizing Java ES shared components to Release 5 are provided in Upgrading Java ES Shared Components. However, all shared components required by Message Queue are upgraded automatically by the Java ES installer when you perform an upgrade of Message Queue to Release 5.

Sun Cluster (soft upgrade dependency). Instructions for upgrading Sun Cluster to Release 5 are provided in Chapter 3, "Sun Cluster Software".

Directory Server (soft upgrade dependency). Instructions for upgrading Directory Server to Release 5 are provided in Chapter 5, "Directory Server".

Java DB (soft upgrade dependency). You need to perform a fresh install of Release 5 Java DB when upgrading Message Queue.

Web Container Software (soft upgrade dependency). Instructions for upgrading Web Server or Application Server are provided in Chapter 7, "Web Server" and Chapter 11, "Application Server", respectively.

Back Up Message Queue

It is always a good practice to back up application data in a production environment before performing an upgrade. Note the location of the persistent store for dynamic application data indicated in Table 10-3.

Upgrading Release 4 Message Queue

Stop any running Message Queue client applications.

If Message Queue is being used in an Application Server environment, shut down Application Server, as well.

Stop any running brokers. You will be prompted for the admin user name and password.

imqcmd shutdown bkr [-b hostName:port]

If you do not want to preserve dynamic data, the Message Queue flat-file user repository, and the Message Queue access control file associated with each broker instance, remove this data using the following command.

imqbrokerd -name instanceName -remove instance

Otherwise, dynamic data and configuration information will be retained and used for Release 5 Message Queue.

su -

Launch the Java ES installer.

cd Java ES Release 5 distribution/os_arch
./installer

where os_arch matches your platform, such as Solaris_sparc. (Use the installer -nodisplay option for the command line interface.)

After the Welcome and License Agreement pages are displayed, you will be presented with a component selection page. (When installed components are detected that can be directly upgraded by the Java ES installer, they are shown with a status of “upgradable.”)

Select Message Queue in the component selection page.

Confirm your upgrade choice.

Message Queue packages will be upgraded and an upgrade summary displayed.

Exit the Java ES installer.

Verifying the Message Queue Upgrade

After you finish the upgrade procedure, verify that it was successful by starting the Message Queue broker with the -version option.

The command returns the Java ES version number as well as the Message Queue-specific version number.

Post-Upgrade Tasks

If you have upgraded the web container and are using the Message Queue HTTP tunneling servelet, you may need to re-deploy it in the new web container. There has been no change to the HTTP tunneling servlet between Release 4 and Release 5. For more information on HTTP support, see the Message Queue 3.7 UR1 Administration Guide, http://docs.sun.com/doc/819-4467.

Also, if you are sure you will not need to roll back the upgrade, you can remove the Release 4 file-based data store located in the fs350 directory (see Table 10-3).

Rolling Back the Upgrade

No scripts are provided for rolling back Message Queue to its pre-upgrade state. The process must be performed manually using the following steps:

Stop any running Message Queue client applications.

Stop any running brokers. You will be prompted for the admin user name and password.

imqcmd shutdown bkr [-b hostName:port]

If you want to delete dynamic data, the Message Queue flat-file user repository, and the Message Queue access control file associated with each broker instance, remove this data using the following command.

imqbrokerd -name instanceName -remove instance

su -

Retrieve the list of installed Message Queue packages with the following command:

On Solaris:
pkginfo | grep -i "message queue"

On Linux:
rpm -qa | grep mq

Remove the Message Queue packages, using the following command:

On Solaris:
pkgrm packageName
where packageName is any of the Message Queue packages. To remove multiple packages, separate the package names by a space.

On Linux:
rpm -e --nodeps RPMName
where RPMName is any of the Message Queue rpm components. To remove multiple components, separate the RPM names by a space.

Because other products might be using Message Queue packages, be careful about removing them. The pkgrm command will warn you of any dependencies on a package before removing it. When prompted, confirm your removal request by typing y (yes).

Type “q” to quit.

Exit the root shell.

Re-install Release 4 Message Queue.

Use the Java ES Release 4 installer.

Restore Release 4 Message Queue data backed up in Back Up Message Queue.

Release 4 Message Queue will work fine with data backed up before the upgrade to Release 5.

Multiple Instance Upgrades

To upgrade a Message Queue cluster, in which multiple brokers interact to provide a scalable message service, you can do a rolling upgrade in which the cluster remains online as each Message Queue instance is upgraded from Release 4 to Release 5. The two conditions to keep in mind when performing a cluster upgrade are:

Otherwise the procedure is straightforward: you shut down, upgrade, and restart the brokers one at a time until all have been upgraded.

Upgrading Message Queue from Java ES Release 3

The procedure for upgrading Java ES 2005Q1 (Release 3) Message Queue to Release 5 is the same as that for upgrading Release 4 Message Queue to Release 5.

Upgrading Message Queue from Java ES Release 2

This section includes information about upgrading Message Queue from Java ES 2004Q2 (Release 2) to Java ES Release 5. The section covers the following topics:

Introduction

Release 2 Compatibility Issues

Release 2 Message Queue Upgrade

Multiple Instance Upgrades



Note	If you are upgrading from Release 2 Message Queue on the Linux platform, then you will have to perform a dual upgrade, in which both Message Queue and the operating system are upgraded (Release 5 Message Queue is not supported on RHEL 2.1). See Dual Upgrade for more information.

Introduction

When upgrading Java ES Release 2 Message Queue to Release 5, consider the following aspects of the upgrade process:

Backward Compatibility. Release 5 Message Queue is not fully compatible with Release 2, as described in Release 2 Compatibility Issues, below.

Upgrade Rollback. Rollback from Release 5 to Release 2 is not currently supported (see Rolling Back the Upgrade).

Platform Issues. The general approach for upgrading Message Queue is the same on both Solaris and Linux operating systems, however there are some additional procedures required on Linux. The procedures that follow indicate platform-specific commands, file locations, or procedures where appropriate.

Release 2 Compatibility Issues

Release 5 Message Queue introduces the following general Message Queue compatibility issues with respect to Release 2 and earlier versions.

Protocol Compatibility

Message Queue has a dependency on a web container to provide HTTP protocol support between Message Queue clients and broker. Due to a protocol change, when using Sun Java System Web Server to provide a web container for the Message Queue imqhttp.war application, you cannot upgrade the Web Server component without also upgrading Message Queue (see Post-Upgrade Tasks on (more...) and (more...) .

Broker Compatibility

A Release 5 Message Queue broker will inter-operate with a Release 4, Release 3, or Release 2 broker, however changes in broker properties and the persistent store schema with respect to Release 2 can impact compatibility.

Release 5 Message Queue can use Release 4, Release 3, and Release 2 data, except that on Linux systems, Release 2 data must be first migrated to Release 5.

You can use earlier Message Queue config.properties files. You can also copy them to another location and consult the property settings they contain when you configure Release 5 Message Queue brokers.

Any persistent Message Queue data—messages, destinations, durable subscriptions—is automatically converted, if necessary, to Release 5 Message Queue data when starting up a broker for the first time. For example, any existing destinations will be converted, if necessary, to Release 5 Message Queue destinations, preserving existing attributes and using default values of new attributes.

If you mix Message Queue Release 2 brokers and Message Queue Release 5 brokers in a cluster, the master broker must be a Message Queue Release 2 broker (whichever is older), and the cluster will run as a Message Queue Release 2 cluster.

Administered Object Compatibility

Release 5 Message Queue administered objects are identical to Release 3 and Release 4 administered objects. However, some Release 3 administered objects were renamed or enhanced with new attributes with respect to earlier versions. Therefore, when upgrading from Release 2 Message Queue to Release 5, you should consider the following:

You can use the same object store and administered objects that you created in Release 2; however, it is best to migrate your administered objects to Release 5. The Administration Console (imqadmin) and the ObjectManager command line utility (imqobjmgr), when performing an update operation, will convert Release 2 administered objects into Release 5 administered objects.

The Release 5 client runtime will look up and instantiate Release 2 administered objects and convert them for use by Release 5 clients. However, this will not convert Release 2 administered objects residing in the object store from which the lookup was made.

Existing Release 2 clients (applications and/or components)—that is, clients that directly instantiate administered objects rather than look them up—are compatible with Release 5. However, if they are to use the new administered object attributes (see Chapter 16 of the Message Queue 3.7 UR1 Administration Guide, http://docs.sun.com/doc/819-4467 for information on administered object attributes), they will need to be rewritten. (Re-compiling Release 2 clients with Release 5 will show which Message Queue Release 2 attributes have been renamed in Release 5. The old names will still work.)

Scripts that start Java clients and which set administered object attribute values using command line options are compatible with Release 5. However, if they are to use the new administered object attributes (see Chapter 16 of the Message Queue 3.7 UR1 Administration Guide, http://docs.sun.com/doc/819-4467 for information on administered object attributes), they will need to be rewritten.

Administration Tool Compatibility

Because of the addition of new commands and new administrative capabilities in Release 3, the Release 5 administration tools (the Administration Console and command line utilities) only work with Release 3, Release 4, and Release 5 brokers. However, all Release 2 commands and command options remain supported.

Client Compatibility

Release 3 and Release 4 clients are completely compatible with Release 5 Message Queue. When upgrading from Release 2 to Release 5, however, you should consider the following compatibility issues, regarding Java clients:

Release 2 Message Queue Upgrade

This section describes how to perform a Message Queue upgrade from Java ES Release 2 to Java ES Release 5:

Pre-Upgrade Tasks

Before you upgrade Message Queue software you should perform the following tasks:

Verify Current Version Information

You can determine the version and edition of Message Queue installed on your system by starting the Message Queue broker with the -version option:

Table 10-5 Message Queue Version Verification Outputs
Java ES Release	Message Queue Version Number
Release 2	Sun Java(tm) System Message Queue 3 2004Q2 Version: 3.5
Release 3	Sun Java(tm) System Message Queue 3 2005Q1 Version: 3.6
Release 4	Sun Java(tm) System Message Queue 3 2005Q4 Version: 3.6 SP3
Release 5	Sun Java(tm) System Message Queue 3.7 Version: 3.7 UR1

Upgrade Message Queue Dependencies

When upgrading Message Queue dependencies, you should do so in the order below (skipping any that might already have been upgraded), before you upgrade Message Queue.

Shared Components. Instructions for upgrading Java ES shared components to Release 5 are provided in Chapter 2, "Upgrading Java ES Shared Components").

Sun Cluster (soft upgrade dependency). Instructions for upgrading Sun Cluster to Release 5 are provided in Chapter 3, "Sun Cluster Software".

Directory Server (soft upgrade dependency). Instructions for upgrading Directory Server to Release 5 are provided in Chapter 5, "Directory Server".

Java DB (soft upgrade dependency). You need to perform a fresh install of Release 5 Java DB when upgrading Message Queue.

Back Up Message Queue

It is always a good practice to back up application data in a production environment before performing an upgrade. For Solaris OS, dynamic data is stored in the following directory:
/var/imq/instances/instanceName.

Upgrading Release 2 Message Queue (Solaris)

The upgrade of Message Queue software to Java ES Release 5 makes use of the mqupgrade script, which installs Release 5 packages.

Stop any running Message Queue client applications.

If Message Queue is being used in an Application Server environment, shut down Application Server, as well.

Stop any running brokers. You will be prompted for the admin user name and password.

imqcmd shutdown bkr [-b hostName:port]

imqbrokerd -name instanceName -remove instance

Otherwise, dynamic data and configuration information will be retained and used for Release 5 Message Queue.

su -

Change directories to the location of the Tools directory of the Java ES Release 5 distribution.

On Solaris SPARC:
cd Solaris_sparc/Product/message_queue/Tools

On Solaris x86:
cd Solaris_x86/Product/message_queue/Tools

Run the mqupgrade script.

Start the script:

./mqupgrade

The mqupgrade script lists installed Message Queue components.

Enter y (yes) to upgrade Message Queue components.

The mqupgrade script detects and lists installed localization files.

If you do not want to upgrade Message Queue components, enter n (no). The mqupgrade script will exit without upgrading Message Queue components.

If prompted, enter y (yes) to upgrade localization files.

The mqupgrade script sends output to a log file in the following location:

/var/sadm/install/logs/Message_Queue_upgrade_'date'.log

Upgrading Release 2 Message Queue (Linux)

The upgrade of Release 2 Message Queue to Release 5 on the Linux platform is complicated by the fact that Java ES Release 2 is supported only on RHEL 2.1, but Java ES Release 5 is not supported on RHEL 2.1. Hence a dual upgrade is required: both the operating system and Message Queue must be upgraded. See Dual Upgrades: Java ES and Operating System Softwared

The basic procedure is to upgrade the Linux OS first, then upgrade all the Message Queue dependencies, and then upgrade Message Queue.

The upgrade from Release 2 Message Queue to Release 5 includes a data migration step that is not needed on Solaris systems, namely the migration of broker instance data to the appropriate Release 5 location. If you want to preserve your Release 2 data in upgrading to Release 5, Message Queue provides a migration tool, mqmigrate, to perform this migration.

To upgrade from Release 2 to Release 5, you use the same instructions as used in Upgrading Release 2 Message Queue (Solaris), except you run the mqmigrate script (Step 6) before you run the mqupgrade script (Step 7), as detailed in the following procedure.

Stop any running Message Queue client applications.

Stop any running brokers. You will be prompted for the admin user name and password.

imqcmd shutdown bkr [-b hostName:port]

imqbrokerd -name instanceName -remove instance

Otherwise, dynamic data and configuration information will be retained and used for Release 5 Message Queue.

su -

Change directories to the location Tools directory of the Java ES Release 5 distribution.

cd Linux_x86/Product/message_queue/Tools

Migrate broker instance data using the following command:

./mqmigrate

The mqmigrate script will move Release 2 broker instance configuration data to the appropriate R4 location.

Run the mqupgrade script.

Start the script:

./mqupgrade

The mqupgrade script lists installed Message Queue components.

Enter y (yes) to upgrade Message Queue components.

The mqupgrade script detects and lists installed localization files.

If you do not want to upgrade Message Queue components, enter n (no). The mqupgrade script will exit without upgrading Message Queue components.

If prompted, enter y (yes) to upgrade localization files.

The mqupgrade script sends output to a log file in the following location:

/var/sadm/install/logs/Message_Queue_upgrade_'date'.log

Installing the Compatibility Package (Linux)

If you have scripts or your Release 2 client applications contain scripts that depend on the location of Release 5 installed files, you will need to install the sun-mq-compat package, which contains symlinks from Release 2 file locations to Release 5 file locations.

The sun-mq-compat package is in the following location where you unzipped the Java ES Release 5 distribution.

Verifying the Message Queue Upgrade

After you finish the upgrade procedure, verify that it was successful by starting the Message Queue broker with the -version option.

The command returns the Java ES version number as well as the Message Queue-specific version number.

Post-Upgrade Tasks

If you are using the HTTP tunneling servlet to provide HTTP connection service support, the upgrade of Message Queue from Release 2 to Release 5 has upgraded the servlet. This requires you to re-deploy it after upgrading Message Queue to Release 5. See the Message Queue 3.7 UR1 Administration Guide, http://docs.sun.com/doc/819-4467 for more information on HTTP support.

Also, you have to migrate Release 2 administered objects to their Release 5 versions using the Administration Console (imqadmin) and/or the ObjectManager command line utility (imqobjmgr) to perform an update operation.

Rolling Back the Upgrade

The upgrade of Message Queue from Release 2 to Release 5 is not currently supported. Normally the procedure would be similar to the rollback from Release 5 to Release 4 (see Rolling Back the Upgrade). However, because the upgrade of Message Queue from Release 2 to Release 5 does not update the Java ES product registry, the Java ES installer cannot re-install Release 2 Message Queue.

Multiple Instance Upgrades

To upgrade a Message Queue cluster, in which multiple brokers interact to provide a scalable message service, you can do a rolling upgrade in which the cluster remains online as each Message Queue instance is upgraded from Release 2 to Release 5. The two conditions to keep in mind when performing a cluster upgrade are:

Otherwise the procedure is straightforward: you shut down, upgrade, and restart the brokers one at a time until all have been upgraded.

Previous Contents Index Next
Sun Java Enterprise System 5 Upgrade Guide for UNIX