Release Notes

UM Version 6.17.1

The most significant updates to UM version 6.17.1 are enhancements and bug fixes to the "DRO Hotlinks" feature.

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

Also see Deprecations.

# Enhancements for 6.17.1 <-

## Streaming Enhancements for 6.17.1 <-

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

- Hotlink Route Groups. An enhancement to DRO Hotlinks that allows a more flexible mix of hotlinked and non-hotlinked DRO configurations.

- Receiver Events Deliver Originating Source Strings. An enhancement to DRO Hotlinks that allows correlation between DRO proxy sources and the originating source. Note that this changes the semantics of a receiver callback's source string referenced in the event's "source" field. See Hotlinks and Source Strings.

- XSP Support for Hotlinks. The DRO Hotlinks feature now supports XSPs. See com::latencybusters::lbm::LBMContext::setNakCutoff().

- NAK Cutoff for Java. The NAK Cutoff feature is now supported in Java.

## Persistence Enhancements for 6.17.1 <-

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

- None.

## Queuing Enhancements for 6.17.1 <-

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

- None.

# Fixed Problems and Limitations for 6.17.1 <-

## Streaming Fixed Problems and Limitations for 6.17.1 <-

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

Change Request | Description
--- | ---
11589, 11592 | FIXED: Hotlink receiver OTID order filter maps are retained after all contributing transport sessions are deleted. Starting with UM version 6.17.1, hotlink receiver OTID order filter maps are deleted when the last contributing transport session is ended.
11590, 11591 | FIXED: DRO crash in stats gathering code.
11588 | FIXED: Live messages received non-hotlinked receivers via DROs contain the originating source string. They should contain the DRO's proxy source string.
11582, 11585 | FIXED: Unrecoverable loss with multiple sending threads configured for use_hotlinks.
11527, 11542, 11557, 11580, 11584 | FIXED: Unrecoverable loss events delivered to a hotlinked receiver has no source string. Also, the per-source client data pointer is NULL. Starting with UM version 6.17.1, hotlinked receiver unrecoverable loss events will contain the original source's source string. Note that this is different from non-hotlinked receivers, which have the adjacent DRO's proxy source's source string. See Hotlink Source Strings for full details. Note that for hotlink-enabled receivers, the per-source client data pointer will continue to be passed as NULL with the unrecoverable loss event. This is unavoidable.
11568, 11569 | FIXED: Restarted store with "restore-last" can fail to finish initializing. Repeatedly reports "Store-5688-5257".
11555, 11560 | FIXED: Fatal assert ("[msg->refcnt >= 0]") with hotlinks feature when using spectrum in a receiver application.
11540, 11558 | FIXED: Hotlinked receivers can get unrecoverable loss events for messages that were successfully received by the application. This has only been seen with persistence during initial recovery.
11534, 11549 | FIXED: Hotlinked DROs can "discover" each other, leading to a loss of hotlink functionality (i.e. only one path is active).
11528, 11548 | FIXED: Hotlinked receivers can get an assertion failure ("[dmux->tidx_map->sz == 0]") and deafness for a topic when a DRO fails.
11543, 11547 | FIXED: Hotlinked receivers can crash with a segmentation fault when a DRO fails.
11523 | FIXED: When debug flags are used and LBM_DEBUG_MAX_ROLLOVER_FILES is set, debug filenames are not correct and the number of files is also not correctly limited.
10817, 11514, 11517 | FIXED: LBT-RU can define a port range as a pool of transport sessions using transport_lbtru_port_low (context) and transport_lbtru_port_high (context). Subsequent source creations will assign the sources to the port range in a round-robin fashion. A source can also be explicitly configured for a specific port using transport_lbtru_port (source), which can be outside the low/high range. This is usually done to isolate the topic to a transport session of its own. However, UM incorrectly added the specified port to the pool of ports. As a result, subsequent source creations would re-use the port, adding additional sources to that transport session. Also, specifying an alternate interface can result in topic deafness. Starting with UM version 6.17.1, an LBT-RU source created with an explicitly specified port and/or interface will only apply to that source and will not affect the RU pool. See LBT-RU Explicit Port Use.

## Persistence Fixed Problems and Limitations for 6.17.1 <-

The following bug fixes apply to UMP and UMQ products.

Change Request | Description
--- | ---
11566 | FIXED: Hotlinked receivers of persisted data cannot use ACK batching. It results in premature ACKs. Starting with UM version 6.17.1, hotlinked receivers support persistence ACK batching.
11541, 11559 | FIXED: Hotlinked receivers of persistent data can get recovered data delivered twice. Some of this recovered data can be interleaved with live data, leading to out-of-order message delivery.
11533, 11551 | FIXED: Hotlinked sources of persistent data can start at the wrong sequence number when restarted, typically zero.
11558, 11556 | FIXED: Hotlinked receivers of persistent data can get duplicate deliveries of messages that have already been received and acknowledged. This can happen after a temporary interruption of of one hotlinked data path.
11529, 11531, 11550 | FIXED: Store crash on RX request from receiver while Store is still creating repository file.
11545 | FIXED: Hotlinked receivers of persistent data can prematurely acknowledge messages to the store, risking message loss if the receiver crashes before it completes processing of the message. The result is that after restarting, the receiver is not re-delivered the incompletely processed message.

## Queuing Fixed Problems and Limitations for 6.17.1 <-

The following bug fixes apply to the UMQ product.

- None.

# Special Upgrade Instructions for 6.17.1 <-

## Hotlinks and Source Strings <-

For receivers that have DRO Hotlinks enabled and are receiving messages forwarded by DROs, the source string delivered with received events will be that of the originating source.

This is different from traditional (non-hotlinked) receivers where the source string would be that of the proxy source in the adjacent DRO forwarding the messages.

Applications migrating to hotlinks that rely on the source string being the adjacent DRO's proxy source will need to correlate the originating source string with the proxy source string in the BOS event.

See Hotlink Source Strings for more details.

## Data Hotlinks and Per-Source Client Data <-

For receivers that have DRO Hotlinks enabled, the per-source client data pointer included with the unrecoverable loss event is NULL.

This is different from traditional (non-hotlinked) receivers where the per-source client data pointer is consistent across all event types, including unrecoverable loss.

For applications migrating to hotlinks, this lack of per-source clientd pointer in unrecoverable loss events must be accounted for.

## LBT-RU Explicit Port Use <-

Due to fixing bug 10817, there a behavior change to LBT-RU port usage.

LBT-RU can define a port range as a pool of transport sessions using transport_lbtru_port_low (context) and transport_lbtru_port_high (context). Subsequent source creations will assign the sources to the port range in a round-robin fashion.

A source can also be explicitly configured for a specific port using transport_lbtru_port (source), which can be outside the low/high range. This is usually done to isolate the topic to a transport session of its own.

In the previous buggy behavior, UM incorrectly added the specified port to the pool of ports. As a result, subsequent source creations would re-use the port, adding additional sources to that transport session. This prevents the application from being able to isolate a source to a transport session of its own while still using the pool for general sources.

As of UM 6.17.1, specifying a port outside of the low/high range no longer adds that port to the pool.

If your application depends on the previous behavior, you may have to manage port assignments in your application rather than using the round-robin algorithm.

Note that we don't know of any use cases for the old buggy behavior.

## Previous Special Instructions <-

If you are upgrading from a UM version prior to 6.17, you must also examine the Special Upgrade Instructions for 6.17.

Also see Deprecations.