Sun Java System Message Queue 4.1 Release Notes

Known Issues and Limitations

This section contains a list of the known issues with Message Queue 4.1. The following product areas are covered:

For a list of current bugs, their status, and workarounds, Java Developer Connection™ members should see the Bug Parade page on the Java Developer Connection web site. Please check that page before you report a new bug. Although all Message Queue bugs are not listed, the page is a good starting place if you want to know whether a problem has been reported.

http://bugs.sun.com/bugdatabase/index.jsp

Note –

Java Developer Connection membership is free but requires registration. Details on how to become a Java Developer Connection member are provided on Sun’s “For Developers” web page.

To report a new bug or submit a feature request, send mail to imq-feedback@sun.com.

Installation Issues

This section describes issues related to the installation of Message Queue version 4.1.

Product Registry and JES

Version 4.1 of Message Queue is installed by a new installer, which also installs and upgrades the shared components that Message Queue needs; for example, JDK, NSS libraries, JavaHelp, and so on. This installer and the Java Enterprise System (JES) installer do not share the same product registry. If a version of Message Queue that was installed with JES is removed and upgraded to Message Queue 4.1 by the Message Queue installer, the JES product registry may be in an inconsistent state. As a result, when the JES uninstaller is run, it may inadvertently remove Message Queue 4.1 and the shared components upon which it depends, which it did not install.

The best way to upgrade software that was installed by the JES installer is as follows.

Use the JES uninstaller to remove Message Queue and its shared components.
Use the Message Queue installer to install Message Queue 4.1.

Selecting the Appropriate JRE

The Message Queue 4. 1 Installer JDK Selection Screen allows you to select existing JDK/JRE's on the system for use by Message Queue. Unfortunately, the list shown also includes the JRE used to run the installer application. This JRE is part of the installer bundle and is not really installed on the system. (Bug 6585911)

The JRE used by the installer is recognizable by its path, which should be within the unzipped installer directory and should include the subdirectory mq4_1–installer. For example:

some_directory/mq4_1–installer/usr/jdk/instances/jdk1.5.0/jre

Do not select this JRE for use by Message Queue. Instead, select another JDK on the system. If one does not exist, take the action appropriate for your platform.

Solaris or Linux: Select “Install and use the default JDK”.
Windows: Download and install a JDK before running the Message Queue 4.1 installer.

Installing on Windows

When installing Message Queue on Windows, please note the following limitations.

The installer does not add entries for Message Queue to the Start>Programs menu (Bug 6567258). To start the administration console use the command line as shown in Starting the Administration Console in Sun Java System Message Queue 4.1 Administration Guide.
The installer does not add the IMQ_HOME\mq\bin directory to the PATH environment variable.(Bug 6567197). Users need either to add this entry to their PATH environment variable or provide a full path name when invoking Message Queue utilities (IMQ_HOME\mq\bin\command).
The installer does not add entries to the Windows registry to indicate that Message Queue is installed.
When run in silent mode, the installer returns right away. The installation does happen; but the user has no way of knowing when the silent installation is actually done. (Bug 6586560)
Text mode (installer –t) is not supported on Windows. Running the installer in text mode on Windows causes an error message to be displayed. This message is displayed in English even when the installer is run in non-English locales. (Bug 6594142)
The string “Install Home” displayed on the Installer Install Home screen is shown in English even when the installer is run in non-English locales. (Bug 6592491)

Installing on Solaris

The error message and “incomplete” summary status misleads user trying to install using the installer-n command. The command actually succeeds. (Bug 6594351)

Installing on Linux

The following issues affect installation on the Linux Platform

On the JDK Selection panel, the scroll list displays only one item. This makes it difficult to select other JDK's in the list. (Bug 6584735)
If the JDK is current and the user selects “Install default JDK” on the JDK Selection Screen, the installer still tries to install it and reports that it cannot install the package. Installation completes successfully despite this issue. (Bug 6581310)
When the installer is run in dry run mode (installer –n), the Summary Screen shows some error messages and also displays an install status of “Incomplete”. This is incorrect and misleading; a dry run does not install anything on the system; it only creates the answer file that can be subsequently used to install.(Bug 6594351)
If older versions of Message Queue localization RPM's exist on your system, installation of Message Queue 4.1 localization RPM's (which happens when you select the “Install Message Queue multilingual packages” checkbox on the Multilingual Packages screen) will fail. Installation fails because of conflicts with Il8 packages from a previous 3.7 UR1 installation. (Bug 6594381)

Workaround Manually remove the localization RPM's using the rpm –e command before running the 4.1 Installer. To determine which RPM's are relevant here, see Message Queue Packages (RPMs) in Sun Java System Message Queue 4.1 Installation Guide.

Installing on All Platforms

These issues affect installation on all platforms.

When the Installer is in the process of installing Message Queue 4.1 and the Progress screen is displayed, the Cancel button is active. Selecting the Cancel button at this time results in incomplete or broken installs. (Bug 6595578)
The Installer Summary Screen contains a number of links that when clicked will launch a log or summary page viewer. If you dismiss this viewer window using the window close button “X” instead of the button labelled “close', you will not be able to bring this viewer window back up. (Bug 6587138)

Workaround Use the button labeled Close to close the window.
When a system has older versions of Message Queue and NSS/NSPR, the Installer's Upgrade only lists Message Queue needing upgrade; it does not mention that NSS/NSPR need to be upgraded. This only an issue with the Update screen as all the relevant software will be upgraded as part of the installation process (as indicated by The ReadyToInstall screen which shows the correct information). (Bug 6580696)

Workaround None needed as the NSS/NSPR files are installed if they are not current, and the older versions are unistalled.
When the Installer or Uninstaller is run in text mode (installer –t), the Summary screen shows the directory containing the log/summary files but does not list the names of these files. (Bug 6581592)
Specifying the name of a file that does not exist, produces inconsistent and unclear error messages. (Bug 6587127)

Version Information

The installer displays Message Queue version information in an opaque form. (Bug 6586507)

On the Solaris platform, refer to the table below to determine the version being installed.

Table 1–11 Version Formats


Version as Displayed by the Installer	Message Queue Release
4.1.0.0	4.1
3.7.0.1	3.7 UR1
3.7.0.2	3.7 UR2
3.7.0.3	3.7 UR3
3.6.0.0	3.6
3.6.0.1	3.6 SP1
3.6.0.2	3.6 SP2
3.6.0.3	3.6 SP3
3.6.0.4	3.6 SP4

Note –

For Patch releases to 3.6 SP4 (for example, 3.6 SP4 Patch 1), the releases string displayed by the installer stays the same. You need to run the command imqbrokerd –version to determine the exact version.

On the Linux platform, it is not possible to provide a simple format translation. The version number displayed by the installer on Linux is in the following form.

<majorReleaseNumber>.<minorReleaseNumber>-<someNumber>

For example, 3.7–22. This tells us that it is one of the 3.7 releases, but not which specific one. To determine that, run the command imqbrokerd —version.

Localization Issues

The following issues relate to localization problems.

When the installer is run in text mode (installer –t), in a non-English locale, multi-byte characters show up as garbage.(Bug 6586923)
The Installer Summary screen allows the user to view a Summary report. Unfortunately, this report (an HTML page) shows garbage when the installer is run in multibyte locales. (Bug 6587112)

Workaround Edit the HTML file to correct the charset specified in it. The HTML file should contain something like the following.

meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8

Replace “UTF-8” with locale_name.UTF-8. For example, ja_JA.UTF-8 or ko.UTF-8 on Solaris; ja_JA.utf8 or ko_KO.utf8 on linux.
On the Installer Progress screen, the progress bar shows strange characters. The tooltip is hard coded in non-English locales. (Bug 6591632)
Text mode (installer –t) is not supported on Windows. Running the installer in text mode on Windows will cause an error message to be displayed. This message is not localized when the installer is run in non-English locales. (Bug 6594142)
The License screen of the installer displays English license text no matter which locale the Installer is run in.(Bug 6592399)

Workaround To access localized license files, look for at the LICENSE_MULTILANGUAGE.pdf file.
Installer usage help text is not localized. (Bug 6592493)
The string “None” that is seen on the Installer summary HTML page is hard coded in English. (Bug 6593089)
The copyright page is not localized for locales other than France. (Bug 6590992)
When the installer is run in a German locale, the Welcome screen does not show the complete text that is seen in other locales. (Bug 6592666)
The string “Install Home” seen on the Installer Install Home screen is not localized. It appears in English even when the installer is run in non-English locales. (Bug 6592491)
When the installer is run in text mode (installer –t), the English response choices “Yes” and “No” are used no matter what locale the installer is run in. (Bug 6593230)
The tooltip for the browse button on the Installer JDK Selection screen is hard coded in English. (Bug 6593085)

Deprecated Password Option

In previous versions of Message Queue, you could use the —p or —password option to specify a password interactively for the following commands: imqcmd, imqbrokerd, and imdbmgr. Beginning with version 4.0, these options have been deprecated. You must furnish passwords as follows.

Set the password property to the desired value in a file used to store only passwords.

Use the following syntax to specify passwords in the password file.

PasswordPropertyName=MyPassword
Pass the name of the password file using the —passfile option.

A password file can contain one or more of the passwords listed below.

A keystore password used to open the SSL keystore. Use the imq.keystore.password property to specify this password.
An LDAP repository password used to connect securely with an LDAP directory if the connection is not anonymous. Use the imq.user_repository.ldap.password property to specify this password.
A JDBC database password used to connect to a JDBC-compliant database. Use the imq.persist.jdbc.vendorName.password property to specify this password. The vendorName component of the property name is a variable that specifies the database vendor. Choices include hadb, derby, pointbase, oracle, or mysql.
A password to the imqcmd command (to perform broker administration tasks). Use the imq.imqcmd.password property to specify this password.

In the following example, the password to the JDBC database is set to abracadabra.

imq.persist.jdbc.mysql.password=abracadabra

You can configure the broker to use the password file you create in one of the following ways.

Set the following properties in the broker's config.properties file.

imq.passfile.enabled=true

imq.passfile.dirpath=MyFileDirectory

imq.passfile.name=MyPassfileName
Use the —passfile option of the imqbrokerd command.

imqbrokerd —passfile MyPassfileName

General Issues

This section covers general issues in Message Queue 4.1. Some of these were introduced with previous Message Queue versions.

When a JMS client using the HTTP transport terminates abruptly (for example, using Ctrl-C) the broker takes approximately one minute before releasing the client connection and all the associated resources.

If another instance of the client is started within the one minute period and if it tries to use the same ClientID, durable subscription, or queue, it might receive a “Client ID is already in use” exception. This is not a real problem; it is just the side effect of the termination process described above. If the client is started after a delay of approximately one minute, everything should work fine.
SOAP clients. Previously the SAAJ 1.2 implementation jar used to refer to mail.jar and mail.jar did not need to be in CLASSPATH. In SAAJ 1.3 this reference was removed; thus, Message Queue clients must put mail.jar explicitly in CLASSPATH.

Administration/Configuration Issues

The following issues pertain to administration and configuration of Message Queue

The imqadmin and imqobjmgr utilities throw an error when the CLASSPATH contains double quotes on Windows machines (Bug ID 5060769).

Workaround You can ignore this error message; the broker correctly handles notifying consumers of any error. This error does not affect the reliability of the system.
The -javahome option in all Solaris and Windows scripts does not work if the value provided contains a space (Bug ID 4683029).

The javahome option is used by Message Queue commands and utilities to specify an alternate Java 2 compatible runtime to use. However, the path name to the alternate Java runtime must not contain spaces. The following are examples of paths that include spaces.

Windows: C:/jdk 1.4

Solaris: /work/java 1.4

Workaround Install the Java runtime at a location or path that does not contain spaces.
The imqQueueBrowserMaxMessagesPerRetrieve attribute specifies the maximum number of messages that the client runtime retrieves at one time when browsing the contents of a queue. Note that the client application will always get all the messages on the queue. Thus, the imqQueueBrowserMaxMessagesPerRetrieve attribute affects how the queued messages are chunked, to be delivered to the client runtime (fewer large chunks, or more smaller chunks), but it does not affect the total messages browsed. Changing the value of this attribute might impact performance, but it will not result in the client application getting more or less data (Bug ID 6387631).

Broker Issues

The following issues affect the Message Queue broker.

There has been some confusion about how to configure the broker for round-robin delivery. The solution is simple and configurable.
1. Set the destination attribute maxNumActiveConsumers to -1. This turns on round-robin delivery.
2. Set the destination attribute consumerFlowLimit to 1. This specifies the number of messages delivered to a single consumer before delivery progresses to the next consumer. For different chunking, set this attribute to the desired value. By default, one hundred messages are delivered to each consumer.
Broker becomes inaccessible when persistent store opens too many destinations. (Bug ID 4953354).

Workaround This condition is caused by the broker reaching the system open-file descriptor limit. On Solaris and Linux use the ulimit command to increase the file descriptor limit.
Consumers are orphaned when a destination is destroyed (Bug ID 5060787).

Active consumers are orphaned when a destination is destroyed. Once the consumers have been orphaned, they will no longer receive messages (even if the destination is recreated).

Workaround There is no workaround for this problem.

Broker Clusters

The following issues affect clustered brokers.

Only fully-connected broker clusters are supported in this release. This means that every broker in a cluster must communicate directly with every other broker in the cluster. If you are connecting brokers using the imqbrokerd -cluster command line argument, be careful to ensure that all brokers in the cluster are included.
A broker using HADB cannot handle messages larger than 10 MB. (Bug 6531734)
If a client is connected to a high availability broker, the client runtime will attempt to reconnect until it succeeds (no matter what the imqAddressListIterations value is set to be.)
A client connected to a broker that is part of a cluster cannot currently use QueueBrowser to browse queues that are located on remote brokers in that cluster. The client can only browse the contents of queues that are located on the broker to which it is directly connected. The client may still send messages to any queue or consume messages from any queue on any broker in the cluster; the limitation only affects browsing.
In a conventional cluster, if you want to cluster a 4.1 broker with a 3.x broker, you must set the property imq.autocreate.queue.maxNumActiveConsumers=1 for the 4.1 broker. Otherwise, the brokers will not be able to establish a cluster connection.
When converting to a high-availability cluster, you can use the Message Queue Manager utility (imqdbmgr) to convert an existing standalone HADB persistent data store to a shared HADB store. The command is as follows.

imqdbmgr upgrade hastore

You can use this utility in the following cases.
- Moving from a 4.0 standalone HADB store to a 4.1 shared HADB store. In this case, the broker will automatically upgrade the store. You can then run the imqdbmgr command to convert the upgraded data store for shared use.
- Moving from a standalone 4.1 HADB store to a shared HADB store. In this case, you just need to run the imqdbmgr command shown above to convert the data store for shared use.
Because this command only supports conversion of HADB stores, it is not possible to use it to convert file-based stores or other JDBC-stores to a shared HADB store. If you were previously running a 3.x version of Message Queue, you must create an HADB store and then manually migrate your data to that store in order to use the high availability feature.
The conversion to an HADB store using the command imqdbmgr upgrade hastore can fail with the message “too many locks are set” if the store holds more than 10,000 message. (Bug ID 6588856)).

(Workaround) Use the following command to increase the number of locks.

hadbm set NumberOfLocks=<desiredNumber>

For additional information see “HADB Problems” in Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.
If more than 500 remote messages are committed in one transaction, the broker might return the error “HADB-E-12815: Table memory space exhausted.” (Bug ID 6550483)

For additional information, see “HADB Problems” in Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.
In a broker cluster, a broker will queue messages to a remote connection that has not been started (Bug ID 4951010).

Workaround The messages will be received by the consumer once the connection is started. The messages will be redelivered to another consumer if the consumer’s connection is closed.

When consuming more than one message from a remote broker in one transaction, it is possible that the following error message will be logged to the broker. The message is benign and can be ignored:

[26/Jul/2007:13:18:27 PDT] WARNING [B2117]: 
Message acknowledgement failed from 
mq://129.145.130.95:7677/?instName=a&brokerSessionUID=3209681167602264320:
    ackStatus = NOT_FOUND(404)\
    Reason = Update remote transaction state to COMMITED(6): 
transaction 3534784765719091968 not found, the transaction
may have already been committed.
    AckType = MSG_CONSUMED
    MessageBrokerSession = 3209681167602264320
    TransactionID = 3534784765719091968
        SysMessageID = 8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690
        ConsumerUID = 3534784765719133952\par

[26/Jul/2007:13:18:27 PDT] WARNING Notify commit transaction 
[8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690, 
[consumer:3534784765719133952, type=NONE]]
TUID=3534784765719091968 got response: 
com.sun.messaging.jmq.jmsserver.util.BrokerException:
 Update remote transaction state to COMMITED(6): 
  transaction 3534784765719091968 not found, the transaction may have already 
  been committed.:
com.sun.messaging.jmq.jmsserver.util.BrokerException: Update remote transaction 
state to COMMITED(6): transaction 3534784765719091968 not found, the transaction
 may have already been committed.r

This message gets logged when notifying the commit to the message home broker for later messages in the transaction when the imq.txn.reapLimit property is low compared to the number of remote messages in one transaction. (Bug 6585449)

Workaround To avoid this message increase the value of the imq.txn.reapLimit property.

JMX Issues

On the Windows platform, the getTransactionInfo method of the Transaction Manager Monitor MBean returns transaction information that has incorrect transaction creation time (Bug ID 6393359).

Workaround Use the getTransactionInfoByID method of the Transaction Manager Monitor MBean instead.

Support for SOAP

You need to be aware of two issues related to SOAP support

Beginning with the release of version 4.0 of Message Queue, support for SOAP administered objects is discontinued.
SOAP development depends upon several files: SUNWjaf, SUNWjmail, SUNWxsrt, and SUNWjaxp. In version 4.1 of Message Queue, these files are available to you only if you are running Message Queue with JDK version 1.6.0 or later.