What's New in Universal Messaging 10.15

The following features have been added in Universal Messaging 10.15:

• Support for determining the server state within a cluster

  You can determine the state of a Universal Messaging server within a cluster in the following ways:

  • Using the newly added command-line tool GetServerClusterState.
  • Using the newly added endpoints in the Health Monitor Plugin IsMaster or GetClusterState.
• File size limit on multi-file disk stores

  Files in multi-file disk stores now have a size limit. When the maximum size per file is reached Universal Messaging creates a new file to persist the next events. You can use a new realm configuration property, MaxSpindleFileSize, to specify the maximum file size in bytes.

  For more information about how to configure multi-file disk stores and the new property, see Multi-File Disk Stores.

• Bi-directional admin client and server compatibility

  Universal Messaging 10.15 and higher supports bi-directional compatibility of Enterprise Manager and the Java Admin API for release versions 10.15 and higher.

  For more information about the functionality, see Bi-directional Admin Client and Server Compatibility.

• Bi-directional compatibility of server-to-server communication

  Universal Messaging 10.15 and higher supports bi-directional compatibility of server-to-server communication within clusters, zones, and joins for release versions 10.15 and higher.

• Server log level configuration for Log4j2

  You can now use the new LogLevelOverride realm configuration property to configure the server log level when the server uses the Log4j2 logging framework. This parameter is only supported when the server is running as a Docker container.

  If you set LogLevelOverride to true, you can configure the fLoggerLevel property. A false value restores the configuration from log4j2.xml and makes fLoggerLevel ineffective in the Enterprise Manager.

  For more information about the logging configuration, see Realm Configuration.

  The functionality is provided with Universal Messaging 10.15 Fix 2.

• com.softwareag.um.client.missed_keep_alives client property

  A new client property that specifies the number of missed server-side keep-alive intervals before the client closes a connection. The property is introduced in Universal Messaging 10.15 Client Fix 4.

  For more information about the property, see Client Parameters.

• MaxNoOfConnectionsPerUserName realm property

  A new realm configuration property that defines the number of concurrent connections to a Universal Messaging server per user. The property is introduced in Universal Messaging 10.15 Fix 5. For more information about using the property, see Realm Configuration.

• New HealthChecker Tool Check

  The new JoinLastEIDMismatchCheck checks for joins that are ahead of the channel's last EID. The check is introduced in Universal Messaging 10.15 Fix 12. For more information, see Running a Configuration Health Check.

• User Connections JMX bean and metrics

  Universal Messaging exposes a new JMX bean, named Universal Messaging User Connections, which enables access to data related to the number of current sessions that each user has established to the server. You can use the related NumberOfConnections JMX metric and sag_um_connections_per_user Prometheus metric for monitoring. The functionality is available with Universal Messaging 10.15 Fix 12.

  For more information about the metrics and using JMX, see Using JMX to Monitor Universal Messaging.

• com.softwareag.um.client.server_keep_alive_leeway client property

  A new client property that specifies the additional time that it can take a Universal Messaging server to reply to a keepalive sent by a client. The property is introduced in Universal Messaging 10.15 Client Fix 14.

  For more information about the property, see Client Parameters.

• Support for Java 17

  Starting with Universal Messaging 10.15 Fix 19, Universal Messaging supports both Java 17 and Java 11 as a runtime for the server, client, and sample applications components.

• Client support for JMS 2.0 and Jakarta Messaging 3.0

  The Universal Messaging Java client supports JMS 2.0 and Jakarta Messaging 3.0 in addition to JMS 1.1. Support for JMS 2.0 and Jakarta Messaging 3.0 was introduced in Universal Messaging 10.15 Fix 20.

  For more information about JMS 2.0 support, see Notes on Universal Messaging Support for JMS 2.0 and Changed Features.

The following Universal Messaging features already available in the previous product release have been changed in Universal Messaging 10.15:

• C++ Libraries

  Note the following changes relating to the C++ libraries that Universal Messaging provides:

  • The C++ libraries for Universal Messaging use OpenSSL libraries that have now been upgraded to version 3.0.5 from version 1.1.1k.
  • The C++ libraries for Universal Messaging use POCO libraries that have now been upgraded to version 1.11.3 from version 1.10.1.
  • OS X is no longer supported.

  If you experience any problems with the new version of the C++ client libraries for Universal Messaging, first consider recompiling your client applications against the new version of the libraries and compilers.

• Defining users exempt from authentication

  Now you explicitly define users that are exempt from authentication by configuring the -DNirvana.auth.exempt property. Previously, users exempt from authentication were loaded by default from a –DSECURITYFILE file, which is not used any longer.

  In addition, exempt users both with and without a password should be able to log in to Universal Messaging. Previously, authentication failed when an exempt user provided an invalid password.

  For more information about defining users exempt from authentication and configuring the -DNirvana.auth.exempt property, see Configuring Authentication and Client Negotiation.

• JMX namespaces for topics and queues

  By default, JMX namespaces are now created using a flat structure, for example, destinationName=/q1/q2/q3. In previous Universal Messaging versions, by default, JMX namespaces for topics and queues have a folder tree structure.

  You can use a new realm configuration property, FlatStoreJMXBeanNamespace, to define if JMX namespaces for topics and queues have a flat structure or a folder tree structure.

  For more information about the property, see Realm Configuration.

• MaxNoOfConnections realm property

  A realm configuration property that defines the total number of concurrent connections to a Universal Messaging server. Now a user with both the Override Connection Count realm permission and an admin connection can override this property. Previously, users with full permissions could override the property. The change is introduced in Universal Messaging 10.15 Fix 5. For more information about using MaxNoOfConnections, see Realm Configuration.

• Realm Information Collector

  The Realm Information Collector command-line diagnostic tool has been enhanced to collect the following additional information about a server:

  • Java Service Wrapper log files even if you configured an absolute file path for the wrapper.logfile property in the Sever_Common.conf file.
  • Log4j2 configuration, and also log files configured through file appenders in the log4j2.xml configuration file.
  • The log header of the Universal Messaging server.

  For more information about the Realm Information Collector, see the section The Realm Information Collector Diagnostic Tool.

• Queue batching

  In Universal Messaging 10.15 and higher, the server disregards event batching for queues that is requested by clients and sets it to one event instead. The modified behavior affects Java clients using the com.pcbsys.nirvana.client.nQueueReaderContext.setPeekBatchSize(int) API.

• com.pcbsys.nirvana.client.nConstants#setReconnectAfterAccessChange method behavior

  If you set setReconnectAfterAccessChange(..) to false, if the client receives nSecurityException for cluster formation or for exceeding the connection limit, these exceptions are treated as recoverable and the client will try to reconnect to the Universal Messaging server. For any other security exceptions, the client will make no reconnection attempts.

  For more information about setReconnectAfterAccessChange(..), see the com.pcbsys.nirvana.client.nConstants class reference in the Java Client API documentation.

• Support for plugins depending on the license type

  Universal Messaging now supports plugins for all UM license types regardless of the Plugins key value in the license file. Previously, plugin support was available only for the NUMWF/NUMTF license type. The change is introduced in Universal Messaging 10.15 Fix 13.

• Server behavior when handling duplicate stores for a store name

  Starting with Universal Messaging 10.15 Fix 14, the Universal Messaging server does not start if there are duplicate stores for a particular store name present on the server when you work with case-insensitive data folders, for example, on a Windows operating system. Contact support about how to proceed.

  When you start the Universal Messaging server, it checks for duplicate stores and shuts down if it finds such stores, for example, testQueue and TestQueue. The server also writes the following warning message in the nirvana.log file and in the console output: "WARNING: Multiple stores found for store name: <Store name>. Listing the stores for this store name: <Store 1><Store 2>…."

  In addition, you can no longer create duplicate stores for a particular store name when you work with case-insensitive data folders.

• Type of store created when using the administration tools or nChannelAttributes constructors

  Starting with Universal Messaging 10.15 Fix 18, all Universal Messaging command-line administration tools associated with stores (channels and queues) create stores of type Mixed by default. Previously, the tools created stores of type Reliable by default.

  In addition, in the Universal Messaging Java client API, the constructors com.pcbsys.nirvana.client.nChannelAttributes.nChannelAttributes() and com.pcbsys.nirvana.client.nChannelAttributes.nChannelAttributes(String name) create mixed stores by default instead of reliable ones.

  Also, the methods in nSession and nRealmNode that create channels or queues create mixed stores instead of reliable ones if you do not set the type of the store explicitly.

  You can use a new system property on the client side, com.softwareag.um.client.DefaultChannelType, to specify the type of stores created when using the administration tools and the nChannelAttributes constructors. Valid values are mixed, reliable, and persistent.

• Base image for Universal Messaging container images

  Starting with Universal Messaging 10.15 Fix 16, the Universal Messaging container images on the IBM Container Repository use Red Hat UBI 9 as a base image. Images up to 10.15 Fix 16 use Red Hat UBI 8 as a base image.

• Client API for JMS method behavior

  With the introduction of client support for JMS 2.0 and Jakarta Messaging 3.0 in Universal Messaging 10.15 Fix 20, some methods in the client API for JMS have changed behavior as follows:

  • MapMessage#setObject(String name, Object value). If the name is null or an empty string, the method now throws an IllegalArgumentException. Previously, the method threw no exception.
  • Connection#getExceptionListener(). If the exception listener is not set on a JMS connection, the method now returns a null value. Previously, if the exception listener was not set on a JMS connection, the method threw a JMSException.
  • MessageProducer#send(). If the message is invalid, the method now throws a MessageFormatException. Previously, if the message was invalid, the method threw an IllegalStateException.
  • XASession#commit() and XASession#rollback(). The methods now throw a TransactionInProgressException. Previously, the methods threw an IllegalStateException.

The following Universal Messaging features have been deprecated in Universal Messaging 10.15:

• Java Client APIs

  The following Java APIs are deprecated:

  nQueue#createAsyncReaderPrevious(nQueueReaderContext context)
  nQueue#createAsyncTransactionalReaderPrevious(nQueueReaderContext context)
  nQueue#destroyReaderLocally(nQueueReader reader) ,destroyReader(nQueueReader reader)
  nQueue#destroyReader(nQueueReader reader)
  nSession#isConnectionVirtual()
  nSession#enableThreading(boolean enabled)
  nSession#enableThreading()
  nSession#setHTTPURLParameter(String parameter)
  nRealm#getHostVal()
  nRealm#getPortVal()
  nRealm#getHTTPPortVal() 

• Client APIs related to the removal of queue reader objects

  The following C# and C++ APIs are deprecated:

  nQueue#destroyReader(nQueueReader reader)
  nQueue#destroyReaderLocally(nQueueReader reader)