Resolved Issues

The current release resolves many functional, robustness, and performance issues. This section provides a short summary of the resolved issues that may be of most interest to customers.

Release 10.11

  • NUM-16257

    A NullPointerException occurs randomly in a Universal Messaging server when you try to publish events to a mixed channel.

    The issue is resolved.

  • NUM-12799

    Out-of-memory errors, ConcurrentModificationException, and deadlock might occur when a user keeps connecting to and disconnecting from the same channel or queue.

    The issue is resolved.

  • NUM-15853

    When initializing a Universal Messaging multiplex session, the connection times out and the Java Service Wrapper detects a deadlock condition.

    The issue is resolved.

  • NUM-15694

    A deadlock might occur when a Universal Messaging realm is transitioning into a master state and trying to purge events from a JMS store. The issue was introduced with the DisconnectOnClusterFailure server-side flag functionality.

    The issue is resolved.

  • NUM-15643

    Caching does not work for multi-file disk stores even when caching is enabled for the server instance.

    The issue is resolved. By default, caching is not enabled for multi-file stores. To store events from a channel with multi-file stores in the cache:

    1. When configuring the Universal Messaging server instance, set the EnableStoreCaching and EnableCaching server configurations to "true" and restart the server.

    2. When creating a channel with a multi-file store, set the "Enable Caching" channel storage properties to "true".

  • NUM-15404

    Universal Messaging might shut down with an out-of-memory error.

    In some cases, the Universal Messaging realm server might shut down with OutOfMemoryError. The issue occurs due to a combination of factors including the slow processing of data buffers from multiplexed sessions.

    The issue is resolved.

  • NUM-14767

    Exclusive durables are not always properly recovered during cluster recovery.

    The issue is resolved.

  • NUM-16249

    Synchronous durable topic or queue consumers that have low timeout values (tenths of milliseconds or less) and consume messages from a slave realm in a Universal Messaging cluster might stop consuming messages and log the following message in the nirvana.log file for the slave realm: "Cluster\> Rolling back Event IDs to allocate for a local connection that no longer exists."

    The issue is resolved. Universal Messaging now has the TimeoutSynchronousConsumerOnMaster advanced realm configuration property that you can use to switch the timeout procedure to the master realm in the cluster. Valid values for the new property are:

    • true - switches the timeout procedure to the master realm in the cluster

    • false (default) - the timeout procedure is run on a slave realm in the cluster

    Important! You must configure the new property after updating all realms in the cluster to the fix version of the master realm.

  • NUM-15340

    During transactional publishing to Universal Messaging using a horizontal scalability (HS) session, the Universal Messaging client might report nUnexpectedResponseException.

    When a client is performing transactional publishing of messages to Universal Messaging servers that are part of an HS URL, and one of the servers is stopped during the transaction, some messages might remain unpublished. In addition, the client returns nUnexpectedResponseException. The exception occurs because the transaction request does not receive a reply from the Universal Messaging server.

    The issue is resolved. When a Universal Messaging server is stopped during multi-threaded transactional publishing, the transaction returns nSessionNotConnectedException, and the transaction can be retried.

  • NUM-16364

    Universal Messaging fails to start automatically after migration using a Command Central composite template.

    The server writes a NullPointerException to the nirvana.log file. You can start the server only from the Command Central web user interface.

    The issue is resolved.

  • NUM-14901

    Exporting or importing a realm configuration into XML results in missing or incomplete join details.

    When exporting or importing realm configurations from Enterprise Manager or using the "nexportrealm" or "nimportrealm" code samples, one of the following issues occurs:

    • The exported XML file does not include any information about the remote joins.

    • The join entries in the exported XML file do not include the details of the remote realm, which incorrectly represents the join as local.

    • The information about the remote joins does not get imported.
      The issues are now resolved.

  • NUM-14412

    Connecting nodes in a Universal Messaging cluster might fail when you use the VIA list of an interface to configure access control list (ACL) entries for cluster communication.

    The issue is resolved.

Release 10.7

  • NUM-10799 (Uninstallation may not remove UM Windows service.)

    Windows services created during or after installation of Universal Messaging may not be removed when the product is uninstalled. Users should check whether any such services still exist after uninstallation and manually remove them if so, using the Windows Services control panel.

    The issue is now resolved.

  • NUM-9489 (JMS API allows creation of multiple exclusive durables with the same name.)

    Since the 9.12 release, the JMS Session.createDurableSubscriber allows creating more than one exclusive durable subscriber with the same name, with no exception thrown or other indication that this has occurred.

    The issue is now resolved. Exclusive durables are now bound to synchronous subscribers.

  • NUM-6873 (Out of order event after restarting shared durable receiver)

    Disordering of events can occur when re-starting a shared durable subscriber with unacknowledged events using the queued shared durable implementation.

    A workaround for this is to ensure that the “Fanout Config -\> SyncQueuePublisher” realm configuration property is set to false. This however may cause excess events to build up on server queues in scenarios where consumers do not keep up with publishers.

    Note that for a Universal Messaging delivery as part of a webMethods bundle, the configuration property defaults to false anyway.

    The issue is now resolved.

Release 10.5

  • NUM-10743 (MQTT QoS 2 connections are not downgraded to QoS 1)

    Universal Messaging doesn’t support MQTT QoS 2 and will automatically downgrade client connections to QoS 1.

    This issue is resolved.

  • NUM-11606 (Universal Messaging status shown as ERROR in CCE)

    Command Central displays an ERROR run-time status for a clustered Universal Messaging server when you replace interfaces on one or more of the realm servers in the cluster from outside Command Central.

    When you monitor a Universal Messaging realm server that is part of a cluster in Command Central, and you add a new interface and remove the previously active interface on one or more of the realm servers in the cluster from outside Command Central (for example, in Enterprise Manager), Command Central displays an ERROR status for the monitored realm and also displays offline cluster members until Platform Manager is restarted.

    The issue is resolved.

  • NUM-11965 (Universal Messaging cluster formation may take too long to reform)

    Logic for purging events from a multi-file store is now optimized.

    Previously, events were read twice from disk although this was not really needed.

    The issue is resolved.

  • NUM-11971 (NSPS connection from DotNet to UM)

    C# clients were not able to connect to NSPS interfaces using SASL authentication.

    The issue is resolved.

  • NUM-12285 (Selectors starting with % sign are not parsed correctly)

    An error was thrown when parsing a selector which starts with the string "%\_". This was an unhandled case in the code, which is now corrected and this scenario is working properly.

    The issue is resolved.

  • NUM-12300 (Batch consumption for serial durable consumers does not use the allowed batch size)

    Serial consumers did not correctly consume messages in batches even when there was a large backlog of events. For example, if the batch size was 50, a serial consumer could receive only 2 or 3 messages in a single batch instead of all 50.

    The issue is resolved.

Release 10.4

  • NUM-10669 (Channels and queues are not sorted in the EM tree)

    The Universal Messaging Enterprise Manager previously did not display newly added channels or queues in alphabetical order.

    The issue is resolved.

  • NUM-10754 (UM Tools for manipulation of JMS artifacts fail when used with authentication)

    The issue is that beside the usual connection which is properly supported for authentication, there is a JNDI connection required where credentials were hardcoded. The credentials provided via the command line are now also used by the JNDI connection.

    The issue is resolved.

  • NUM-10872 (Enterprise Manager slows down while editing channels or queues)

    Previously, when editing channels or queues in the Enterprise Manager, the processing became slower after each save operation. When you edited channels or queues nested in several containers (folders) in the Enterprise Manager, the time for saving your changes increased with each save operation.

    The issue is resolved.

  • NUM-10944 (Batch Purge performance)

    Event purge performance has been improved in the case where there is an indexed durable (Shared or Serial) attached to a store.

  • NUM-10945 (Problem when editing a queue in Enterprise Manager)

    Editing a queue in the Universal Messaging Enterprise Manager could previously cause some events on the queue to be lost.

    The issue is resolved.

  • NUM-11166 (Cluster manager doesn't throttle events when queue becomes big)

    Previously, in inter-cluster communication, one node could send events faster than the receiving node could process them. This could lead to an out of memory exception.

    Now if the event queue becomes too big, the receiving node will throttle.

  • NUM-11381 (Universal Messaging C# client only supports secure connection TLS 1.0 and SSL 3.0 protocols)

    This issue is now resolved. The Universal Messaging C# client now also supports TLS 1.1 and TLS 1.2 protocols.

Release 10.3

  • NUM-10389 (Possible memory leak when deleting channels.)

    A memory leak of cached Google Protocol Buffer definitions that could be triggered by deleting channels from the Universal Messaging realm server has been resolved.

  • NUM-10317 (JAVA_HOME environment variable not tailored correctly on Windows.)

    The JAVA_HOME environment variable was not being correctly tailored to point to the installed Java Virtual Machine when opening one of the Universal Messaging command prompts from the Windows Start Menu. The variable will now be set correctly.

  • NUM-10313 (Enterprise Manager hangs after 10 minutes.)

    The Universal Messaging Enterprise Manager tool could hang after a period of time when connected to a realm server under heavy load. This issue has been resolved.

  • NUM-9719 (AMQP/JMS mapping header mismatch.)

    The AMQP to JMS mapping supported by Universal Messaging has been updated to include some additional mappings defined in the latest updates to the AMQP specification.

Release 10.2

  • NUM-9143 (It is not possible to import a realm configuration exported from UM 10.1.)

    Previous releases allowed realm configurations containing clustered Simple and Transient channels to be imported even though these configurations are unsupported. The import tooling has been updated to detect such invalid configurations and allow automatic upgrading of these channels to Mixed type if requested by the user.

  • NUM-9326 (UM's SPM should set connection name for admin connection.)

    The Software AG Platform Manager (SPM) plugin for Universal Messaging will now set the “connection name” property when making an administrative connect to the Universal Messaging server. This allows easier identification of the clients connecting to a particular server.