What's New in Universal Messaging 10.5
Universal Messaging 10.5 is the successor of Universal Messaging 10.4.
Universal Messaging 10.5 includes new features, enhancements, and changes as described in the following topics.
New features in v10.5
The following Universal Messaging features have been added in Universal Messaging 10.5:
Support for purging events on a queue using Command Central It is now possible to purge a range of event IDs or a single event ID on a queue.
This means that purging of events on queues is possible through Enterprise Manager, Command Central and the client API, in the same way as for purging events on channels.
Monitoring queue-level connections It is now possible to monitor both asynchronous and synchronous subscription to a specific queue similar to the monitoring of connections to durable subscribers. This is available programmatically via nQueueNode, similar to nDurableNode. Both Enterprise Manager and the Command Central UI have been updated to show these statistics; they are almost identical to how connections for durable subscribers are shown.
In Enterprise Manager they can be seen under a specific queue in the Consumer Info tab. In Command Central they are under in the Administration tab when you click on a specific queue and go to Consumer Info tab. Additionally there are few new queue properties present in the Status tab of the queue under Consumer Status.
Individual purging of events on shared/serial durables The JMS Engine of Universal Messaging now has the ability to automatically purge individual events from channels whose consumers are exclusively using durable subscriptions of type Shared or Serial.
The individual JMS Engine purge is deactivated by default. To activate it, set the new realm configuration property "Event Storage"-> "JMSEngineIndividualPurgeEnabled" to "true".
Note:
We are planning to change this default setting from deactivated (boolean value "false") to activated (boolean value "true") in a software fix that is scheduled for release shortly after the initial release of v10.5.
Changed features in v10.5
The following Universal Messaging features already available in the previous product release have been changed in Universal Messaging 10.5:
Health Checker error and warning messages Some messages which were previously reported as error messages during a health check of a live cluster have now been changed to warning messages. This is because small synchronization delays across the live cluster can occur that cause the health checker to detect discrepancies, although the cluster is working correctly. Such discrepancies are therefore now classified as warnings rather than errors.
Re-worked queue implementation In v10.5 the queue implementation in Universal Messaging has been reworked. This was done in order reduce internal complexity regarding queue usage, and to increase their stability and maintainability.
Queue subscriber filtering In previous product versions, queue subscriber filtering was always enabled, which led to a certain amount of processing overhead. In v10.5 this has been changed, so that the feature can be activated or deactivated by using the new realm property QueueSubscriberFiltering in the Event Storage configuration group.
By default, this property is set to false, meaning that queue subscriber filtering is deactivated. If you set this property to true, this activates the feature whereby events published to a queue can be read by selected subscribers only.
Subscriber name/host filtering is activated at the API level by using the setSubscriberName() method of nConsumeEvent.
Even if you set a name/host on an nConsumeEvent (using setSubscriberName), this would not have any effect unless the new realm property QueueSubscriberFiltering is set to true.
Deprecated features in v10.5
The following Universal Messaging features are now deprecated in Universal Messaging 10.5. Features listed as deprecated are still available in the product, but will be removed in a future release.
API nQueueReaderContext method setMaintainPriority() For single node usage, the priority assignment for queue asynchronous consumers has been deprecated. This concerns only native queue asynchronous consumers, which set the maintain priority to "true" in their nQueueReaderContext.
Additionally, cluster support for this method has been removed. The method still exists, but for cluster usage it has no effect.
Fanout archive The fanout archive functionality is a legacy feature that has various limitations. It will be removed from the product in the next releases.
"Persistent" flag for durable objects The "Persistent" flag for durable objects is now deprecated. When the flag is removed in a later product version, the persistence of the durable will be inherited by the persistence support of the durable's channel. If the parent channel supports persistent events, its durables will always be created as persistent, whereas if the parent channel does not support persistent events, its durables will always be created as non-persistent.
"Cluster-wide" flag for durable objects When the flag is removed in a later product version, the cluster-wide property of the durable will not be defined explicitly. The durable will be created as cluster-wide if its channel is a cluster-wide channel, whereas the durable will be created as non-cluster-wide if its channel is non-cluster-wide.
Removed Features in v10.5
The following Universal Messaging features have been removed in Universal Messaging 10.5:
API for Microsoft Silverlight The Universal Messaging client API for Microsoft Silverlight has been removed.
API for Windows Phone The Universal Messaging client API for Windows Phone has been removed.
Removal of store types Support for the channel/queue types Simple, Paged, Transient and Offheap has been removed.
Note:
If a Universal Messaging client from an earlier product version connects to the version 10.5 server, the client might wish to create a store (channel or queue) that has a store type of Simple, Paged, Transient or Offheap. In this case, these store types will be remapped to one of the existing ones as follows:
Simple -> Reliable
Transient -> Reliable with a TTL (time to live) of 1 millisecond
Off-heap -> Reliable
Paged -> Mixed
Also, log message will be visible in the nirvana.log file.
Example: If a v10.3 client tries to create a Transient channel, the v10.5 server will instead create a Reliable channel, and will also set the TTL to 1 millisecond in order to provide functionality that is similar to what the client would expect. A log message similar to the following will be visible in the nirvana.log file:
UserCreate> Warning : Store <store_name> is of type TRANSIENT which is not supported anymore. Instead RELIABLE type will be used with TTL set to 1 ms.
For further information on the migration of store types that have been removed, see the section
Migration Notes in these Release Notes.
Removal of durable types "Priority" and "Shared-Queued" The durable types "Priority" and "Shared-Queued" have been removed.
Clients connections from previous product versions that use these durable types will be automatically mapped to other types if they connect to a v10.5 server:
"Priority" will be mapped to "Serial".
"Shared-Queued" will be mapped to "Shared".
Removal of nNamedObject-based API from the nChannel API The previously deprecated nNamedObject-based API has been removed from the nChannel public API. If you have client applications that use nNamedObject, you will need to change them to use the nDurable API instead.
For further information on the migration of applications that use
nNamedObject, see the section
Migration Notes in these Release Notes.
Client API for Java The option -autoconvert has been removed from the Java client API. This option converted clustered transient channels and queues to mixed channels and queues when you imported a realm configuration from an XML file. The option has also been removed from the sample program nimportrealmxml that is delivered with the product.
Realm configuration properties The following list shows the realm configuration properties that are no longer available. The names are given in the form <category>: <property>, where <category> is the category to which the property belongs, and <property> is the property name.
Event Storage : QueueDeliveryPersistencePolicy Fanout Values : SyncQueueDelay Fanout Values : SyncQueuePublisher The syncQueuePublisher and syncQueueDelay properties provided a throttling mechanism for queues and shared-queued durables.
When you set syncQueuePublisher to true, Universal Messaging started to slow down publishers for a queue or shared-queued durable when all consumers for this destination had received their full window of events and had not yet acknowledged or rolled back any received events.
You configured this throttling mechanism globally, that is, it had effect for all queues and shared-queued durables on the server.
With the removal of the two properties, Universal Messaging no longer provides this throttling mechanism. This means that if the publishing rate for a queue or shared durable is faster than the consumption rate, events start accumulating in the respective store on disk or in memory, depending on store type.
For this reason, using non-persistent events with queues and shared durables might deliver suboptimal performance if the publishing rate is higher than the consumption rate for a store. In such cases, events accumulate in heap memory until the server memory protection mechanism is activated if you have enabled it. The mechanism throttles publishers and enables consumers to process events, reducing the overall publishing throughout.
If you exported a realm configuration containing any of the removed properties to an XML file in a previous product version, when you import the XML file into a newer-version realm, the properties are ignored.
Transient queue events The transient event flag of an nConsumeEvent(setTransient()) for events published to a queue is no longer supported and will be ignored. As a consequence, transient events will always be stored on the queue, even if there are no active subscribers.
Documentation Changes
Enterprise Manager documentation The Universal Messaging Enterprise Manager documentation in the Administration Guide has been reorganized to be more task-oriented.
Additional Information
You can run Universal Messaging in a Docker environment.
See the section
Using Docker in the
Installation Guide for further information.