This section contains a list of the known issues with Message Queue 3.7 UR1. The following product areas are covered:
For a list of current bugs, their status, and workaround, 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
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.
A connection service using SSL is currently limited to supporting only self-signed server certificates, that is, host-trusted mode.
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.
In Message Queue 3.7 UR1, the example broker configuration for using an LDAP server as a user repository is provided in the comment area in the config.properties file, and the LDAP user repository example in the default.properties file has been commented out.
If you previously relied on any property value in the example LDAP user repository properties specified in the default.properties file, your JMS application client will receive a security exception when attempting to create a JMS connection. This will happen after you upgrade to Message Queue 3.7 UR1.
When your JMS client tries to make a connection to the Message Queue 3.7 UR1 broker, you will get a error in the broker log and your JMS client will receive the following exception:
SecurityException. 20/Aug/2004:11:16:41 PDT] ERROR [B4064]: Ldap repository ldap property .uidattr not defined for authentication type basic:com.sun.messaging.jmq.auth.LoginException: [B4064]: Ldap repository ldap property .uidattr not defined for authentication type basic
Workaround Set the broker property imq.user_repository.ldap.uidattr following the instructions in Chapter 7, Managing Security, in Sun Java System Message Queue 3.7 UR1 Administration Guide.
The following items relate to the use of broker clusters.
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 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.
If a master broker is not used in a broker cluster, persistent information stored by a broker being added to the cluster is not propagated to other brokers in the cluster.
Connection is dropped for a broker in a cluster (Bug ID 6377527).
One reason this can happen is that the broker address (whose connection is dropped) is resolved to be the loopback IP address (127.0.0.1).
Workaround Make sure that the broker address does not resolve to the loopback IP address.
In a broker cluster, a broker will queue messages to a remote connection which has not been started (Bug ID 4951010).
WorkaroundThe 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.
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 destination. 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).
The following issues affect the Message Queue broker.
The imqbrokerd —license command displays outdated or duplicate information. It displays information about the try license, even though this type of license is no longer supported (Bug ID 6489711) and it displays duplicate information about the unl license (Bug ID 6441015).
Workaround These are cosmetic problems that require no workaround.
The broker does not honor the default limit of 1000 messages for the dead message queue; it keeps adding messages to the dead message queue until the broker runs out of memory. (Bug ID 6502744)
Workaround Reset the Dead Message Queue limit to 1001 or any value other than 1000.
HTTPS createQueueConnection occasionally throws exception on Windows 2000. (Bug ID 4953348).
Workaround Retry the connection.
When using Ctrl-C to shut down broker, transactions may be cleaned up after store is closed (Bug ID 4934446).
The broker may show errors with the following reason “Store method accessed after the store is closed.” if the broker is shut down while messages or transactions are processed.
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.
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.
Message selection using JMSMessageID doesn’t work (Bug ID 6196233).
Workaround Change the selector from the following expression
JMSMessageID = "ID:message-id-string"
To the following expression
JMSMessageID IN (’ID:message-id-string’, ’message-id-string’)
Message Queue A queue browser shows uncommitted messages (Bug ID 6264003).
When browsing the contents of a queue, messages that were produced in a transaction but are not yet committed may appear in the queue browser enumeration.
Workaround There is no workaround for this problem.
Messages may become unavailable after broker crashes during a commit (Bug ID 6467874).
In very rare cases, during a broker crash, messages in a transaction may become unavailable to consumers. Specifically, there is a small window during Commit processing that may cause the message to become stuck in the persistent store. When this occurs, the following message is displayed at startup of the broker after a crash.
[06/Sep/2006:10:11:11 PDT] ERROR [B2085]: Loading Destination q0 [Queue] failed. Messages stored on that destination will not be available.: > com.sun.messaging.jmq.jmsserver.util.BrokerException: The message 8-129.145.180.87(b8:8b:26:15:41:26)-38998-1157562551217 has an associated acknowledgement list already.
Workaround There is no workaround for this problem.
There is no standalone product for the Beta release of Message Queue 3.7 UR1. For this release, therefore you must install Message Queue using the Java Enterprise System Installer and consult the Sun Java System Installation Guide for instructions.