Known Issues

Edit online

This section lists any issues for the current release that were known when this readme was published.

  • NUM-21114

    Creating two or more channels with names that differ only in the case sensitivity of the letters should be avoided. Channels may require store creation that results in files being persisted on disc. This may lead to unexpected results because Windows is case-insensitive.

  • NUM-21607

    The runUMTool command-line tool does not create JMS topics and queues of type Mixed, which is the default JMS topic and queue type. In this case, you should explicitly set the topic or queue type to Mixed.

    If you need help, see the Universal Messaging documentation or contact IBM support.

  • NUM-18109

    A Universal Messaging client may fail to receive events sent to a Universal Messaging server over AMQP via the AMQPNetLite library. The client returns ArrayIndexOutOfBoundsException.

    For a workaround to this issue, contact IBM support.

  • NUM-14533

    When Universal Messaging is configured to use Logback as the logging framework, many of the server start-up messages in the server's nirvana.log file will be written with status ERROR. This happens due to a limitation in Logback that does not provide usage of custom log levels. Therefore, Universal Messaging messages logged with a LOG level are translated to an ERROR level when Logback is used.

    There is no workaround for this issue.

  • NUM-10210

    The Universal Messaging instance manager tool may crash when run on Windows with an instance name longer than 42 characters, although the instance may still be created.

    The only workaround is to use a shorter instance name.

  • NUM-7839

    If an exclusive asynchronous durable is created, closed, and then re-subscribed immediately, it is possible for the client to receive an exception that the subscriber is already bound.

    The issue occurs because the session disconnect operation does not wait for all resources to be cleaned. If a client waits for a while before the second subscription, all resources on the server are cleaned so the subscription is successful, but there is no way to ensure the exact time at which everything is cleaned.