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.

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 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 Linux

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)

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.

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 —passfileMyPassfileName

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.

Set the destination attribute maxNumActiveConsumers to
-1. This turns on round-robin delivery.

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.

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.

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.

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.