Release Notes

UM Version 6.17

The most significant update to UM version 6.17 is the "DRO Hotlinks" feature.

Attention
  There are some special upgrade instructions for UM versions 6.17 and beyond that will affect some users upgrading from pre-6.17 versions of UM. See Special Upgrade Instructions for 6.17. For general upgrade instructions, see Upgrade Procedure.

Also see Deprecations.

# Enhancements for 6.17 <-

## Streaming Enhancements for 6.17 <-

The following new features and enhancements apply to UMS, UMP, and UMQ products.

- Hotlinks. A form of fault-tolerance where two copies of each message are sent in parallel over the two global networks from a publishing datacenter to subscribing datacenters. If packet loss on one network prevents that copy of the message, the other network's copy will be used. See DRO Hotlinks.

- Flexible LBT-RU Topic Assignment. There is a modification to the way that topics are assigned to LBT-RU transport sessions. See Flexible LBT-RU Topic Assignment.

- DRO and Store support log files with UTC-based timestamps. See Tnwgd Man Page and Umestored Man Page.

- UM will now re-resolve DNS names after certain connection failures. See bug 11442 (lbmrd), bug 11342 (SRS), and bug 11383 (DRO).

- DRO UDP Peer: Compression and Encryption. Compression and encryption functionality has been added to the DRO UDP Peer link. See UDP Peer Link.

- Datagram Max Size Separation. UDP-based protocols (LBT-RM and LBT-RU) can now have their datagram max sizes configured differently for sending and receiving. See Changing Datagram Max Size.

## Persistence Enhancements for 6.17 <-

The following new features and enhancements apply to UMP and UMQ products.

- Store now supports log files with UTC-based timestamps. See Umestored Man Page.

## Queuing Enhancements for 6.17 <-

The following new features and enhancements apply to the UMQ product.

- None.

# Fixed Problems and Limitations for 6.17 <-

## Streaming Fixed Problems and Limitations for 6.17 <-

The following bug fixes apply to UMS, UMP, and UMQ products.

Change Request | Description
--- | ---
11475 | FIXED: Log message Core-10403-150 does not contain the context instance ID.
11490 | FIXED: UM_DynamicRouting_6.16_Win2k-x86_64-install failed to install DRO on windows 11. Symptom: "Error opening file for writing: \UMS_6.16\Win2k-x86_64\bin\tnwg.dll"
11453 | FIXED: Datagram max size cannot be made different between receiving and sending. This makes it difficult to change a network's datagram size. Datagram max size can now be separately configured between sending and receiving. See Changing Datagram Max Size.
11442, 10928 | FIXED: If a host running an "lbmrd" unicast resolver daemon fails, and the UM components specify the "lbmrd" by DNS name, moving the "lbmrd" to a different host and updating the DNS name to the new IP address does not redirect the running UM components to the new IP address. The components must be restarted for UM to re-resolve the DNS name. Starting with UM version 6.17, UM will re-resolve the DNS name for an "lbmrd" each time connection to it fails.
11342 | FIXED: If a host running an "SRS" TCP-based resolver service fails, and the UM components specify the "SRS" by DNS name, moving the "SRS" to a different host and updating the DNS name to the new IP address does not redirect the running UM components to the new IP address. The components must be restarted for UM to re-resolve the DNS name. Starting with UM version 6.17, UM will re-resolve the DNS name for an "SRS" each time connection to it fails.
11383 | FIXED: If a host running a DRO with an "acceptor" peer portal fails, and the DRO "initiator" portal specifies the "acceptor" by DNS name, moving the "acceptor" to a different host and updating the DNS name to the new IP address does not redirect the running "initiator" DRO to the new IP address. The "initiator" DRO must be restarted for it to re-resolve the DNS name. Starting with UM version 6.17, the initiator DRO will re-resolve the DNS name for the "acceptor" DRO each time connection to it fails.
11411, 11494 | FIXED: An application can register its own file descriptor (fd) with UM and associate it with a UM event queue. When lbm_cancel_fd_ex() is called to de-register the fd, the user's cancel callback is invoked too soon, before UM has finished with the fd. So if the user closes the fd inside the cancel callback, UM will log the warning: `Core-5455-1: epoll_ctl: EPOLL_CTL_DEL returned: errno:9:Bad file descriptor`
11433 | FIXED: When a subscriber detects "EOS" (End Of Stream), the following warning assertion can be printed: `WARNING: failed assertion [new_duration!=0]` Note that no bad behavior results; the warning can be ignored.
11485 | FIXED: The SRS (Stateful Resolution Service) does not publish connection and disconnection events in its monitoring statistics.
11395 | FIXED: The SRS (Stateful Resolution Service) prints some "debug" lines in its log file. This clutters the log file with unnecessary lines.
11390 | FIXED: The UM C API is missing the functions lbm_xsp_dump() and lbm_xsp_attr_dump().
11124 | FIXED: The DRO logging option "<log type="syslog"/> lbm_xsp_dump() and lbm_xsp_attr_dump().
11305 | FIXED: It is possible to delete an event queue that still has events on it. These events are purged, which can result in silent memory leakage. Starting in UM version 6.17 a debug log can be enabled to warn of event purging.
11396 | FIXED: The lbmmon.c example app does not print DRO statistics, like UDP peer link statistics.
11345, 11369, 11385 | FIXED: The MCS and SRS services require that the user conform to the directory structure established by the UM package installer. However, users are not generally required to follow the UM installer conventions. Starting with UM version 6.17, the MCS and SRS services can conform to the user's preferred directory structure. See Man Pages for MCS and Man Pages for SRS.
11287 | FIXED: The MCS service does not shut down cleanly, potentially leaving some recent statistics not saved in the database. Starting with UM version 6.17, the MCS will gracefully cleanup itself when using the recommended methods of shutting it down. See Man Pages for MCS ("Usage Notes").
11449 | FIXED: In the UM EBF 6.16.0.1, the startup scripts for SRS and MCS specified incorrect jar file paths.
11364 | FIXED: The lbmmon.c example app normally does not exit its main loop. However, if a user program is based on lbmmon.c and does exit normally the cleanup code after the main loop is code incorrectly.
10158 | FIXED: The UM Java sample applications have unnecessary dependencies on `log4j-1.2.9.jar` and `openmdx-kernel.jar`, neither of which were included in the UM packaging. Starting with UM version 6.17 the Java sample apps no longer depend on `log4j-1.2.9.jar` and `openmdx-kernel.jar`. However, we added a dependency to the GNU `java-getopt-1.0.13.jar`. See Running Java Examples.

## Persistence Fixed Problems and Limitations for 6.17 <-

The following bug fixes apply to UMP and UMQ products.

11444 | FIXED: When a non-persistent source is created for a topic that is also persisted, the Store initiates SRI request to the non-persistent sources. This produces log messages in the non-persisted source: "LOG Level 6: THROTTLED MSG: Core-6361-126: received sri request for unknown source"
11437 | FIXED: When named Stores are being used, a publisher deleting the context can trigger the following fatal assertion: `FATAL: failed assertion [rctxinfo->rctx==NULL]`
11377, 11382 | FIXED: In a UM network containing DROs, if a persistent receiver uses XSPs, it can fail to successfully register with Stores.
11496 | FIXED: With binary daemon stats enabled, the Store can log: "Tue Nov 26 16:14:00 2024 [CRITICAL]: Store-10184-73: failed to set dmon source option [monitor_interval] to [0]: CoreApi-5688-722: option monitor_interval unknownTue Nov 26 16:14:00 2024 [INFO]: Core-9571-16: Domain name address: ... resolved to ip: ...
11432 | FIXED: When at least one Store is "wiped" (state and cache files deleted), a starting receiver that needs to recover significant numbers of messages will recover very slowly.
11462 | FIXED: Windows-based Store with I/O Completion ports can crash shortly after the log message, "Sat Aug 17 17:49:02 2024 [CRITICAL]: Core-9950-1: Critical Windows Completion Port error (10054) (Connection reset by peer): the Receive I/O operation could not be started. No data will be received".
11338, 11439, 11483 | FIXED: The Leading Loss suppression behavior for streaming receivers is also applied to persistent receivers. But persistent receivers should not be subject to this suppression. Starting in UM version 6.17, a persistent receiver will not suppress leading unrecoverable loss events.

## Queuing Fixed Problems and Limitations for 6.17 <-

The following bug fixes apply to the UMQ product.

- None.

# Special Upgrade Instructions for 6.17 <-

There are no upgrade instructions specific to 6.17. However, if you are upgrading from a version prior to 6.16, then you must examine the Special Upgrade Instructions for 6.16.

Also see Deprecations.