Informatica

Ultra Messaging (Version 6.16)

Release Notes

[ Multi-page HTML ] | [ PDF ]

Introduction <-

This document describes the important changes made to the Ultra Messaging product family with each new version. This document is cumulative from UM version 6.0 till now, and also across the core Ultra Messaging products: Streaming Edition (UMS), Persistence Edition (UMP), Queuing Edition (UMQ), and the Dynamic Routing Option (DRO).

Note: Release notes for pre-6.0 versions of UM can be found in the UM version 5.3.6 Change Log document. (See also the full 5.3.6 Documentation Set.)

For policies and procedures related to Ultra Messaging Technical Support, see UM Support.

This software and documentation are provided only under a separate license agreement containing restrictions on use and disclosure. No part of this document may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording or otherwise) without prior consent of Informatica LLC.

A current list of Informatica trademarks is available on the web at https://www.informatica.com/trademarks.html.

Portions of this software and/or documentation are subject to copyright held by third parties. Required third party notices are included with the product.

This software is protected by patents as detailed at https://www.informatica.com/legal/patents.html.

The information in this documentation is subject to change without notice. If you find any problems in this documentation, please report them to us in writing at Informatica LLC 2100 Seaport Blvd. Redwood City, CA 94063.

Informatica products are warranted according to the terms and conditions of the agreements under which they are provided.
INFORMATICA LLC PROVIDES THE INFORMATION IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OR CONDITION OF NON-INFRINGEMENT.

See UM Glossary for Ultra Messaging terminology, abbreviations, and acronyms.

Important Corrections <-

When UM version 6.14 was released, an important special upgrade instruction were accidentally omitted from the release notes. Please see Additional C Include Directive.
When UM versions 6.12.1 and 6.13 were released, bug 10676 was incorrectly listed as fixed. It has been moved to Persistence Known Problems and Limitations.
When UM version 6.13 was released, an important special upgrade instruction was accidentally omitted from the release notes. Please see Add LBMRD Interface.
When UM version 6.7 was released, the special upgrade instructions were accidentally omitted from the release notes. Please see Special Upgrade Instructions for 6.7.
When UM version 6.5 was released, the special upgrade instructions were accidentally omitted from the release notes. Please see Special Upgrade Instructions for 6.5.
When UM version 6.5 was released, the deprecations list was accidentally omitted from the release notes. Please see Deprecations for 6.5.

UM Version 6.16 <-

The most significant updates to UM version 6.16 are UDP-based DRO peer links and general bug fixes.

Also see Deprecations.

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

Enhancements for 6.16 <-

Streaming Enhancements for 6.16 <-

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

UDP DRO Peer Links. Prior to UM version 6.16, DRO peer links could only be configured for the TCP protocol. This can introduce high latency spikes and low throughput, especially for long-distance WAN links. UM version 6.16 introduces UDP-based peer links to provide more consistent latency and throughput. See UDP Peer Link.
Updated Windows Toolchain. The UM Windows LBM DLL is now built with Visual Studio 2022.
UM .NET API Targets .NET Standard. Both the Unix and Windows .NET libraries are now built as .NET Standard. This reduces the dependencies of the UM .NET libraries. However, it should not affect their usability by existing UM .NET applications. For example, a windows-based .NET Framework application should built and run OK with the .NET Standard UM library. See .NET Standard.
TCP Keepalives for UIM. TCP Transports have supported SO_KEEPALIVE since UM version 3.3.8. Starting with UM version 6.16 this functionality is added to UIM TCP connections. See TCP Disconnections for more information.
Onload Enhancements. Starting with UM version 6.16, UM sockets can be assigned to Onload stacks on a context basis. Also, UM is changed to not load the Onload dynamic library unless UM is configured to use Onload features. See Solarflare Onload.
Option to Disable NAKs for LBT-RU Receiver. See transport_lbtru_send_naks (receiver).

Persistence Enhancements for 6.16 <-

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

None.

Queuing Enhancements for 6.16 <-

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

None.

Fixed Problems and Limitations for 6.16 <-

Streaming Fixed Problems and Limitations for 6.16 <-

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

Change Request	Description
11356	FIXED: The TCP and IPC transports can log a failed warning assertion, "[tsni_max_len>=LBM_SRC_TSNI_LENGTH]", if the transport datagram maximum size is set to 500 (the documented minimum).
11343	FIXED: The Linux UM library "liblbm.so" had an unnecessary dependency on libnsl.so. This causes a problem for recent Linux distributions that no longer contain that library.
11333	FIXED: The DRO can abort with a fatal assert, "[buff->len<=LBMUIM_APDU]" if a UIM of exactly 65265 bytes is sent.
11327	FIXED: There is a very low probability event that can happen when creating a UM receiver that joins an IPC transport that causes the IPC thread to exit immediately. The symptom is that the program will be deaf to IPC sources. This has only ever been seen on Windows in the Informatica lab; it has never been reported by a user.
11325	FIXED: If an application using Smart Sources attempts to send a message that is larger than the source's configured ume_flight_size_bytes (source), it returns -1 with an lbm_errnum() of 2 (LBM_EWOULDBLOCK) with the lbm_errmsg() of "CoreApi-10055-3012: send would block because of flight size". This is incorrect. The source should return lbm_errnum() of 1 (LBM_EINVAL) with the lbm_errmsg() "CoreApi-6020-9: Payload exceeds flight size bytes maximum, unable to send."
11290	FIXED: If an application is run with Onload configured to active spinning (e.g. setting EF_POLL_USEC=-1), and that application uses TCP-based topic resolution (SRS-based), the context's background thread which communications with the SRS will needlessly consume 100% CPU. This was fixed by setting the socket associated with the SRS connection to ONLOAD_DONT_ACCELERATE.
11143	FIXED: .NET does not support High-resolution Timestamps.

Persistence Fixed Problems and Limitations for 6.16 <-

The following bug fixes apply to UMP and UMQ products.

11311

FIXED: If a non-persistent (streaming) source is created with the UMP or UMQ product, UM will incorrectly allocate memory for that source's flight size buffer, leading to an unnecessarily large memory footprint.

Queuing Fixed Problems and Limitations for 6.16 <-

The following bug fixes apply to the UMQ product.

None.

Special Upgrade Instructions for 6.16 <-

Eliminate 32-bit <-

Starting with UM version 6.16, all support for 32-bit builds is dropped. This includes Daemons and applications.

However, note that earlier versions of UM still support 32-bit. I.e. if you have 32-bit applications built with, say, UM 6.14, Informatica will continue to support those applications. Also, note that those older 32-bit components can transparently interoperate with newer 64-bit components.

The limitation here is that any new functionality introduced in UM version 6.16 and beyond will not be available to your 32-bit applications. I.e. they will be "stuck" at UM version 6.15.

Previous Special Instructions <-

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

UM Version 6.15 <-

The most significant updates to UM version 6.15 are performance improvements for IPC and the persistent Store.

Also see Deprecations.

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

Enhancements for 6.15 <-

Streaming Enhancements for 6.15 <-

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

IPC Speedup. The code for the Transport LBT-IPC is better optimized, especially for multiple subscribers (fanout). No application or configuration changes are necessary to take advantage of this improvement.
SRS Monitoring. The SRS Service (TCP-based topic resolver) now publishes its operational statistics to the Monitoring Collector Service (MCS). See SRS Element "<monitor-format>". See Monitoring for an overview of monitoring an Ultra Messaging network.
Improved UDP Message Reception. When the multiple_receive_maximum_datagrams (context) option is used, memory management is now more efficient, leading to a small increase in maximum sustainable throughput.
MCS without license key. A UM license key is no longer needed to run the Monitoring Collector Service (MCS).
UDP Topic Resolution Reduction. Bug 11037 was fixed with an enhancement that provides a mild reduction in UDP-based topic resolution traffic when applications get an EOS event.

Persistence Enhancements for 6.15 <-

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

Store Initialization Speedup. When a disk-based Store is restarted, it restores previously saved messages from the cache file. This message restoration is now optimized in two ways:
1. Messages are read more quickly.
2. The Store can be configured to read a subset of saved messages when restarted; see Limit Initial Restore with Restore-Last for more information.
Proxy Source Election. Some users will be interested in an improved algorithm for proxy source election. See Proxy Source Elections.

Queuing Enhancements for 6.15 <-

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

None.

Dynamic Router Enhancements for 6.15 <-

As of UM version 6.15, DRO enhancements/fixes are included in the streaming section and are applicable to UMS, UMP, and UMQ. This is because the DRO now included with all three products.

Fixed Problems and Limitations for 6.15 <-

Streaming Fixed Problems and Limitations for 6.15 <-

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

Change Request	Description
11063	FIXED: A UM version 6.14 SRS can get into a state where control messages are sent and received at a very high rate. This is difficult to reproduce, and is related to a named Store being restarted on a network containing a DRO. SRS users with named Stores and DROs should upgrade at least their SRSes, DROs, and Stores to UM version 6.15.
11055	FIXED: An application can get a crash (seg fault) if an event queue is shut down while a context/XSP is still enqueuing events to it.
11111, 11112, 11190	FIXED: Application crash (seg fault) when configured for automonitoring using monitor_transport set to lbmsnmp.
11146, 10387	FIXED: When source-side filtering is enabled but there is a network problem leading to packet loss when the connection is being set up, the receiver can be deaf to messages.
11269	FIXED: When the DRO is configured to send stats using protobuf, the DRO portal-specific stats are not sent.
11153	FIXED: When a source send fails, typically due to an application coding or configuration error, UM improperly increments its internal sequence number state.
11270	FIXED: A small memory leak in the DRO when protobuf stats are enabled.
11247	FIXED: A wildcard receiver can leak a small amount of memory when a matching source exits and times out.
11015	FIXED: Store initialization very slow on large repository. This was fixed with a new feature: Limit Initial Restore with Restore-Last.
11037	FIXED: Spike in topic resolution seen after EOS is delivered to application. This was fixed with an enhancement that reduces topic resolution traffic after an EOS. No changes in code or configuration are needed to take advantage of this enhancement.
10529	FIXED: Added destination IP address to certain socket errors (including no route to host).

Persistence Fixed Problems and Limitations for 6.15 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
11206	FIXED: Store can crash if configured for RPP, the Store is writing to disk, and the Store is restarted.
11072	FIXED: When a memory-only Store is run in RPP mode, a "down" blocking receiver will not block the source. Although this bug is fixed, Informatica does not recommend using a memory-only Store in RPP mode.
11082	FIXED: The Store can crash with a fatal assertion: `[EMERGENCY]: FATAL: failed assertion [info->sqn == DMON_GET(repo, mem_trail_sqn)]` when the Store experiences unrecoverable loss during late join, incoming data, and data being written to disk. This is VERY difficult to reproduce.
11087	FIXED: Persistent sources set with very large flight size limits (in the hundreds of thousands or more) can experience very long source registration times and shutdown times of many tens of seconds. The delays are now somewhat reduced, but very large flight sizes are not recommended.
11127	FIXED: If a Store is configured for sending daemon statistics over protobufs, the stats message can get too big to send. This is only when large numbers or sources and/or receivers are connected to the same Store process. Store monitoring messages are now separated into three messages. See Store Protobuf Monitoring for special upgrade instructions.
11123	FIXED: The Store can crash when the state/cache directory plus file name is more than 255 characters long. Note that even with the fix, the cache directory and the state directory paths are limited to 230 ASCII characters. If that limit is exceeded, UM will print an error and exit.
11140	FIXED: A publisher using the Smart Source API to send UM requests on a persistent source can fail with: `FATAL: failed assertion [info->sqn == ctlr->trail_sqn]`
11152, 11156	FIXED: The Store can crash when sequence numbers roll over from 0xFFFFFFFF to 0, with the message: `[EMERGENCY]: FATAL: failed assertion [repo->batch_end_sqn>=repo->batch_start_sqn]`
10166, 11162	FIXED: If topic resolution and SRI messages don't arrive in proper order, a restarted store can be deaf to a source.
9777	FIXED: Store can crash with log message: `FATAL: failed assertion [rctxinfo->rctx==NULL]...`
11167	FIXED: Store sometimes logs the warning: `WARNING: failed assertion [client->sid==sid]...`
10552	FIXED: When SRI requests time out in a persistent receiver due to a short-term network outage, the receiver can remain deaf after the network is restored. Retries were added. Note that warnings are logged periodically with each retry.
11177	FIXED: Proxy source can sometimes re-register on cleaned Store.
10946, 10930	FIXED: Proxy source can sometimes be repeatedly created and deleted by different stores ("rolling" behavior).
11245	FIXED: A misconfigured persistent publisher can result in a Store crash (seg fault). The specific configuration error is that the source's list of Stores has some Stores specified with registration IDs and others not.

Queuing Fixed Problems and Limitations for 6.15 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.15 <-

As of UM version 6.15, DRO enhancements/fixes are included in the streaming section and are applicable to UMS, UMP, and UMQ. This is because the DRO now included with all three products.

Special Upgrade Instructions for 6.15 <-

Reduced FD Store Discontinued <-

As of UM version 6.15, the "Reduced FD Store" feature is removed from the product. Users of reduced-FD should migrate to repository-type "disk".

Store Proxy Source Election <-

For persistence users who enable proxy sources on their Stores, Informatica recommends enabling the new Store configuration option: Store Option "proxy-source-repo-quorum-required".

See Proxy Source Elections for details.

Store Protobuf Monitoring <-

Due to bug 11127, the Store's daemon statistics using protobuf format had to be separated into three message types:

Configs
Stats
Events

If you have written code to process protobuf format Store daemon stats, you will need to revisit that code. See Example ump_mon.proto for the Store's protocol buffer definition file. Your code can look at the message type to differentiate between old vs. new Store stats.

Previous Special Instructions <-

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

UM Version 6.14 <-

The most significant update to UM version 6.14 is further enhancement of TCP-based Topic Resolution (DRO compatibility).

Also note UM version 6.14 announces the deprecation of several features. See Deprecations.

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

Enhancements for 6.14 <-

Streaming Enhancements for 6.14 <-

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

SRS and DRO. TCP-based Topic Resolution now has full functionality (except lbmrd-based Network Address Translation (NAT), which is not planned at this time). Users of DRO can now use the SRS instead of UDP-based TR. See TCP-Based Topic Resolution Details. Includes the introduction of a new configuration option: resolver_disable_udp_topic_resolution (context).
Monitoring. A new monitoring infrastructure is available which unifies transport statistics with Store and DRO statistics. As part of this, automatic monitoring now supports reporting of topic-to-transport mappings. See Monitoring and Monitoring Collector Service (MCS).
Fragmentation and MTU. Dynamic Fragmentation Reduction allows users of kernel bypass drivers (like Solarflare's Onload) to avoid premature UM fragmentation of messages into multiple datagrams that should fit in a single MTU, while also avoiding IP fragmentation that can happen if datagram max size is set above 1472. See Dynamic Fragmentation Reduction.

Note: this enhancement should address known issue 10985.
The .NET API now supports XSP. See Example lbmrcvxsp.cs.
Smart Source Requests. The Smart Source C API now supports the sending of UM requests. Note that this enhancement does not support Java, .NET, UM fragmentation, message properties, or spectrum channels. See Request/Response, lbm_ssrc_send_request_ex() and Example lbmssrcreq.c.
Sparc, Darwin (MacOS / OSX). Informatica no longer ships the Sparc or Darwin (MacOS / OSX) platforms with every new version of UM. Instead, Sparc and Darwin are now considered "on demand" platforms. Note that Sparc and MacOS are still supported platforms for UM. Customers of the Sparc and/or Darwin platforms may specifically request that a build be generated for the most-recent general UM version.
Jars. The UM jar files for Java are now included in the UM package files. Unpacking the package file will now provide a "java" sub-directory that contains the jar files.

Persistence Enhancements for 6.14 <-

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

None.

Queuing Enhancements for 6.14 <-

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

None.

Dynamic Router Enhancements for 6.14 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.14 <-

Streaming Fixed Problems and Limitations for 6.14 <-

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

Change Request	Description
10863	FIXED: A variety of UM configuration validation error messages do not report the topic name associated with the invalid configuration.
10965	FIXED: Starting with UM version 6.11, Windows UM cannot load XML configuration files via HTTP.
10997	FIXED: The SRS is missing the "-E" command-line option for setting environment variables for Windows services.
10992	FIXED: The various UM example applications are inconsistent regarding the treatment of multiple "-c file1 -c file2" options on a command line. Some apps will load every file specified, but some apps will only load the last file specified. All application now support multiple "-c file1 -c file2" options in the same way: by loading every file specified.
10654	FIXED: When UM detects outages of unicast Topic Resolution, the logs were classified as "notice" or "warning". However, since the loss of topic resolution can lead to "deafness", the messages should be classified as errors. This is especially a problem for the DRO. This change applies to all applications and daemons. Note that the message was given a new ID number. Removed: WARNING Core-10403-03: SRS Controller Connection (%p) SID (0x%x) got a disconnect from the Server (%s:%u) Local Addr (%s:%u) Replaced with: ERROR Core-10654-02: SRS Controller Connection (%p) SID (0x%x) got a disconnect from the Server (%s:%u) Local Addr (%s:%u) This change applies only to the DRO: Added: ERROR Core-10654-1: unicast resolver %s:%u went inactive after having previously been active Finally, note that for non-DRO components, including user applications, the following message remains as a notice: No change: NOTICE Core-5688-3375: unicast resolver %s:%u went inactive

Persistence Fixed Problems and Limitations for 6.14 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
11019, 11053	FIXED: A change in UM version 6.13 resulted in SPP-configured persistent sources experiencing periodic latency outliers and hitting flight size (LBM_EWOULDBLOCK send failures).
11046	FIXED: The persistent Store process can hang during initialization on Windows-64. This has only been seen on 64-core servers. A stack trace indicates the hang is inside the SmartHeap 3rd party package.
11046	FIXED: The persistent Store process can hang during initialization on Windows-64. This has only been seen on 64-core servers. A stack trace indicates the hang is inside the SmartHeap 3rd party package.
11026	FIXED: The persistent Store process can experience severe memory growth over time. This has only been seen on Windows-based 64-bit servers. The problem has been traced to the SmartHeap 3rd party package.
11022	FIXED: The umesnaprepo example application cannot be built on Windows due to unresolved symbols lbm_srp_...
11005	FIXED: If an SPP store experiences unrecoverable burst loss, it can lead to significant memory growth.
8013, 11000, 11001	FIXED: If an RPP Store had to write some messages to disk at some point in the past, and then the Store and publisher restart, the source can restart at the wrong sequence number.
10984	FIXED: If a persistent receiver is assigned to an XSP, a memory corruption can happen resulting in unpredictable behavior, including crashes.
10981	FIXED: If a non-UME example application is configured to use persistence, the unexpected events delivered did not produce helpful error messages.

Queuing Fixed Problems and Limitations for 6.14 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.14 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

Special Upgrade Instructions for 6.14 <-

Additional C Include Directive <-

Starting with UM version 6.14, users should compile C programs with an additional include directory. Prior to UM 6.14, applications only needed to supply "-I $UM_PLAT/include" where "$UM_PLAT" is the path to the platform-specific directory of a UM installation. In versions 6.14 and beyond, applications should supply "-I $UM_PLAT/include -I $UM_PLAT/include/lbm".

For example:

gcc -I /UMP_6.14/Linux-glibc-2.17-x86_64/include \
    -I /UMP_6.14/Linux-glibc-2.17-x86_64/include/lbm \
    ...

Without this, you may encounter a build error where the compiler is unable to find the include file "gen/um_mon_attributes.pb-c.h".

Previous Special Instructions <-

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

UM Version 6.13.1 <-

The most significant update to UM version 6.13.1 is an upgrade to the latest OpenSSL.

Attention: There are some special upgrade instructions for UM versions 6.13.1 and beyond that will affect some users upgrading from pre-6.13.1 versions of UM. See Special Upgrade Instructions for 6.13.1. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.13.1 <-

Streaming Enhancements for 6.13.1 <-

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

OpenSSL 1.1.1g. UM's Encrypted TCP feature has been upgraded to use OpenSSL version 1.1.1g.

Persistence Enhancements for 6.13.1 <-

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

None.

Queuing Enhancements for 6.13.1 <-

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

None.

Dynamic Router Enhancements for 6.13.1 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.13.1 <-

Streaming Fixed Problems and Limitations for 6.13.1 <-

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

Change Request

Description

10965

FIXED: UM on the Windows platform was not able to load XML configuration files via the HTTP protocol.

10932, 10970

FIXED: UM versions 6.12, 6.12.1, and 6.13 on Linux suffered a minor speed degradation, visible in certain minimal ping/pong tests. No degradation has been reported during testing of production applications.

As part of fixing this, the Linux 64-bit UM versions 6.13.1 and beyond must have access to a glibc of version 2.14 or higher. See Minimum Required Glibc Version.

10979, 10980

FIXED: Enabling Compressed TCP on the Solaris X86 64-bit platform can result in a segmentation fault inside "LZ4_copy8()".

Persistence Fixed Problems and Limitations for 6.13.1 <-

The following bug fixes apply to UMP and UMQ products.

10911, 10934

FIXED: The Store can fail with a segmentation fault or a fatal assert ("info->sqn == DMON_GET(repo, mem_trail_sqn)" when it is configured to use TCP-based Topic Resolution and it is restarted while the persistent source is actively sending.

10976, 10978

FIXED: If an SPP Store running UM version 6.12, 6.12.1, or 6.13 is restarted without deleting the state and cache files, it can enter a state where it does not resume persisting messages. That store also stops sending stability ACKs to the source.

Queuing Fixed Problems and Limitations for 6.13.1 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.13.1 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

Special Upgrade Instructions for 6.13.1 <-

Minimum Required Glibc Version <-

Due to fixing bug 10932, some Linux users will need to use a newer version of the glibc library than is standard on their version of Linux. Linux 64-bit UM versions 6.13.1 and beyond must have access to a glibc of version 2.14 or higher. For example, RHEL-6 systems come standard with glibc 2.12. To determine the glibc shipped with a wide variety of Linux distros, see this distrowatch query for glibc (look for "Red Hat").

If your 64-bit Linux system does not have glibc 2.14 or higher, Informatica does NOT recommend replacing your existing glibc with a newer one.

The best approach is to upgrade to a newer version of Linux. Note that RHEL-6 will end its maintenance support on November 30, 2020.

However, we recognize that upgrading your Operating System is a disruptive and expensive activity. We have had good luck using glibc 2.14 on CentOS-6 (Red Hat's non-enterprise version of RHEL-6). Here are the steps we followed:

download glibc 2.14.
Build it locally. Do NOT install it in the standard location. You want the new version to co-exist with your OS's standard version.
To run an application with UM version 6.13.1 or beyond, set the environment variable "LD_PRELOAD" to the path of the "libc.so.6" file built in step 2.

Remember, you don't want to replace the standard glibc for your OS.

Finally, note that if your application was built against UM version 6.7 or beyond, you are not required to rebuild your application; you can simply use the existing executable. This glibc upgrade won't affect your application's use of glibc.

Previous Special Instructions <-

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

UM Version 6.13 <-

The most significant updates to UM version 6.13 are enhanced TCP-based Topic Resolution (redundancy and scalability), and Persistence performance improvements.

Attention: There are some special upgrade instructions for UM versions 6.13 and beyond that will affect a small percentage of users upgrading from pre-6.13 versions of UM. See Special Upgrade Instructions for 6.13. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.13 <-

Streaming Enhancements for 6.13 <-

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

Redundant SRS. The Stateful Resolver Service (SRS) can now be deployed redundantly. UM components can be configured for multiple instances of SRS. If one SRS goes down or is cut off from the network, the other SRSes will continue to provide Topic Resolution service. See TCP-Based TR and Fault Tolerance for details.
SRS traffic reduction. The SRS now supports tracking of topics that each context is interested in (has receivers for). This allows for further reduction of TR traffic by filtering source advertisements based on topic interest. Note that this can interfere with the resolver_source_notification_function (context) and resolver_event_function features. See TCP-Based TR Interest for more information.
Configuration error handling. A change has been made to how configuration file errors are handled - they can now be treated as "warnings" instead of "errors". See Configuration Error Handling for details.
Windows Services Most of the UM daemons running as Windows Services can now have a file configured to set desired environment variables for the Service process. See Configure the Windows Service (the "-E" option).

Persistence Enhancements for 6.13 <-

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

Performance improvements Persistence throughput is increased of both storage of new messages and recovery of stored messages.
Improved recovery rates. Fixing bug 10877 allowed a change to the default value for Store option repository-disk-max-read-async-cbs from 16 to 10,000. This improves receiver recovery rates. See Special Upgrade Instructions for 6.13.

Warning
If your Store configuration specifies a value for repository-disk-max-read-async-cbs, you might see your recovery performance decrease. See bug 10877.
Thread affinity. The UM Store Daemon can now set thread affinity to "pin" threads to one or more desired CPU cores. This can provide a significant improvement in throughput. See Store Thread Affinity.
Marking messages in Store. Selected messages in the Persistent Store can now be marked as invalid, to prevent them from being delivered to a recovering receiver. This can be useful if a misbehaving publisher sends a "poison" message that causes receivers to crash; having that message in the Store's repository means that restarting the failed receiver will just cause it to crash again when the message is recovered. See Request: Mark Stored Message Invalid.

Warning
If misused, this feature allows a user to interfere with message delivery. By default, this feature is disabled. However, especially if you have enabled UMP Element "<remote-config-changes-request>", Informatica recommends Securing Daemon Control Requests.
Forced de-registration. A failed receiver can now be de-registered from a Persistent Store. This will delete the state information for that receiver. See Request: Deregister Receiver.

Warning
If misused, this feature allows a user to interfere with message delivery. By default, this feature is disabled. However, especially if you have enabled UMP Element "<remote-config-changes-request>", Informatica recommends Securing Daemon Control Requests.
Message extraction from Store. A Persistent Store's state and cache files can now be statically analyzed, and stored messages can be extracted. See Store Repository Profiling (SRP).

Queuing Enhancements for 6.13 <-

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

None.

Dynamic Router Enhancements for 6.13 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.13 <-

Streaming Fixed Problems and Limitations for 6.13 <-

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

Change Request	Description
10726	FIXED: When the multiple_receive_maximum_datagrams (context) option is used, undesired latencies can be introduced by multiple Topic Resolution or MIM datagrams being processed in a row. The option now only affects LBT-RM and LBT-RU transports. It no longer applies to Topic Resolution or MIM.
10794	FIXED: In a race condition related to the closing of a socket, it is possible to get: `Core-5455-1: epoll_ctl: EPOLL_CTL_DEL ...` or: `Core-5455-2: lbm_fd_cancel epoll_ctl: epoll_op: ...` or: `FATAL: failed assertion [epoll_err==0]` (due to the unpredictable nature of race conditions, there may be other symptoms as well.)
10685	FIXED: In UM version 6.12, a dependency was added to UM for a dynamic library for "rsock", which is used for communication with the SRS. However, a static form of the rsock library was not provided. As of UM version 6.13, the "rsock" code is now provided in static form. It is included in the "liblbm.a" library.
10841	FIXED: A hot failover receiver can crash with: `FATAL: failed assertion [hfrcv->timer_id == -1]`
10822	FIXED: The SRS Daemon Statistics "clients.DR.inactive.SIR.count" and "clients.DR.inactive.SIR.count" are incorrectly classified as errors and are included in the SRS_ERROR_STATS message type. The counters "clients.DR.inactive.SIR.count" and "clients.DR.inactive.SIR.count" have been moved to be in the SRS_STATS message type. See Message Type: SRS_STATS.
10777	FIXED: Inadvertent connection to TCP source from a UIM Request Client results in a memory leak. Note that while the memory leak is fixed, it is still not valid for an application to send a UIM to a port that is used by a TCP source.
10657	FIXED: There are cases where the use of a Hot Failover (HF) receiver will inhibit the delivery of unrecoverable Tail Loss events.
9917	FIXED: When using LBT-RU, packet lengths are sometimes improperly set according to LBT-RM's maximum datagram size. This can result in errors of the form: `Core-5688-449: LBMC datagram malformed`

Persistence Fixed Problems and Limitations for 6.13 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
10877	FIXED: Large values for repository-disk-max-read-async-cbs can lead to unresponsive Stores during large message recovery operations by receivers. As of UM version 6.13, changes in the internal threading model of the Store avoids contention between receiver message recovery handshaking with the Store, allowing higher recovery performance without degrading responsiveness. Associated with this fix is a change in the default value for repository-disk-max-read-async-cbs from 16 to 10,000. Users are recommended not to explicitly set a value for repository-disk-max-read-async-cbs and instead simply allow it to default. See Special Upgrade Instructions for 6.13.
10849	FIXED: If using LBT-RU transport with Smart Sources, and two or more sources are mapped to the same transport session, deleting one of them leaves the other sources on the same session corrupted. This can result in segmentation faults or other bad behaviors.
10818	FIXED: If a persistent receiver configuration does not set values for ume_state_lifetime (receiver) and ume_activity_timeout (receiver) (both default to zero), the store's value of receiver-state-lifetime is not used to determine the receiver's state lifetime, as it should be. Instead, the value of receiver-activity-timeout is used.
10867	FIXED: If a Source initially registers with a Store with Proxy Sources disabled, and then the source restarts and registers with Proxy Sources enabled, the Store fails with a segmentation fault. This sequence no longer causes the Store to crash. However, changing the Proxy Source configuration is not permitted across a re-registration. See Registration Limitations.
10811	FIXED: There are certain sequences of shutting down and restarting persistent receivers and stores that can result in multiple entries for the same source registration on the Store Web Monitor. For this problem to happen, the receiver must use the deregistration API.
10808	FIXED: If a session ID value is chosen that exceeds 231, it is displayed on the Store Web Monitor as a negative number. Session IDs are now displayed as 32-bit unsigned numbers.
10765	FIXED: For all UM versions 6.11. and 6.12., the Store logs the warning: `Core-5688-28: WARNING: context config variable receive_thread_pool_size is deprecated` This warning is benign and can be ignored. As of UM version 6.13, this warning is removed altogether.
10737	FIXED: A registering RPP receiver can get old messages replayed after a store is shut down, the state and cache files deleted, and the store restarted. This bug is caused by the cleanly restarted Store requesting Late Join message recovery from the Source, and the receiver registering with the Store during the late join process. The receiver is mistakenly told to start with the sequence number of the next message to be recovered by Late Join. As of UM version 6.13, when a receiver registers with a store and that store has no state information for that receiver, the receiver will be told to start with the sequence number that the source's live messages are at.
10733	FIXED: When a persistent receiver restarts after a period of being down, and the Store's retention policy has led to messages no longer being available, the receiver's persistent delivery controller does not properly use the value of delivery_control_maximum_burst_loss (receiver) when delivering loss events to the receiver callback. That is, even if the number of missing messages exceeds the configured value of delivery_control_maximum_burst_loss (receiver), UM still delivers a separate loss event for every missing sequence number. The persistence delivery controller will now deliver a single "burst loss" event if the number of missing messages exceeds delivery_control_maximum_burst_loss (receiver).
10661	FIXED: When sending messages using a Smart Source in Java, if the messages contain message properties and are larger than the datagram maximum size (requiring UM fragmentation), a crash can result.
10805	FIXED: When a UM configuration file is supplied to the UMP Element "<daemon-monitor>", source-scoped options are not applied.
10483	FIXED: There are rare circumstances under which a persistent receiver becomes deaf to some number of new messages sent by a source due to the receiver's expected sequence number being higher than the source's live sequence numbers. This typically happens when the source is restarted after a period of store overload, or through product misuse. The receiver registration now ensures that the low sequence number is never higher than the high, which allows all live messages sent by the source to be received. See Persistent Receiver and Duplicate Messages for more information.

Queuing Fixed Problems and Limitations for 6.13 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.13 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request

Description

10856

FIXED: A DRO can crash with:
FATAL: failed assertion [len<LBMC_MAX_TOPICNAME_LEN]
if a source or receiver is created with a topic name of exactly 246 characters (not including a final null).

10826

FIXED: A DRO can crash with a segmentation fault when used with an SRS for TCP-based Topic Resolution. In a stack backtrace it happens in lbm_topic_resolve_process_tir().

10588

FIXED: When a UM configuration file is supplied to the Router Element "<daemon-monitor>", source-scoped options are not applied.

Special Upgrade Instructions for 6.13 <-

Add LBMRD Interface <-

Users must specify an interface to "lbmrd".

Due to fixing bug 10937, some users of UM version 6.13 and beyond will need to slightly change their Unicast UDP Topic Resolution daemon "lbmrd" usage. If you do not specify an interface for lbmrd, it will appear that lbmrd doesn't work, although no error messages will appear in its log file.

Starting with UM version 6.13, an interface specification must be provided, either via the command-line using the "-i" option (see Lbmrd Man Page), or via the "<interface>" XML configuration element (see LBMRD Element "<interface>"). Note that an easy and flexible method for specifying the interface is using CIDR notation, such as "10.0.0.0/8". This matches any interface whose IP address starts with 10.

Upgrade order: Persistence and DRO <-

Applications running UM version 6.13 and beyond have a potential incompatibility with pre-6.13 DROs. Due to Known Limitation 10833, Informatica recommends upgrading DROs before Persistent Stores. This only applies to users who upgrade gradually; for users who upgrade everything at once, this issue does not apply. See Order of Upgrades.

repository-disk-max-read-async-cbs <-

As a result of improving the overall performance of the Store, there is a condition where receiver message recovery performance can be significantly degraded if repository-disk-max-read-async-cbs is configured for a small number. In the past, this option needed to be small, due to bug 10877. However, as of UM version 6.13, this restriction has been lifted, and the default value changed to a more appropriate value.

If your Store configuration includes repository-disk-max-read-async-cbs, Informatica recommends removing the setting and allowing it to operate with its default value.

SRS Daemon Statistics Change <-

This is for users who have written monitoring applications that consume SRS Daemon Statistics. The counters "clients.DR.inactive.SIR.count" and "clients.DR.inactive.SIR.count" have been reclassified as non-errors, and moved to message type SRS_STATS. See bug 10822.

Persistent Receiver and Duplicate Messages <-

Due to fixing bug 10483, there is a certain use case in which there is an increased chance of a persistent receiver getting messages re-delivered that it had already processed (duplicate messages). It is important for persistent receivers to be able to detect duplicate messages after a registration; see Duplicate Message Delivery.

The use case affected by this bug fix is where a restarted sending application is able to re-send previously sent messages based on the starting sequence number. When a restarted source registers with the Stores, the Stores can tell the sender to start at an earlier sequence number than was previously sent. This can happen, for example, if the Stores experience tail loss right before the source restarts. It is unlikely, but possible.

In this use case, the sending application looks at the starting sequence number from the store and is able to reconstruct the previously-sent messages, starting at the given sequence number. This has the advantage that the Stores are correctly populated with the missing message data.

Starting with UM version 6.13, all receiving applications will have these messages delivered. This can be true even if a receiver has received those messages and acknowledged them to the Store. So with the use case where the sender is re-sending previously-sent messages, UM will deliver these messages again to the receiving application. However, note that if the application has successfully ACKed messages and UM is about to re-delivery them, the UM will log the message:
Core-10483-1: WARNING: UMP receiver Low sequence number[0xx] is greater than the High sequence number [0xx] + 1. Setting to high + 1. Receiver will join the live stream and no messages will be recovered.

Note that the sequence numbers will match the previous transmissions. The application can keep track of the highest sequence number received for that source and skip any delivered messages equal to or less than that saved number. (For use cases where the sender always starts sending new messages after a restart, do not skip those messages.)

Also note that some applications use the LBM_MSG_FLAG_UME_RETRANSMIT flag bit in a message's lbm_msg_t_stct::flags field to indicate the message is recovered from the store and therefore subject to possible duplication. However, in the case of a restarted source, the messages are "live" and therefore don't have the LBM_MSG_FLAG_UME_RETRANSMIT flag set.

Platform Reduction for 6.13 <-

Starting with UM version 6.13, UM Daemons will not be supported on platforms other than Linux and Windows.

Previous Special Instructions <-

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

UM Version 6.12.1 <-

The most significant updates to UM version 6.12.1 are the introduction of .NET on Linux, and a "busy wait" option for context threads.

Attention: There are some special upgrade instructions for UM versions 6.12 and beyond that will affect a small percentage of users upgrading from pre-6.12 versions of UM. See Special Upgrade Instructions for 6.12. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.12.1 <-

Streaming Enhancements for 6.12.1 <-

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

.NET on Linux. UM now supports the Microsoft .NET framework on 64-bit Linux. See Using UM .NET on Linux.
Busy Looping. The Network Socket Busy Waiting feature can be used to prevent a context or XSP thread from sleeping while waiting for network events, such as received packets. This can reduce latency and especially latency outliers (jitter).
OpenSSL optional. The dependency between UM and the OpenSSL libraries is now optional. If the libraries are not used, then they do not need to be present on the system. See OpenSSL Dependency for more information.

Persistence Enhancements for 6.12.1 <-

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

None.

Queuing Enhancements for 6.12.1 <-

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

None.

Dynamic Router Enhancements for 6.12.1 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.12.1 <-

Streaming Fixed Problems and Limitations for 6.12.1 <-

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

Change Request

Description

10702, 10713, 10741

FIXED: UM has a load-time dependency on a specific version of OpenSSL. If the expected version is not present, the application can be unable to load and run, or it can write warning messages to the log file (Core-9565-109 and Core-9728-14), even if encryption services are not configured for use.

For more information, see OpenSSL Dependency.

10792, 10793

FIXED: When an application is built with the UM 6.12 static library, diagnostic error information might not be properly communicated from a failed API call. A bad status will be returned, but the error code and message will be empty. To our knowledge, there will be no adverse behavior, but the loss of error information makes problem diagnosis very difficult.

This problem is fixed in UM version 6.12.1 and beyond.

none

FIXED: The UM documentation main page does not render correctly in some environments, possibly due to the use of deprecated HTML frames.

The UM documentation main page is now simplified.

Persistence Fixed Problems and Limitations for 6.12.1 <-

The following bug fixes apply to UMP and UMQ products.

Change Request

Description

9940, 10131, 10651, 10734

FIXED: If a persistent publisher sends a message containing one or more Message Properties, and the Proactive Retransmission feature is used to record the message on the Store, a receiver which recovers the message from the Store will crash with a fatal assert:
FATAL: failed assertion [prop_offset >= 0]

10765, 10788

FIXED: Store log always contains "[WARNING]: Core-5688-28: context config variable receive_thread_pool_size is deprecated. Has no effect."

Queuing Fixed Problems and Limitations for 6.12.1 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.12.1 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

UM Version 6.12 <-

The most significant update to UM version 6.12 is the introduction of a TCP-based Stateful Topic Resolution Service (SRS) which optimizes the Topic Resolution Process.

Attention: There are some special upgrade instructions for UM version 6.12 that will affect a small percentage of users. See Special Upgrade Instructions for 6.12. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.12 <-

Streaming Enhancements for 6.12 <-

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

TCP-Based Topic Resolution. 6.12 introduces a new component, the SRS (Stateful Resolution Service). This is the first phase of a plan to significantly improve UM's topic resolution characteristics. The SRS service can be run on 64-bit Windows and 64-bit Linux. (An SRS running on either one of those platforms can service clients across the full range of supported platforms.)

For more information, see Topic Resolution Description.
Streaming Receiver Optimization. Message receive latency has been improved with the following features:
Smart Source Message Sizing Flexibility. The Smart Sources feature now supports greater flexibility in application message sizes, including:
- UM Message Fragmentation.
- User Supplied Buffers.
For more information, see Smart Source Message Buffers.

Also, a problem in Smart Source was fixed (see Fixed Limitation 10567) which users of Smart Source need to be aware of. Some users will need to change their configuration as a result. See Smart Source Header Size Change for details.
Windows Service Enhancements. Support for running the 3 main pre-6.12 UM Daemons as Windows Services has been improved. This includes the UM Message Router (DRO), the persistent Store, and the unicast topic resolution daemon (lbmrd). The new service, SRS, is introduced with the same support for Windows Service. (Note that the Ultra Messaging Manager daemon ummd is not available as a windows service at this time.) For more information, see UM Daemons as Windows Services.
XSP Enhancements. The Transport Services Provider (XSP) feature has been enhanced to support the following new capabilities:
- Registration of File Descriptors. The Transport Services Provider (XSP) feature has been enhanced to support registration of application file descriptors. For more information, see Other XSP Operations.
- Persistence. Persistent receivers can now be assigned to a Transport Services Provider (XSP).
Leading Loss Events Suppressed. UM no longer delivers unrecoverable loss events to receiver callbacks prior to the first message delivery. See bug 5199.
AIX. Informatica no longer ships the AIX platform with every new version of UM. Instead, AIX is now considered an "on demand" platform. Note that AIX is still a supported platform for UM. Customers of the AIX platform may specifically request that an AIX build be generated for the most-recent general UM version.
Daemon Platform Deprecations. The original 6.11.1 release notes announced the deprecation of certain platforms for UM daemons, claiming that they would be discontinued in UM version 6.12. However, some users requested more time for the transition. As of UM version 6.12, these deprecated daemon platforms have not yet been removed, and are therefore still fully supported in 6.12. Starting with UM version 6.13, the UM daemons will no longer be available on certain platforms. See Platform Deprecations for Daemons.

Persistence Enhancements for 6.12 <-

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

XSP. Persistent receivers can now be assigned to a Transport Services Provider (XSP).
Receiver re-registration. Persistent receivers can now re-register with a store immediately following certain events. See bug 5890.

Queuing Enhancements for 6.12 <-

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

Ultra Load Balancing Throughput. The Ultra Load Balancing (ULB) feature has been enhanced to significantly improve throughput when used with unicast transport protocols TCP and LBT-RU. For more information see ULB Performance.

Dynamic Router Enhancements for 6.12 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.12 <-

Streaming Fixed Problems and Limitations for 6.12 <-

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

Change Request	Description
10567	FIXED: Smart Sources reserved a differing amount of space for worst-case headers than traditional sources. For users of kernel bypass network drivers like Onload, this can lead to having to set the transport_lbtrm_datagram_max_size (context) option to different values for apps using Smart Sources vs. apps that do not. For apps that use both, this creates a sub-optimal solution for one or the other. UM now uses the same reserve size for Smart Sources as it always has for traditional sources. Attention Users of Smart Source may need to update their configuration because of this. See Smart Source Header Size Change.
10542	FIXED: When an XSP user's transport_mapping_function callback is invoked, the second parameter is: `"lbm_new_transport_info_t *info"` which has the field `"char source[LBM_MSG_MAX_SOURCE_LEN];"`. However, that field does not contain the source string. Note To pre-6.12 users who worked around this problem by defining `"LBM_INTERNAL_USE_ONLY"`: your application will continue to work properly with 6.12 without any need to recompile. However, we do recommend that you remove the LBM_INTERNAL_USE_ONLY definition when it is convenient.
5199, 9415	ENHANCEMENT: There are a variety of circumstances where a newly-created streaming receiver will be delivered unrecoverable loss events before the first message is received. This is normally not useful to the application since it does not represent a gap in the received message stream, but rather just difficulty in getting successfully joined to the stream. UM now will suppress unrecoverable loss events prior to the first message delivery. Informatica believes that this new behavior is the correct behavior for UM, and that there should be no cause for concern by users. This behavior change does not apply to Persisted data streams where delivery of all messages is important. See Leading Loss for more information.
3398	FIXED: Windows-based UM closes TCP connections abruptly, causing TCP "RST" packets on the network, and "connection reset" warnings in UM log files. Windows-based UM now closes TCP connections gracefully.
10518	FIXED: When installing UM on a Windows machine using the UM package installer, the system PATH can be corrupted or cleared if the updated length is greater than 1023 bytes. This is related to a limitation in the Windows installer that UM uses; it fails on long PATH content. UM had a bug in which UM did not detect the failure and instead wrote the bad PATH. UM has been updated to detect the failure, issue an error, and not update the PATH.
10380, 10381	FIXED: lbm_rcv_delete_ex and lbm_wildcard_rcv_delete_ex can crash when unsubscribing from spectrum channels.
10469, 10486, 10466	FIXED: When sending a message using a Smart Source send API, UM can crash with a failed assertion of the form: `"failed assertion [...-\>sminfo.timer_id == -1]"`. This happens when a TSNI is in the process of being sent by the context thread at the same time that the application sends a message.
10492	FIXED: When the lbmrd is configured for incorrect interface specification, either in its XML configuration file, or on the command line, the lbmrd did not detect any error and appears to be running. However, it does not function. Also, the lbmrd does not accept interface specifications other than a simple IP address. The lbmrd interface can now be specified as a simple IP address, a CIDR network specification (e.g. 10.1.2.0/24), a quoted device name (e.g. "eth0"), or a DNS host name. The lbmrd will report an error if an invalid interface specification is configured, including 0.0.0.0.
10288	FIXED: Sending Unicast Immediate (UIM) Requests on Sparc machines can result in high CPU burn with no messages being sent.
10602	FIXED: The `tnwgdmonmsgs.h` header file was omitted from the distribution package. This made it impossible to write daemon stats monitoring applications.
10519	FIXED: The Unix-based UMS and UMP products were built such that liblbm.so had a dependency on libqpid-proton.so.2, which was not included in the package. This did not cause improper behavior because the UMS and UMP products never attempt to call any of the missing entry points. However, having the dependency is unnecessary. The UMS and UMP dependencies to libqpid-proton.so.2 have been removed.
10490, 10491	FIXED: The log message: `Core-5688-447: LBMC datagram malformed.` does not give any information about the sender of the malformed datagram. The IP and port of the sender is now included in the log message.
10456	FIXED: The configuration options zero_transports_function (xsp) and operational_mode (xsp) cannot be specified in a "flat" UM configuration file. The error: `CoreApi-5688-61: object xsp not supported` is logged.
10398	FIXED: On many Linux systems, the `"Makefile.unix"` shipped with the example programs can produce a build error of the form: /usr/bin/ld: ....o: undefined reference to symbol 'sqrt...' The solution was to add "-lm" to the builds of the examples.
10383	FIXED: Due to an improper installation of Solarflare's `"Onload"` library, certain socket calls can return an error. UM reported this error with the unhelpful log: `Core-5688-1881: handle events returned error 0` UM has been changed to properly decode and print the proper error. In addition, if the socket reports that the `"recvmmsg()"` function is not implemented, UM disables the multiple_receive_maximum_datagrams (context) feature.
9972	FIXED: If an application attempts to unsubscribe from a Spectrum channel that it had not previously been subscribed to, the application crashes with an illegal memory access.
9798	FIXED: If a receiver of a TCP or IPC transport gets messages out of order due to the data coming through a DRO and the originating source is UDP-based, the receiving application declares immediate unrecoverable loss, even though the missing messages arrive shortly thereafter. The TCP transport receiver can now be configured to wait for a period of time before declaring unrecoverable loss. This is controlled by two new configuration options: transport_tcp_dro_loss_recovery_timeout (receiver) and transport_lbtipc_dro_loss_recovery_timeout (receiver). See DRO Reliable Loss for more information.
10435	FIXED: UM does not properly time out the total Late Join recovery process. This can lead to premature termination of Late Join recovery. UM now correctly calculates the total Late Join recovery timeout as late_join_info_request_interval (receiver) multiplied by late_join_info_request_maximum (receiver).
10640	FIXED: A timing window exists that could cause Late Join to not complete. This can occur if the max number of late join requests has been completed before the total Late Join recovery process times out.

Persistence Fixed Problems and Limitations for 6.12 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
5890, 9054	ENHANCEMENT: There are certain circumstances where a receiver has to unnecessarily wait for the ume_activity_timeout (receiver) to expire before it can register with a Store. An enhancement was made to persistent receivers that allows for immediate re-registration in the following circumstances: A persistent source application is started and takes over from a proxy source. A persistent source application using a session ID re-registers with the Store. A receiver process is restarted and it has the same session ID, request_tcp_interface (context), and request_tcp_port (context) values.
10446, 10450	FIXED: When applications and/or Stores are restarted in certain orders, the receiver can log the warning, `"Core-9743-08: WARNING: proactive keepalive is not supported at the store"`. This can happen even though the Store does support the Proactive Keepalive feature.
10379	FIXED: When a persistent source deregisters from the Store by API call (lbm_src_ume_deregister()), the Store will occasionally crash.
10617	FIXED: The Store code sometimes reads an uninitialized memory location. No improper behavior has been seen when this happens, but there is a very small chance that a receiver's outstanding messages will not be properly acknowledged, leading to potential unnecessary message recovery if the receiver restarts. This has never been observed in the field.
10564	FIXED: When a Smart Source is configured for persistence, incorrect internal handling can lead to incorrect Forced Reclaims.
10462, 10432, 10482	FIXED: After a set of multiple store restarts without clearing the state and cache files, there can be an extended period of topic deafness where persistent receivers will not see messages sent by the source.
10454	FIXED: When an RPP store is writing to disk due to a non-blocking receiver exiting, and the disk fills and needs to wrap, the store can stop accepting new messages.
10447, 10451, 10458	FIXED: If a source sends messages and then immediately deregisters, there is a chance that the Store will crash with an illegal memory access.
10343	FIXED: When a Smart Source is publishing a persisted message stream, and there is a large amount of network packet loss, the publisher can crash with the log: `FATAL: failed assertion [info->sqn == ctlr->trail_sqn]`
10341	FIXED: Minor misspelling in Store log message: `Store-8079-10: Staring store...` (Should be "Starting"; the second "t" is missing.)

Queuing Fixed Problems and Limitations for 6.12 <-

The following bug fixes apply to the UMQ product.

Change Request	Description
9974	FIXED: There was a scenario where a late arriving ACK from a ULB receiver could cause the ULB source to crash with an illegal memory access inside `lbm_ulb_src_ctlr_handle_ack()`.
10548	FIXED: Starting in UM 6.11, a non-fatal assertion is generated when shutting down a brokered queue receiver: `WARNING: failed assertion [broker->rcv_list->sz==0]`
8899	FIXED: A ULB source will get stuck in an infinite loop if umq_ulb_application_set_message_reassignment_timeout (source) is set to zero and one of the receivers exits.
3632, 8596, 8525	FIXED: If you attempt to disable ULB message reassignment by setting option umq_ulb_application_set_message_reassignment_timeout (source) to '`x:0`', and option umq_ulb_application_set_message_lifetime (source) is already set to the default value of 0, in-flight messages are not discarding. As a workaround, to inhibit message reassignment use option umq_ulb_application_set_message_max_reassignments (source) set to 1, and leave umq_ulb_application_set_message_reassignment_timeout (source) at its default value. This has now been fixed. The workaround is no longer needed.

Dynamic Router Fixed Problems and Limitations for 6.12 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request

Description

10443

FIXED: When a DRO portal is queuing outgoing messages (perhaps due to a low rate limiter or a low-bandwidth link), and a topic has more than delivery_control_maximum_burst_loss (receiver) (default 1024) messages queued to be sent, there is a possibility that receivers will deliver a burst loss event to the application and not deliver the queued messages, even though they are eventually sent. This is because the originating source sent a TSNI, and the DRO allowed it to bypass the data queue and be sent before the queued data messages. Thus the receiver sees a gap greater than the burst loss configuration and does not wait for the missing data to be sent.

The DRO now queues TSNIs behind data messages.

10499

FIXED: The DRO configuration element <route-info> has the attribute "max-hop-count" which is documented as defaulting to 100. However, the DRO did not properly initialize its internal default, which had the effect of defaulting to 255.

The DRO now properly defaults "max-hop-count" to 100.

3548

FIXED: The DRO cannot run as a standalone Windows service.

Now fixed. See UM Daemons as Windows Services.

Special Upgrade Instructions for 6.12 <-

Smart Source Header Size Change <-

A problem in Smart Source was fixed (bug 10567) which users of Smart Source need to be aware of.

When a kernel bypass network driver is used, users often change their datagram max size larger than a network MTU to ensure that UM data packets are efficiently filled. See Datagram Max Size and Network MTU for details.

However, because of bug 10567, users had to set the datagram max size to different values depending on whether their application used Smart Sources or traditional sources. This was particularly a problem for applications that make use of both Smart Sources and traditional sources; no value was optimal for both.

The fix for 10567 was to have Smart Sources reserve the same amount of space for headers as traditional sources.

Warning: For users who have set the datagram max size larger than an MTU, you may need to reduce the configured value to avoid IP fragmentation in UM version 6.12 and beyond.

As described in Setting Datagram Max Sizes High, you will need to experimentally determine the optimal value for datagram max size for your use case.

Previous Special Instructions <-

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

UM Version 6.11.1 <-

The most significant update to UM version 6.11.1 is a set of performance improvements to the Persistent Store daemon. Some performance improvements were also applied to the data receive path for applications.

Attention: See Deprecations for 6.11.1 for important information regarding future platform support for UM daemons.; There are some special upgrade instructions for UM versions 6.10 and beyond that will affect a small percentage of users upgrading from pre-6.10 versions of UM. See Special Upgrade Instructions for 6.10. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.11.1 <-

Streaming Enhancements for 6.11.1 <-

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

Performance improvements made to the data reception code paths, including reduction in calls to gettimeofday(), and some localized code optimizations.

Persistence Enhancements for 6.11.1 <-

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

The Persistent Store benefits from the performance enhancements made on the data receive path. (See also Persistence Fixed Problems and Limitations for 6.11.1.)

Queuing Enhancements for 6.11.1 <-

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

None.

Dynamic Router Enhancements for 6.11.1 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.11.1 <-

Streaming Fixed Problems and Limitations for 6.11.1 <-

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

Change Request

Description

10385, 10280

Enhancement: Reduced number of gettimeofday() calls in context loop. This lowers receive-side latency and CPU load.

Persistence Fixed Problems and Limitations for 6.11.1 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
10332, 10409	FIXED: When the Persistent Store is configured to publish Daemon Statistics, there is a small chance that it will fail to initialize properly. It might log the error: `[CRITICAL]: Store-10184-80: umestore_dmon_publish: CoreApi-5688-2996: src must be valid` and could exit with a segmentation fault.
10400, 10401	FIXED: Bug in Persistent Store leads to performance degradation over time. (This bug has existed in the Store for many years.)
10404, 10411	FIXED: When using RPP with repository-type "disk", it is possible for a blocking receiver to get unrecoverable loss. This loss can be accompanied by the following warning in the Persistent Store log file: `[WARNING]: WARNING: failed assertion [ntohl(ohdr->sqn)==rec->sqn]`
10406, 10407	FIXED: A bug fix added to 6.10.1 accidentally introduced a significant performance reduction in the UMP Persistent Store. This regression is repaired in 6.11.1.

Queuing Fixed Problems and Limitations for 6.11.1 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.11.1 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

UM Version 6.11 <-

The most significant updates to UM version 6.11 are the introduction of XSP for multi-threading receivers, and Daemon Statistics for the Store and the DRO.

Attention: There are some special upgrade instructions for UM versions 6.10 and beyond that will affect a small percentage of users upgrading from pre-6.10 versions of UM. See Special Upgrade Instructions for 6.10. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.11 <-

Streaming Enhancements for 6.11 <-

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

Transport Services Provider (XSP). XSP is a new method of assigning receiver transport sessions to independent threads. XSP gives the application control over how received transport sessions are assigned to threads. It replaces the earlier Multi-Transport Threads (MTT) feature, which is no longer supported. For more information, see Transport Services Provider (XSP).
Enhanced Smart Source feature. The Smart Sources feature now supports more functionality. Some of this support is limited, so please check the corresponding sections for further information.
- Smart Sources and Persistence is now supported,
- LBT-RU transport type is now supported,
- Smart Sources and Spectrum is now supported,
- Smart Sources and Memory Management is now supported,
- Smart Sources and Message Properties is now supported.
For this UM version, the Smart Source API is not supported in .net.
Rolling Log Files for Persistent Store and DRO. To prevent unbounded disk file growth, the Persistent Store and the DRO now support rolling log files. See Store Rolling Logs and DRO Rolling Logs for details.

Persistence Enhancements for 6.11 <-

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

Smart Sources now support Persistence. See Smart Sources and Persistence. (See also Streaming Enhancements for 6.11 for more enhancements to Smart Sources.)
Store Daemon Statistics. A new method of monitoring the Persistent Store daemon. The same information which is currently available on the daemons' web monitors can now be published on a normal UM topic. See daemonstatistics.

Queuing Enhancements for 6.11 <-

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

None.

Dynamic Router Enhancements for 6.11 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

Dynamic Router Daemon Statistics. A new method of monitoring the UM Dynamic Router daemon. The same information which is currently available on the daemons' web monitors can now be published on a normal UM topic. See daemonstatistics.
The DRO now logs an informational message each time its internal routing table changes giving the reason for the change. Messages of this form will be printed during normal startup, to give status as the DRO network establishes connectivity, and they will also be printed when a disruption causes a change in connectivity. The messages are of the form "Gwd-9574-xx".

Fixed Problems and Limitations for 6.11 <-

Streaming Fixed Problems and Limitations for 6.11 <-

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

Change Request	Description
10260	FIXED: When using Smart Source, a source processing NAKs can fatal assert: "(bvec->flags & ~LBTRM_BVEC_SMART_SOURCE_FLAG) == 0".
10178	FIXED: An unnecessary sprintf() initializing a string buffer is being called from lbm_context_process_events(). The sprintf() was moved to context creation.
10135	FIXED: When using the JAVA interface, if the source has ume_message_stability_notification (source) set to LBM_SRC_TOPIC_ATTR_UME_STABLE_EVENT_PER_MESSAGE, you could get an ArrayIndexOutOfBoundsException on the source event callback.
10087	FIXED: Applications and daemons are at risk of a bus error on architectures that require alignment (SPARC, Power). These happen very rarely, and are associated with UIM messages in a UM Routed (DRO) environment. (Note: UIMs are involved with many features, such as Late Join, Persistence, and ULB.)
10085	FIXED: Interoperation between little-endian and big-endian architectures was broken in UM version 6.10. This problem also interferes with interoperation between 6.10 and any other version of UM, on big-endian architectures. This affects systems that use any combination of DROs, Persistence, or Hot Failover. Users with big-endian architectures are advised to avoid UM version 6.10.
10079	FIXED: Java and .NET programs that use the topic resolution callback by overriding the context object's onResolverEvent() method can generate a segmentation fault, resulting in a JVM dump.
10071, 10072	FIXED: SDM: cloning an attribute object does not copy over the state of the "name_tree" attribute.
10048	FIXED: If a Java application improperly calls respond() for a message after it had been disposed, a crash results. It is requested that respond() instead throw an exception, to make it easier for application bugs to be diagnosed.
9973	FIXED: If lbm_send_request() is called on a heavily-loaded system, and a response is returned very quickly, the `"lbm_request_t reqp"` parameter can be returned with NULL.
9963, 10172	FIXED: In UM version 6.7 a change was made which had the unintended consequence of unnecessarily increasing network traffic related to "final advertisements" (see resolver_send_final_advertisements (source)).
9913	Source Send call from within context callbacks is inconsistently documented. The C, Java, and .NET API documents have been updated to be consistent and correct related to context thread callbacks. See lbm_src_send(), lbm_src_send_ex(), lbm_src_sendv(), lbm_src_sendv_ex(), lbm_send_request(), lbm_send_request_ex(), lbm_hf_src_send(), lbm_hf_src_send_ex(), lbm_hf_src_send_rcv_reset(), lbm_hf_src_sendv(), lbm_hf_src_sendv_ex(), lbm_send_response().
9829	FIXED: If a Java application improperly attempts to close a context object before all child objects (sources, receivers) are closed, a crash can result. Now, if an application attempts to close a context that still contains active sources or receivers, a warning is logged and the context is not closed. However, no exception is thrown from the context close; it returns normally. The user must use the error log to identify the application bug.
9816	FIXED: The documentation did not inform the user that it is necessary to have a consistent value for transport_lbtrm_datagram_max_size (context). A note has been added to transport_lbtsmx_datagram_max_size (source), transport_lbtrm_datagram_max_size (context), transport_lbtru_datagram_max_size (context), transport_tcp_datagram_max_size (context), transport_lbtipc_datagram_max_size (context), transport_lbtrdma_datagram_max_size (context).
9606	FIXED: Java properties don't support redundant keys. This creates a problem for the resolver_unicast_daemon (context) configuration option which needs to be specified multiple times for redundant `lbmrd` operation. This does not work with Java Properties. The solution was to modify resolver_unicast_daemon (context) to allow multiple servers to be specified in a single specification, separated by commas or semicolons. For example: `cattr.setProperty("resolver_unicast_daemon", "10.3.29.181:5555,10.3.29.185:5555,10.3.29.190:5555");`
5555	FIXED: Message Properties are incompatible with the Spectrum feature. Both cannot be used for the same message. Now a message can be sent both with message properties and to a Spectrum channel.
7763	This bug cannot be reproduced in any recent version of UM. The bug is assumed to be FIXED: You cannot send messages larger than 65,535 bytes over the LBT-IPC transport when you set option ordered_delivery (receiver) to 0 (zero) unless you also set transport_lbtipc_behavior (source) to '`receiver_paced`'.

Persistence Fixed Problems and Limitations for 6.11 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
10231	FIXED: The Persistent Store Web Monitor displays truncated values for "Retransmission Request Received Rate" and "Retransmission Request Service Rate". The decimal portion is now correctly displayed.
6088, 8660, 8955, 4899	FIXED: Persistent Store log files grow without bounds. Rolling log files are now implemented in the Store and in the DRO. See Store Rolling Logs and DRO Rolling Logs for details.
10201	FIXED: In a scenario where messages are getting lost and proactive retransmissions are being used between the source and the store, it is possible to get into a state where the source would be infinitely stuck on flight size.
10196	FIXED: When a store is not keeping up with incoming messages to the point where it has to intentionally drop incoming messages, there is a possible scenario where the source can get stuck, blocked on flight size.
10183, 6324	FIXED: When the store is overwhelmed with incoming messages and has to intentionally drop some messages, it is possible for the state associated with the store to get corrupted and, depending on the next sequence of events, one or more of the following messages can be logged: `FATAL: failed assertion [buff->len<=LBMUIM_APDU]` `WARNING: failed assertion [ntohl(ohdr->sqn)==rec->sqn]` `WARNING: failed assertion [ntohs(ohdr->msglen)<=rxbuff->maxlen]` `WARNING: failed assertion [ntohs(ohdr->msglen)==rec->disk_len]` followed by either an abort or a segmentation fault. Checks have been added so that the store's state won't be corrupted.
10176	The description of message Store-5688-5574 has been corrected.
10063, 10064	FIXED: Version 6.10 of the Persistent Store had a condition that could cause rare segmentation faults. When it happens, it is usually associated with the store falling behind the source.
10036	FIXED: When using an RPP non-blocking receiver, the source blocks once the store's disk repository fills up. Now, when the store's repository fills up, messages will be deleted if only non-blocking acks are outstanding.

Queuing Fixed Problems and Limitations for 6.11 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.11 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request	Description
10194	FIXED: When Peer Links attempt to establish connections, there is a window during which a socket could get closed just before attempting to complete the connection. This can result in a fatal assert "handle==conn_mgr->sock->sock", or could simply result in the peer link not making any more connection attempts, leaving the link permanently disconnected.
10188	FIXED: An issue with routing Multicast Immediate Messages (MIM) through a DRO running SPARC 32-bit systems which caused a bus error.
10163	FIXED: There are several instances of random message corruption which can cause the DRO to crash. Defensive checks have been added to protect the DRO against malformed messages.
10051	FIXED: Large UIM messages can become corrupted while transiting a DRO network. It happens when message fragments are either dropped (due to link overload) or become out of order.
10050	FIXED: In UM 6.10, the DRO crashes when it is paired with the UMS or UMP version of the UM library.

UM Version 6.10.1 <-

The most significant update to UM version 6.10.1 is a set of bug fixes.

Attention: There are some special upgrade instructions for UM versions 6.10 and beyond that will affect a small percentage of users upgrading from pre-6.10 versions of UM. See Special Upgrade Instructions for 6.10. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.10.1 <-

Streaming Enhancements for 6.10.1 <-

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

None.

Persistence Enhancements for 6.10.1 <-

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

None.

Queuing Enhancements for 6.10.1 <-

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

None.

Dynamic Router Enhancements for 6.10.1 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.10.1 <-

Streaming Fixed Problems and Limitations for 6.10.1 <-

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

Change Request	Description
10051, 10130	FIXED: Large UIM messages, such as UM responses, can become corrupted when transferred between Topic Resolution Domains by a DRO.
10085, 10086	FIXED: For UM version 6.10 (only) running on "big-endian" machines (e.g. SPARC), 64-bit values in UM packet headers were not properly swapped, with the result that for certain features, big-endian machines cannot interoperate with little-endian machines. The problem is most visible with the ULB feature, and the DRO.
10050, 10054	FIXED: For UMM version 6.10 (only), the DRO is not able to run o the UMS or UMP products' "lbm" libraries.
10106	FIXED: Documentation related to several configuration options, including transport_tcp_sender_socket_buffer (source), response_session_sender_socket_buffer (context), and Topic Option "repository-size-threshold".

Persistence Fixed Problems and Limitations for 6.10.1 <-

The following bug fixes apply to UMP and UMQ products.

Change Request

Description

10050, 10054

FIXED: For UMM version 6.10 (only), the DRO is not able to run on the UMS or UMP products' "lbm" libraries.

Queuing Fixed Problems and Limitations for 6.10.1 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.10.1 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request

Description

10050, 10054

FIXED: For UMM version 6.10 (only), the DRO is not able to run on the UMS or UMP products' "lbm" libraries.

UM Version 6.10 <-

The most significant updates to UM version 6.10 are related to improving performance (latency, jitter, and throughput).

Attention: There are some special upgrade instructions for UM versions 6.10 and beyond that will affect a small percentage of users upgrading from pre-6.10 versions of UM. See Special Upgrade Instructions for 6.10. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.10 <-

Streaming Enhancements for 6.10 <-

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

IPC performance improvement. Changed the receiver-side dequeuing algorithm to avoid semaphore operations when possible. Also see configuration option transport_lbtipc_pend_behavior_linger_loop_count (context).
NCF reduction. Changed the LBT-RM reliability algorithm to reduce the number of NCF control messages sent during periods of heavy loss. The change reduces the impact of loss on healthy receivers, but might slightly increase the load on the source. See NAK Suppression for details.
Host names in configuration files. For configuration options that take an IP address, it is now permissible to supply a host name. UM will resolve the name to an IP address when the configuration file is read.
Non-contending Statistics retrieval. Statistics gathering API functions 'lbm_*_retrieve*stats()' no longer contend with the message receive path (context thread). Retrieving statistics no longer introduces latency outliers in normal message flow. Note that a given sample of statistics no longer necessarily represents a single snapshot in time. For example, it is possible that between two samples, the field 'bytes_rcved' could change but 'lbm_msgs_rcved' does not. NOTE: brokered queuing contexts are not included in this enhancement.
Smart Sources. A new, somewhat restrictive API for sending messages which eliminates looping, locking, and dynamic memory allocation/freeing, resulting in a significant reduction in send time and elimination of variance in execution time (jitter). Available for C and Java. See Smart Sources.
Send path performance improvement. For UDP-based protocols (LBT-RM and LBT-RU), an algorithmic optimization was made to eliminate two memory allocations and frees per send call. This is for established sources (i.e. this optimization is not related to Smart Sources). Reduction of memory allocations and deallocations reduces send time, but more importantly reduces latency outliers (jitter).
Send message direct to a source. Unicast Immediate Messages (UIM) have always allowed the use of IP address and UIM port (also known as "request port") of the destination application. As of version 6.10, a "source string" can also be used as the destination. This allows a receiving application to send a message directly to a newly subscribed source application. See the Concepts Guide section Sending to Sources.
Default interface configuration option. This new configuration option simplifies the previously error-prone process of configuring interfaces for different features. If all or most features should use the same interface, it is no longer necessary to configure each interface option. Instead, specify the default_interface (context) once and then optionally specify any exceptions. (See below for affected configuration options.)
Increased send-side socket buffer for TR. The send-side socket buffers for Topic Resolution has been increased to 1MB. This will reduce the possibility of send-side loss due to EWOULDBLOCK on socket sends.
HTML documentation. Version 6.10 contains the first phase of a conversion of UM documentation to a different tool chain which produces manuals in 3 forms: multi-page HTML, single-page HTML, and PDF. Manuals converted in 6.10: "Concepts Guide", "Configuration Guide", "Operations Guide", and "Guide to Queuing". Additional manuals will be converted in a future release. In addition, Doxygen is now being used to produce .NET and Java API documentation.
Context delay warning. A UM context keeps track of how long each loop of its context thread takes. As of UM 6.10, it now logs a warning (Core-5688-1882 for embedded mode, Core-5688-1891 for sequential mode) if a loop exceeds 1500 milliseconds (1.5 s). This behavior can be modified by setting the environment variable LBM_CONTEXT_DELAY_WARNING to the number of milliseconds desired, or to zero to disable the warning. Note that if you see this warning, it represents a significant source of latency and should be investigated to determine the root cause.

Jar file names changed. The following shipped Java jar file's names have changed to remove the JDK version number. In the table below, '<vers>' is the UM version number.

Old jar name	New jar name
UMS_<vers>_jdk1.5.0_12.jar	UMS_<vers>.jar
UMSPDM_<vers>_jdk1.5.0_12.jar	UMSPDM_<vers>.jar
UMSSDM_<vers>_jdk1.5.0_12.jar	UMSSDM_<vers>.jar
UMMAPI_1.5.0_12.jar	UMMAPI.jar
UMMD_1.6.0_02.jar	UMMD.jar
UMMGUI_1.6.0_02.jar	UMMGUI.jar

The UMSSDM jar file is no longer included in the UMS jar file. Starting with UM 6.10, Java programs that use SDM need to explicitly include UMSSDM_<vers>.jar in the classpath.
Windows .NET API is now included with base Windows package. It is no longer necessary to download and install .NET separately. The dynamic libraries and example executables are now contained under 'bin\dotnet'.
Windows package built with Visual Studio 2012. The UM packages for Windows are now being built with Visual Studio 2012 (VS 2012). The package is no longer shipped with the Windows Runtime library msvcr80.dll. Now UM ships with msvcr110.dll. User applications should be built with VS 2012 or beyond.
Improved defaults. Many streaming and persistence configuration options have new default values. For systems already in production, please review the options and determine if the improved defaults are appropriate for your application. If not, then you must ensure that the desired values are explicitly configured. For details, see UM 6.10 Improved Defaults.

Persistence Enhancements for 6.10 <-

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

Improved UM configuration defaults. Many persistence-related configuration options have new default values. For systems already in production, please review the options and determine if the improved defaults are appropriate for your application. If not, then you must ensure that the desired values are explicitly configured. See Special Upgrade Instructions for 6.10.

Queuing Enhancements for 6.10 <-

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

None.

Dynamic Router Enhancements for 6.10 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

Smart-Batch. New method of batching within the DRO which significantly increases throughput without increasing latency (as compared to flushing every message). See <smart-batch>.

Fixed Problems and Limitations for 6.10 <-

Streaming Fixed Problems and Limitations for 6.10 <-

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

Change Request	Description
10024	FIXED: The API function lbm_transport_source_parse() incorrectly parsed source strings under a wide variety of circumstances.
9824	FIXED: When a .NET program made use of ResolverEventCallback, it could result in a crash with the message, '`A callback was made on a garbage collected delegate...`'.
9710, 9788	FIXED: The API functions lbm_rcv_topic_attr_dump(), lbm_src_topic_attr_dump(), and lbm_context_topic_attr_dump() generated log messages of the form: '`Core-5688-27 WARNING: ... config variable ... is deprecated. Use ... instead.`' One side-effect of this problem is that the Dynamic Router (DRO) logs these messages. This has been corrected since UM version 6.9.1.
9950	FIXED: Corrected certain log messages generated due to Windows socket errors. Previously, the reason for the error was not printed correctly (always said error code was zero). Now it correctly prints the error code returned by Windows.
9877	FIXED: If an LBT-RU source's context thread experiences a significant multi-second delay, due perhaps to scheduling delay on a severely overloaded server, and a receiver is configured to receive multiple datagrams via the multiple_receive_maximum_datagrams (context) option, there is a possibility that the receiver will crash with a fatal assert: '`[map != NULL]`'.
9939	FIXED: Corrected memory alignment crash when using LZ4 compression on 32-bit SPARC machines.
9981, 9977, 9955	FIXED: UM version 6.9. have a problem which prevents the optional UM products UMDS, UMCache, and SNMP from working (mul_inet_ntoa).*
9722, 9826	FIXED: When the UMDS server component was executed on UMS or UMP library versions prior to 6.9, the server would log: '`CoreApi-5688-22 UMQ not supported`' Note that the server would function properly, so the log message could be ignored. In UM 6.10 the log is suppressed.
9957	FIXED: When using Myricom's Datagram Bypass Library (DBL), a fatal assert ('`handle==dmux- >rcvmsock->sock`') and segmentation fault can occur if a receiver is deleted while the receiver is processing incoming datagrams.
9779	Enhancement: Added configuration option transport_lbtru_nak_initial_backoff_interval (receiver). Setting this greater than zero reduces NAK traffic when UDP datagrams are delivered out of order. However, it also introduces repair latency when a datagram is lost.
4839, 9249, 9950	Enhancement: Updated a number of error log messages to include the proper Windows return code.
9878	Enhancement: In the Java API, if a receiver object is closed more than once, we silently ignore any closes after the first. (Previously an error condition was encountered.)
9677	Enhancement: UM Windows package now built with Visual Studio 2012. The Windows runtime library msvcr110.dll is now included with UM.
9951	Enhancement: print a log message when UM attempts to send a topic resolution message and the send to the socket fails. Most failures are serious and require attention to determine root cause.
9983	Enhancement: include .NET libraries with the base Windows package for all products (UMS, UMP, UMQ). Downloading a separate .NET package is no longer necessary. The DLLs and example program binaries are now under '`bin\dotnet`'.
9926	Enhancement: Topic Resolution send-side socket buffers are now set to 1MB. This should prevent "EWOULDBLOCK" errors and the associated loss of TR packets.
9967, 8556, 7793, 2548	Enhancement: reduce the number of NCF control messages sent during periods of heavy loss. The change reduces the impact on healthy receivers, but might slightly increase the load on the source.

Persistence Fixed Problems and Limitations for 6.10 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
9953	FIXED: Due to an incorrect print specification, 32-bit applications can occasionally crash with illegal memory access when debug logging is enabled and a persistent session ID is being printed. The print specification has been corrected.
9583	FIXED: When a source requests registration with a store, if is possible for the store's response control message (PREG_RESP) to be lost. The source will re-try the registration, which the store will reject with the log, "RegID xxx is in use by a different source". This has been corrected (a store allows a registered source to re-register).
9920, 9929	FIXED: Under unknown circumstances, a store can exit with inconsistent data in the state and/or cache files. When the store is restarted, this inconsistent data can result in a store crash during initialization. Defensive checks have been added.
9861	FIXED: The UMM tool tip for the source configuration option ume_proactive_keepalive_interval (context) was incorrect. Also, if zero was supplied, CPU utilization jumped to 100%. It is fixed such that zero disables proactive keepalives.
9902, 9925	FIXED: The Store's log file sometimes shows session IDs as negative numbers. These have been corrected to use unsigned.
9458, 9796	FIXED: A minor race condition in the Store which results in one or more warning logs: '`WARNING: failed assertion [repo->disk_holder->disk->offset >= deletesz] at line ...`'
9938, 9943	Enhancement: If a 5.x persistent source is configured for named stores and is also configured not to query for the store name (via the environment variable '`UME_SKIP_NAMED_STORE_QUERY`'), and a 6.x store becomes non-responsive due to excessive load, and then returns to normal operation, the source will not be able to resolve the store again. This is because a 6.x store cannot be configured to periodically advertise its name indefinitely. In UM version 6.10, the store can be configured to periodically advertise indefinitely via the UM configuration option compatibility_include_pre_um_6_0_behavior (context). Note that this option is only recommended for use during a limited transition period while customers upgrade from 5.x to 6.x and persistent stores must be configured not to query. When all components are at version 6.x, the use of this configuration option should be discontinued.
9993	Enhancement: Proactive Keepalive feature modified to reduce disk activity due to page faults during periods of low message traffic.
9689	Enhancement: Added Store configuration element <xml-config> to allow the use of XML-based UM configuration files. With this addition, Informatica discourages the use of the environment variable '`LBM_XML_CONFIG_FILENAME`'.

Queuing Fixed Problems and Limitations for 6.10 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.10 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request	Description
9710, 9788	The DRO generated log messages of the form, `Core-5688-27 WARNING: ... config variable ... is deprecated. Use ... instead.` This was due to a problem in the underlying UM library.
9810	A variety of timing-related issues with single-TCP peer links have been resolved.
9800	If a DRO has a proxy source with queued messages and the proxy source is deleted, the messages get stuck in the queue, which subsequently has less room for future messages. In the worst case, the queue can be stuck in a full state, preventing message forwarding. Proxy sources are deleted as a result of the originating source being deleted, or as a result of all receivers in a remote TRD being deleted, eliminating interest in the topic in that TRD.
9799	If a DRO has a proxy source with queued messages, there is a small timing window during message flow that can cause messages to get stuck in the queue, which subsequently has less room for future messages. In the worst case, the queue can be stuck in a full state, preventing message forwarding. (Similar to 9800, but does not require deletion of proxy source.)
9916	If a debug log is being generated, a garbage value is printed in some of the logged messages, making it more difficult for Informatica Support to diagnose problems.

Special Upgrade Instructions for 6.10 <-

DRO (Dual) TCP Peer Link <-

UM version 6.10 no longer supports "Dual TCP" peer links ("<tcp>"). Upgrading customers should use <single-tcp> instead.

UM 6.10 Improved Defaults <-

The following configuration options have had their default values changed. The intention is for these values to be generally better for users, so you may benefit from them. However, some users may have tuned their applications and/or environments to conform to the old defaults. You should examine these options and compare them to values that you may have set, paying special attention to options that you do not set, since those may result in behavior changes in your system. Contact Informatica Support for assistance.

Streaming Defaults

Note that these affect streaming, persistence, and queuing use cases.

Option	Old default	New default
multiple_receive_maximum_datagrams (context)	1	0
resolver_multicast_interface (context)	INADDR_ANY	Value of default_interface (context)
resolver_unicast_interface (context)	INADDR_ANY	Value of default_interface (context)
request_tcp_interface (context)	INADDR_ANY	Value of default_interface (context)
response_tcp_interface (context)	INADDR_ANY	Value of default_interface (context)
transport_tcp_interface (source)	INADDR_ANY	Value of default_interface (context)
transport_tcp_interface (receiver)	INADDR_ANY	Value of default_interface (context)
transport_lbtru_interface (source)	INADDR_ANY	Value of default_interface (context)
transport_lbtru_interface (receiver)	INADDR_ANY	Value of default_interface (context)
resolver_multicast_receiver_socket_buffer (context)	0 (OS default)	8388608 (8MB) Increase in socket buffers reduces loss and latency outliers for UDP-based transports with ordered delivery.
resolver_unicast_receiver_socket_buffer (context)	0 (OS default)	8388608 (8MB)
transport_lbtrm_receiver_socket_buffer (context)	524288 (512KB)	8388608 (8MB)
transport_lbtrm_source_socket_buffer (context)	0 (OS default)	1048576 (1MB)
transport_lbtru_receiver_socket_buffer (context)	524288 (512KB)	8388608 (8MB)
transport_lbtru_source_socket_buffer (context)	0 (OS default)	1048576 (1MB)
transport_tcp_sender_socket_buffer (source)	Windows 128000 (125KB)	0 (OS default) The value zero suppresses the setting of the socket buffer, which allows the OS to make use of auto-tuning.
response_session_sender_socket_buffer (context)	Windows 128000 (125KB)	0 (OS default) The value zero suppresses the setting of the socket buffer, which allows the OS to make use of auto-tuning.
transport_lbtrm_rate_interval (context)	100 ms (.1 sec)	10 ms (.01 sec) Reduction of rate interval can improve network stability and prevent loss, but can also increase latency outliers.
otr_request_initial_delay (receiver)	10 sec	2 sec
otr_request_message_timeout (receiver)	20 sec	60 sec

Persistent Defaults

Note that these affect persistence and queuing use cases.

Option

Old default

New default

ume_use_ack_batching (receiver)

0 (no)

1 (yes) Batching of receiver consumption acknowledgements greatly increases system throughput, although it also increases the likelihood of duplicate messages during a recovery operation.

ume_confirmed_delivery_notification (source)

1 (yes)

0 (no) Increases system throughput.

ume_message_stability_timeout (source)

20,000 (20 sec)

5,000 (5 sec) Should be less than NAK generation interval (for UDP-based protocols).

Improved Store configuration defaults

Option

Old default

New default

repository-size-threshold

25,165,824 (24MB)

1,024 (1K)

Previous Special Instructions <-

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

UM Version 6.9.2 <-

The most significant update to UM version 6.9.2 is the repair of a serious bug in LBT-RM and LBT-RU transports.

Attention: There are some special upgrade instructions for UM versions 6.8 and beyond that will affect a small percentage of users upgrading from pre-6.8 versions of UM. See Special Upgrade Instructions for 6.8. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.9.2 <-

Streaming Enhancements for 6.9.2 <-

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

None.

Persistence Enhancements for 6.9.2 <-

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

None.

Queuing Enhancements for 6.9.2 <-

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

None.

Dynamic Router Enhancements for 6.9.2 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.9.2 <-

Streaming Fixed Problems and Limitations for 6.9.2 <-

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

Change Request

Description

9927

Fixed a problem with UDP transports LBT-RM and LBT-RU where sending a very large number of datagrams (more than 4 billion) results in a failed assertion [oblk!=NULL].

9824

Fixed problem in .NET API where using a resolver event callback and/or a source cost callback can cause crashes after garbage collection.

Persistence Fixed Problems and Limitations for 6.9.2 <-

The following bug fixes apply to UMP and UMQ products.

Change Request

Description

9902

Fixed problem where session IDs were printed to the Store log file in an inconsistent way, sometimes signed, sometimes unsigned.

Session IDs are now always printed unsigned.

9920

Fixed problem in Store where use of Receiver-Paced Persistence can lead to a Store segmentation fault during startup.

Queuing Fixed Problems and Limitations for 6.9.2 <-

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.9.2 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

UM Version 6.9.1 <-

The most significant update to UM version 6.9.1 is expansion of the supported platforms:
Linux-X86 (32 and 64 bit), Windows (32 and 64 bit), Solaris-X86 (32 and 64 bit), Solaris-Sparc (32 and 64 bits), Linux-Itanium (64-bit), Linux-Power8 (64-bit, little endian), HP NonStop-X64 (64-bit).

Warning: Due to a serious bug in UM 6.9 and 6.9.1, users of LBT-RM and LBT-RU transports are strongly advised to upgrade to 6.9.2 as soon as possible. The bug causes a crash (fatal assert) after approximately 4 billion datagrams are sent on a transport session.

Attention: There are some special upgrade instructions for UM versions 6.8 and beyond that will affect a small percentage of users upgrading from pre-6.8 versions of UM. See Special Upgrade Instructions for 6.8. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.9.1 <-

Streaming Enhancements for 6.9.1 <-

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

Addition of Linux-Power8 (64-bit, little endian), HP NonStop-X64 (64-bit) platforms.
High-resolution Timestamps are now supported for Java applications.

Persistence Enhancements for 6.9.1 <-

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

None.

Queuing Enhancements for 6.9.1 <-

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

None.

Dynamic Router Enhancements for 6.9.1 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.9.1 <-

Streaming Fixed Problems and Limitations for 6.9.1 <-

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

Change Request	Description
9729	Fixed a problem where a UDP packet with bad checksum was silently ignored. UDP packets with checksum errors will now generate a warning log message.
9654	Fixed a potential crash with Windows Completions Ports due to memory corruption during a TCP disconnect. This bug was fixed in UM version 6.9, but was not included in the 6.9 release notes due to an oversight.
6102	Fixed a problem where TSNIs were not sent when Source Side Filtering was enabled. TSNIs are now sent.
9722	Enhanced the UMS library to not report certain warnings related to persistence and queuing. These warnings were most apparent with using the UMDS product, which ensures that persistence and queuing behaviors are disabled, but when used with the UMS library, generated warnings. These warnings are not needed and have been removed.

Persistence Fixed Problems and Limitations for 6.9.1 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
9707	Fixed a problem with Receiver Paced Persistence where setting the source configuration option ume_write_delay (source) to zero did not override the store's repository-disk-write-delay value. The source can now override the store with ume_write_delay (source) set to zero.
9805	Fixed a problem where certain store log messages associated with registration sometimes caused a segmentation fault on 32-bit Linux.
9481	Fixed a problem where the UMM user interface did not initialize options to the correct default values for the options ume_retransmit_request_outstanding_maximum (receiver), ume_registration_interval (source), ume_sri_inter_sri_interval (source), and ume_sri_max_number_of_sri_per_update (source). Those options are now initialized to the correct default values.
9462	Enhanced a warning log message related to a store receiving a keepalive message that is not of type "STORE". The message now reports the IP and Port of the sender.
9704	Enhanced a store log message related to source registration errors. The message now reports the IP and Port of the source.
9743	Enhanced the keepalive protocol between the store and a persistent receiver to significantly reduce the keepalive traffic, especially for the case where a persistent receiver exits. This involved the introduction of a new configuration option, ume_proactive_keepalive_interval (context).

Queuing Fixed Problems and Limitations for 6.9.1 <-

The following bug fixes apply to the UMQ product.

Dynamic Router Fixed Problems and Limitations for 6.9.1 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request

Description

9817

Fixed a topic deafness problem where a temporary surge of messages flowing out of an endpoint portal will put one or more topic queues into a blocked state which does not unblock when the surge is over.

Temporarily blocked topic queues are now correctly unblocked.

9755

Fixed a problem where a DRO endpoint could get stuck in an infinite loop sending topic resolution traffic. The problem is associated with the creation and deletion of topics and wildcard receivers which match them.

This has been fixed.

UM Version 6.9 <-

The most significant update to UM version 6.9 is the introduction of certificate-based security (authentication and encryption).

Warning: Due to a serious bug in UM 6.9 and 6.9.1, users of LBT-RM and LBT-RU transports are strongly advised to upgrade to 6.9.2 as soon as possible. The bug causes a crash (fatal assert) after approximately 4 billion datagrams are sent on a transport session.

Attention: There are some special upgrade instructions for UM versions 6.8 and beyond that will affect a small percentage of users upgrading from pre-6.8 versions of UM. See Special Upgrade Instructions for 6.8. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.9 <-

Streaming Enhancements for 6.9 <-

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

TCP-based communication can now enable compression and/or encryption. Other protocols (udp, multicast, etc.) are not supported for compression or encryption at this time. See Encrypted TCP.
The LBT-RM transport type now supports a "zero-copy" API for sending messages. See Zero-Copy Send API.
The LBT-RM transport type now supports high-resolution timestamps for packet transmission and reception for customers using Solarflare network interfaces and the Onload driver. See High-resolution Timestamps.
Performance has been improved for sending messages on all transport types by reducing use of dynamic memory. This reduces the send time and also reduces the variance of send times ("jitter").
Added two new APIs to Java: com::latencybusters::lbm::LBMMessage::getSerializedResponse and com::latencybusters::lbm::LBMContext::respond, as well as a new class: com::latencybusters::lbm::LBMSerializedResponse. These provide a way to receive a UM request, serialize the response object, and then send the response, possibly via a different context.

Persistence Enhancements for 6.9 <-

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

An API has been added to start and stop a store from inside an application process. See Callable Store.
The store has been enhanced to log thread IDs for each of its internal threads. The log messages are of the form 'Store-8079-x'.
The Receiver-paced Persistence feature now supports blocking and non-blocking receivers. See RPP: Receiver-Paced Persistence.

Queuing Enhancements for 6.9 <-

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

None.

Dynamic Router Enhancements for 6.9 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

Peer links may now be compressed and/or encrypted.

Fixed Problems and Limitations for 6.9 <-

Streaming Fixed Problems and Limitations for 6.9 <-

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

Change Request	Description
9759	The UM Log Messages chapter of the "Operations Guide" did not correctly order messages numerically. For example, "Core-1234-10" would come before "Core-1234-9". The order has been corrected.
9484, 9566	UM generally reacts to an exhaustion of dynamic memory (heap) with a warning, and attempts to continue execution in a crippled manner. UM has now been changed to react to exhaustion of dynamic memory by triggering a fatal assertion.
9582	When the C API lbm_register_fd() is used to register a socket, and an event queue is used to deliver socket events, there is a race condition that can cause delivery of a spurious read event. An application that responds by doing a blocking read can experience an unbounded block. A non-blocking read can return no data. UM now effectively prevents this spurious read event.
9625	When the resolver_unicast_daemon (context) option is read multiple times with the same '`IP:PORT`' combination, the context adds multiple references to that lbmrd, leading to wasted resources, potentially exhausting ports in the unicast resolver UDP port range. UM now detects duplicate IP:PORT and maintains a single reference to that lbmrd.
9672	The multiple_receive_maximum_datagrams (context) configuration option enables the use of recvmmsg() to improve the efficiency of reading UDP data. However, multiple datagrams were not actually read. No improper behavior results, but the potential efficiency improvement is not delivered. UM now properly enables reception of multiple datagrams.
9591	Under some circumstances, when using the epoll form of FD management, the operating system can return an error to UM that UM does not know how to handle. UM has been triggering a fatal assertion in these cases. Further testing has suggested that some of these unexpected statuses can be benign. So UM has now been changed to use warning asserts when epoll returns an unexpected bad status.
9654	Fixed a potential crash with Windows Completions Ports due to memory corruption during a TCP disconnect.

Persistence Fixed Problems and Limitations for 6.9 <-

The following bug fixes apply to UMP and UMQ products.

Change Request

Description

9115

The store now prints BOS and EOS events to its log.

9276

If an RPP store configured for reduced FD storage fails and restarts immediately after a receiver registers, that receiver will sometimes lose messages.

Fixed by ensuring that the restarted reduced FD store starts at the correct sequence number.

9626

When the ume_store (source) and/or ume_store_name (source) configuration option is read multiple times referring to the same store, the context adds multiple references to that store, leading to wasted resources.

UM now detects duplicate stores and maintains a single reference to that store.

Queuing Fixed Problems and Limitations for 6.9 <-

The following bug fixes apply to the UMQ product.

Change Request

Description

9494

UMM did not include the option umq_queue_activity_timeout (context).

It has been added.

9555

When the C API lbm_rcv_topic_attr_setopt() is used to set a value for umq_ulb_source_activity_timeout (receiver), the value was not set correctly. Note that using text-based configuration files worked correctly for that option.

The C API function is now corrected.

9640

When the broker configuration option is read multiple times referring to the same broker, the context adds multiple references to that broker, leading to wasted resources.

UM now detects duplicate brokers and maintains a single reference to that broker.

Dynamic Router Fixed Problems and Limitations for 6.9 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request

Description

8880

DRO daemons using dual-tcp peer links with non-"select" FD management types might issue many 'Core-5688-3808...' log messages.

The Router now hard-codes peer links to use select for Unix and wsaeventselect for Windows. This avoids the errors.

9694, 9688 A race condition can cause a portal to become deadlocked and not pass traffic. The portal locking has been corrected.

UM Version 6.8 <-

The most significant update to UM version 6.8 is the replacement of the UM brokered queuing and JMS functionality (umestored) with an enhanced Apache ActiveMQ-based JMS/AMQP broker. The existing UMQ queuing API has been adapted to make use of ActiveMQ via the open standard AMQP protocol.

Note that when upgrading a brokered queuing application from a pre-6.8 version, the application source code may need to be changed and re-built.

Attention: there are some special upgrade instructions for UM versions 6.8 and beyond that will affect a small percentage of users upgrading from pre-6.8 versions of UM. See Special Upgrade Instructions for 6.8. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.8 <-

Streaming Enhancements for 6.8 <-

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

The Multiple Datagram Reception feature can greatly increase receiver performance during message bursts by reading multiple UDP datagrams with one recvmmsg() system call.

For applications prone to bursts of many messages arriving at a receiver in a very short time, performance can degrade while the receiver reads each message individually. To accelerate message reception during these bursts, enable Multiple Datagram Reception.

This feature applies to all UDP-based sockets, such as topic resolution, MIM, and for transports LBT-RM and LBT-RU. You can use this feature with Linux kernel 2.6.33 or later, and glibc 2.12 or later.

To enable Multiple Datagram Reception, set the configuration option multiple_receive_maximum_datagrams (context) to the maximum number of datagrams per socket to receive in one pass.

Note
Due to an implementation defect, this feature does not function correctly in UM version 6.8. Users of version 6.8 are advised to upgrade to UM version 6.9.2 or beyond to take advantage of the performance advantages of this feature.
Improved defaults. Many streaming and persistence configuration options have new default values. For systems already in production, please review the options and determine if the improved defaults are appropriate for your application. If not, then you must ensure that the desired values are explicitly configured. For details, see UM 6.8 Improved Defaults.

Persistence Enhancements for 6.8 <-

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

UM 6.8 introduces the following new API call:
- C: lbm_ume_ack_mark_not_outstanding()
- Java and .NET: com::latencybusters::lbm::UMEMessageAck::markNotOutstanding()
This call updates the internal acking state up to the sequence number provided for throttled recovery, without acking anything.
The Persistent Store no longer requires a UM License file to operate. Persistent client application still require a license key with peristence enabled.
You can now configure a Persistent Store to port=0, which selects the actual port number from within the range of the request_tcp_port_low (context) and request_tcp_port_high (context) configuration options.

The following configuration options default values are changed:

Option	Old Default	New Default	Notes
use_otr (receiver)	0	2 (enables only persistent receivers)
ume_registration_interval (source)	500 ms	3000 ms	Reduce overly-aggressive registration activity, which causes excess CPU use. Sources still register very quickly if all stores are available, and only wait for the '`ume_registration_interval`' to expire if less than the full list of stores responds to the registration request of the source.
ume_registration_interval (receiver)	500 ms	3000 ms	Reduce overly-aggressive registration activity, which causes excess CPU use. Receivers still register very quickly if all stores are available, and only wait for the '`ume_registration_interval`' to expire if less than the full list of stores responds to the registration request of the receiver.
ume_consensus_sequence_number_behavior (source)	`majority`	`highest`	For applications that do not reconcile and republish in-flight messages upon store re- registration in the same order they were originally sent, this revised default reduces the chances that a source republishes a previously sent sequence number with a different payload.
ume_sri_inter_sri_interval (source)	100 ms	500 ms	This option, combined with option ume_sri_max_number_of_sri_per_update (source), determines how long a persistent source advertises stores to receivers after receiving an SRI request. These increased values reduce the likelihood of poor network performance and infrastructure components causing improper UMP registration behavior.
ume_sri_max_number_of_sri_per_update (source)	10	20
ume_store_activity_timeout (source)	3000 ms	10,000 ms	This increased value allows for reduced heartbeat traffic, and decreases false declarations of inactive stores. You must set this option and the Persistent Store '`keepalive-interval`' option together. For information about how these values affect a phased upgrade from earlier versions, see this document's Installation section.
ume_store_behavior (source)	`rr`	`qc`	Round-Robin behavior is discontinued.

The following Persistent Store configuration options default values are changed:

Option	Old Default	New Default	Notes
receiver-new-registration-rollback	0	2147483647	The previous default value of 0 resulted in new receivers not requesting any initial state. The new value causes receivers to request all of the data cached in the Persistent Stores that they might be interested in before they become active. You may still need to change these values either with configuration or programmatically.
keepalive-interval	500 ms	3000 ms	This increased value reduces heartbeat traffic, and decreases false declarations of inactive stores. You must set this option and the ume_store_activity_timeout (source) option together. For information about how these values affect a phased upgrade from earlier versions, see Upgrading From Version Pre-6.0.
proxy-election-interval	5,000 ms	60,000 ms	This increased value gives a UMP store more time to create the potentially large number of proxy sources that may result from a large-scale failure event. This reduces the chances of an overload situation in UMP store processes.
source-check-interval	100 ms	750	This increased value reduces CPU use in the UMP store. The previous default was too aggressive and did not significantly improve performance.

Queuing Enhancements for 6.8 <-

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

Robust commodity-based JMS/AMQP broker features:
- Fully-managed (pure Java) JMS 1.1 client API
- AMQP 1.0 wire protocol support for UMQ client API
- Automatic failover for client to broker connections
- Inter-operation between UMQ and JMS client APIs
UMQ 6.8 introduces a new architecture for Ultra Messaging Queuing. The umestored daemon no longer implements queuing. To support queuing semantics for UMQ clients and both publish/subscribe and queuing semantics for JMS clients, the UMQ client API now supports the Advanced Messaging Queuing Protocol 1.0 wire protocol. Also, the UMQ package now includes Informatica-supported versions of the open-source Apache ActiveMQ broker and ActiveMQ JMS client API.

The Ultra Messaging JMS API and its associated file-based and JNDI configuration methods are now discontinued.

UMQ 6.8 also includes an Ultra Messaging Persistence Adapter for ActiveMQ, which implements a robust, commodity-based replication protocol between brokers using UM Persistence (with instances of umestored to persist the replication stream). The UM persistence adapter also implements a quorum-based heartbeat and leader-election protocol to coordinate broker availability.

The Ultra Load Balancing (ULB) feature is unaffected by the changes in this release and continues to operate as before.
New configuration option: broker (context).
New Broker transport statistics added:
You cannot set option umq_queue_participation (receiver) to a value of 2.
You cannot use the lbm_rcv_umq_deregister() function with brokered contexts.
Sources in a brokered context cannot send Application Headers. Use Message Properties as an alternative.

For more information on upgrading queuing applications, see Queuing Upgrade Considerations.

Dynamic Router Enhancements for 6.8 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None

Fixed Problems and Limitations for 6.8 <-

Streaming Fixed Problems and Limitations for 6.8 <-

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

Change Request	Description
2219	A Windows application crashes if you set configuration option fd_management_type (context) to '`select`'. The valid option for Windows is '`wsaeventselect`'. As a solution, now if you set a Windows application configuration option fd_management_type (context) to '`select`', Ultra Messaging returns an error.
6290	In Java, if you reuse the same com::latencybusters::lbm::LBMMessageProperties object for every message sent, to adjust those properties dynamically between sends, you are forced to call com::latencybusters::lbm::LBMSourceSendExInfo::setMessageProperties. As a solution, the com::latencybusters::lbm::LBMSourceSendExInfo object now maintains a reference to an com::latencybusters::lbm::LBMMessageProperties object, if it is set, such that the current value of the com::latencybusters::lbm::LBMMessageProperties is used at the time of the send, rather than the value of the properties at the time which com::latencybusters::lbm::LBMSourceSendExInfo::setMessageProperties() was called. Also, for Java and .NET, the com::latencybusters::lbm::LBMSourceSendExInfo::setApplicationHeaderChain(), .setChannelInfo(), .setIndexInfo(), .setMessageProperties(), and .setTotalLifetimeInfo() APIs now update the flags of the com::latencybusters::lbm::LBMSourceSendExInfo as appropriate.
8825	An Ultra Messaging Java application might crash when using the com::latencybusters::lbm::UMERegistrationIdExCallbackInfo or UMERecoverySequenceNumberCallbackInfo callback methods.
8926	A hotfix or EBF version of the DRO installer on Windows fails to install unless the version of Ultra Messaging on the system had exactly the same version number. As a solution, the DRO installer on Windows now permit installation if the major and minor versions (x.y) are the same.
9015	Message Properties has a memory leak when adding more than 16 message properties.
9024	Ultra Messaging range configuration options pairs do not validate values to ensure that the low range value is less or equal to the high range value.
9025	The lbmpong.c sample application might cause the following fatal assert: `FATAL: failed assertion [src->exbq!=NULL] at line 2155 in ../../../../src/lib/lbm/lbmsrc.c`
9028	If the function lbm_deserialize_response() has a NULL pointer for the second variable, the function returns an LBM_EINVAL. As a solution, the lbm_deserialize_response() function now fatally asserts if NULL is passed for the '`lbm_context_t`' and/or '`lbm_serialized_response_t`' arguments.
9029	Ultra Messaging Datagram Bypass Layer (DBL) still uses Myricom DBL version 1. As a solution, Ultra Messaging now uses Myricom DBL version 3.
9033	A Windows receiver using FD management type wincompport might crash with the following log message: `Core-5688-3839: lbm_fd_handle_events line 4463: wincport recv WSA err 0 (Not a WSA error.) from peer not a connected socket`
9034	The lbmrd process no longer requires a license to run, but the help menu still references the "-f" command line option/value, which has no effect.
9035	An HFX receiver with option receiver_callback_service_time_enabled (context) option set to 1 might crash or operate without getting any data.
9036	When referenced from an IDE, the Ultra Messaging .NET API libraries do not specify Informatica as creator.
9086	Multi homed windows machines where the IP addresses of at least two NICs have the same number of digits might return the wrong IP address for an adapter name.
9090	For the LBT-RM transport, the '`nak_stm_min`' and `nak_tx_min` statistics might contain incorrect values, such as MAX_INT+1 or 0x100000000, due to being incorrectly initialized. As a solution, these statistics are now correctly initialized to 0.
9092	In a Java sending application, if you set the message properties flag while sending but do not set the actual message properties object, the application might crash.
9077	When you set option resolver_multicast_incoming_address (context) to 0.0.0.0, the Ultra Messaging application exits during topic resolution.
9143	An Ultra Messaging application using fd management type `epoll` might have file descriptors silently become unregistered.
9146	When delivering a no source notification to a UM wildcard receiver application, it may experience a segmentation fault.
9147	Ultra Messaging unicast applications might process topic resolution data from lbrmd resolver daemons that they are not configured to use.
9152	An Ultra Messaging application using fd management type select might fatally assert with the following message: `FATAL: failed assertion [index<fdm->select_fd_count]`
9155	The lbm_event_dispatch() function might invoke a user callback before the associated event queue has been shut down. As a solution, the lbm_event_dispatch() function now checks the event queue shutdown status before calling a user callback, but still always processes UNBLOCK events.
9155	When sending serialized Ultra Messaging responses via the DRO, the Ultra Messaging request application might not receive them.
9160	For AIX systems, a setsockopt call for '`IP_ADD_MEMBERSHIP`' might fail silently, possibly resulting in an EOS without a BOS. As a solution, if this failure occurs Ultra Messaging now retries the call and generates the following log message: `Core-9160-1: INFO: Attempted IP_ADD_MEMBERSHIP on multicast receive socket returned ENOBUFS, retrying.`
9169	An application might freeze when a new thread tries to dispatch events after the event queue is shut down.
9176	In certain configurations, contexts do not learn Domain IDs as expected. To avoid this, all contexts in the same Topic Resolution Domain (TRD) must use the same value for the option resolver_domain_id_active_propagation_timeout (context).
9191	In Java, when you send message properties set in an com::latencybusters::lbm::LBMSourceSendExInfo object, garbage collection might corrupt the message. As a solution, com::latencybusters::lbm::LBMSourceSendExInfo objects now maintain a reference to com::latencybusters::lbm::LBMMessageProperties objects, if set.
9205	In Java, Ultra Messaging ignores the com::latencybusters::lbm::LBMApplicationHeaderChain object that is passed into the com::latencybusters::lbm::LBMSourceSendExInfo constructor.
9298	If an Ultra Messaging application's context thread processing is delayed significantly, the LBT-RM or LBT-RU receiver activity might time out before the application adds a receiver socket file descriptor to the Ultra Messaging file descriptor set. This causes a memory corruption.
9370	In a Windows application using transport TCP, the application might fatally assert with the following message: `FATAL: failed assertion [handle==conn->sock->sock] at line 980 in lbm\lbmtcp.c`
9372	When you enable '`LBM_CONTEXT_DELAY_WARNING_THRESHOLD`', the context delay value displays a misleading value in seconds. As a solution, the context delay time printed now shows the correct value.
9436	Message selectors that consist of only white space cause a message selector parsing error.

Persistence Fixed Problems and Limitations for 6.8 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
4727	If you restart all UMP stores simultaneously, UMP stores cannot recreate proxy sources. As a solution, the UMP Store now maintains information about proxy sources as part of the per-source state, and can elect proxy sources upon restart of the store daemon if necessary. Once restarted, a store waits for the configured source-activity-timeout before it attempts to create a proxy source.
8814	Some UMP store log messages are missing newlines.
9023	A receiver might disable the option to use Late Join without disabling UMP store participation, which is an invalid configuration. As a solution, if a receiver subscribes to a persistent source with ume_use_store (receiver) enabled but use_late_join (receiver) disabled, the use_late_join (receiver) option is automatically enabled for that source only. and you see the following log message: `LOG Level 7: Core-6959-1: INFO: Receiver on topic "xyz" has its use_late_join option disabled but has a persistent source on transport TCP:10.29.3.42:14371:7d6a8a86[4208529623].` To opt out of Late Join when subscribing to persistent sources, you must also disable the ume_use_store (receiver) option. This will not cause a receiver with use_late_join (receiver) disabled to participate in Late Join from a non-persistent source.
9037	If a store with receiver paced persistence enabled experiences transport-level loss, then a UMP source might fail to decrement the flight size count and block indefinitely without sending.
9091	If you run the Java umesrc sample application without specifying a store, the application should exit, but does not. As a solution, the Java umesrc now displays an error message and exits if you do not specify a store.
9094	The .NET umesrc sample application crashes when using the "-S" command line option to input a valid store IP and port.
9095	The .NET umesrc sample application crashes when using the "-S" command line option to input a valid store IP and port.
9214	With low flight size settings, in-flight messages might experience minor processing delays.
9302	A store service starting up on Windows might lose data or become unstable if it attempts to read locked cache or state files. As a solution, the store now exits at startup if any cache or state files are found to be locked by another process.
9323	Ultra Messaging might incorrectly drop a message that follows a fragmented message.
9443	A receiver might get late join messages even if use_late_join (receiver) is disabled. This was caused by the original solution to bug 9027, which forcibly enabled use_late_join (receiver) for a receiver that joined a persistent stream from at least one source. This caused the receiver to also Late Join from non-persistent sources on the same topic discovered after the persistent source. As a solution, Late Join participation is now forcibly enabled only with respect to persistent sources; a receiver does not Late Join from non-persistent sources on the same topic if the use_late_join (receiver) option is disabled. See description for bug 9027 for more details.

Queuing Fixed Problems and Limitations for 6.8 <-

The following bug fixes apply to the UMQ product.

Change Request	Description
8621	Configurations with multiple slave queue instances can cause data loss, crashes or an inability to restart without removal of cache and state files (resulting in data loss). Informatica recommends deploying only configurations with a single queue instance without slaves. To facilitate failover, configure the '`sinc-log-filename`', `sinc-data-filename`, and '`sinc-queue-swap-filename`' to write to a shared file system, and use external process management (automatic or manual) to start up a backup queue instance referencing the same files if and only if the active instance fails (i.e. only allow one queue instance to access the files at any time). Note that host failures (e.g., OS, disk, server) may still result in data loss. With this configuration, sinc files grow over time, so perform clean restarts (i.e., shut down, delete all files and restart) periodically. Using a shared file system may also impact performance; Informatica recommends holistic system performance characterization prior to production deployment.
8798	You cannot send messages with a zero-length payload.
9148	When a Java source uses ULB and sends messages with com::latencybusters::lbm::LBMSourceSendExInfo without a per-send client object, a memory leak occurs. As a solution, the call to the lbm_src_send_count_expected_terminals() function occurs only when there is a per-send client present.
9305	The sample Java application umqrcv.java might produce garbled output.
9318	The .NET sample application umqrcv.cs no longer deregisters upon exit by default. Use the - D command line option.

Dynamic Router Fixed Problems and Limitations for 6.8 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request	Description
8851	Setting option <max-datagram> to a value other than the default of 65535 can cause the DRO to hang. As a solution, the DRO now discards wrong-sized messages and continues.
8979	Incorrect DRO endpoint Domain IDs propagate continuously, without a mechanism for resetting other than restarting all contexts in the TRD.
9026	When a DRO peer link closes the connection, the other peer issues the following log message: `Gwd-6033-618: peer portal [GW_0_to_GW_2] inbound connection destroyed due to socket failure` As a solution the other peer now issues the following correct log message: `Gwd-6033-618: peer portal [name] inbound connection destroyed due to disconnect`
9144, 9153	On UNIX platforms, DRO daemons using single-tcp peer links might incorrectly declare peer links as inactive, and attempt to tear down and re-establish the peer connection. As a solution, for UNIX platforms the DRO now forces the peer portal option fd_management_type (context) to '`select`' regardless of the user's configuration settings.
9178	In certain configurations using varying values of configuration option resolver_domain_id_active_propagation_timeout (context), Ultra Messaging might assign incorrect domain ID values.
9299	When using DRO peer portals, a peer disconnect might result in a deadlock, which causes the DRO to stop functioning and requires a restart.

Special Upgrade Instructions for 6.8 <-

UM 6.8 Improved Defaults <-

The following configuration options have had their default values changed. The intention is for these values to be generally better for users, so you may benefit from them. However, some users may have tuned their applications and/or environments to conform to the old defaults. You should examine these options and compare them to values that you may have set, paying special attention to options that you do not set, since those may result in behavior changes in your system. Contact Informatica Support for assistance.

The following configuration options default values are changed:

Option	Old Default	New Default	Notes
mim_incoming_address (context)	224.10.10.21	0.0.0.0	Disable MIM reception by default to avoid the possibility of default-configured applications sending data that is heard by all contexts. NOTE: This disables reception of MIM by default.
retransmit_request_outstanding_maximum (receiver)	200 messages	10 messages	Use a more efficient setting for streaming or persistent late join.
response_tcp_deletion_timeout (context)	2000 ms	20,000 ms	Use a longer timeout to avoid wasted CPU time caused by unnecessary TCP socket tear down and recreation, along with associated log messages.
resolver_domain_id_active_propagation_timeout (context)	-1	0	This new value where contexts learn of domain IDs from active DROs only is now the default.
fd_management_type (context)	wsaeventselect (Windows)	wincompport (Windows)

Upgrading Brokered Queuing and JMS <-

In UM version 6.8, the brokered queuing functionality and JMS API was re-implemented with an enhanced ActiveMQ-based JMS/AMQP broker. In many cases, the UM queuing API can still be used with few if any changes.

Note: Important: If you are upgrading non-ULB queuing applications from versions prior to 6.8, note that this upgrade has a major impact on your applications and deployment. The umestored daemon no longer implements queuing functionality; instead, the UMQ client API now uses the AMQP protocol to communicate with an ActiveMQ broker for queuing functionality. You must rebuild applications, redeploy daemons, and perform a flash cut over. Also, review your applications for functionalities that are deprecated in UMQ 6.8 or later. UMQ clients using version 6.8 or later will not interoperate with a pre-6.8 umestored-based queue broker. UMQ clients using versions earlier than 6.8 will not interoperate with an ActiveMQ broker. For more information, see the Guide for Queuing.

See Queuing Upgrade Considerations for more information about upgrading brokered queuing applications.

MIM Disabled by Default <-

As of UM version 6.8, the configuration option mim_incoming_address (context) defaults to 0.0.0.0, disabling reception of MIM messages.

If your application uses MIM and you explicitly set either mim_incoming_address (context) or mim_address (context), this change will not affect you. However, if you use MIM and depend on the default settings, your MIM receivers will stop working.

Informatica recommends that all users of MIM explicitly set the configuration option mim_address (context).

Previous Special Instructions <-

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

UM Version 6.7.3 <-

The most significant update to UM version 6.7.3 is the repair of a critical bug that primarily affects the DRO when using peer links.

Attention: There are some special upgrade instructions for UM versions 6.7 and beyond that will affect a small percentage of users upgrading from pre-6.7 versions of UM. See Special Upgrade Instructions for 6.7. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.7.3 <-

Streaming Enhancements for 6.7.3 <-

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

Ultra Messaging 6.7.3 introduces the following new Java class and methods:
These methods allow Java applications to extract a serialized response (a byte array representation of the request originator's address) from a received request message, and allow either the same application or another application (if the byte array representation is passed to the other application, e.g., via a standard message) to use that serialized response to send a response to the request originator.

Persistence Enhancements for 6.7.3 <-

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

None.

Queuing Enhancements for 6.7.3 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionality is retained.

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

None.

Dynamic Router Enhancements for 6.7.3 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.7.3 <-

Streaming Fixed Problems and Limitations for 6.7.3 <-

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

Change Request

Description

9508

On Windows, an application might crash when a TCP receiver disconnects from a TCP source.

9515

Multi-homed windows machines where the IP addresses of at least two NICs have the same number of digits might return the wrong IP address for an adapter name.

9516

When using DRO peer portals, a peer disconnect might result in a deadlock, which causes the DRO to stop functioning and requires a restart.

Persistence Fixed Problems and Limitations for 6.7.3 <-

The following bug fixes apply to UMP and UMQ products.

None.

Queuing Fixed Problems and Limitations for 6.7.3 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionality is retained.

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.7.3 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

UM Version 6.7.2 <-

Ultra Messaging version 6.7.2 consists only of the UMS product for the Stratus OpenVOS platform.

Attention: There are some special upgrade instructions for UM versions 6.7 and beyond that will affect a small percentage of users upgrading from pre-6.7 versions of UM. See Special Upgrade Instructions for 6.7. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.7.2 <-

Streaming Enhancements for 6.7.2 <-

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

UMS 6.7.2 is available for the Stratus OpenVOS platform.

UM Version 6.7.1 <-

The most significant update to UM version 6.7 is the inclusion of the HP NonStop platform for the UMP product. Note that daemons are not supported on NonStop, only client applications.

Attention: There are some special upgrade instructions for UM versions 6.7 and beyond that will affect a small percentage of users upgrading from pre-6.7 versions of UM. See Special Upgrade Instructions for 6.7. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.7.1 <-

Streaming Enhancements for 6.7.1 <-

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

You can now set how a context learns the ID of its own Topic Resolution Domain (TRD) with option resolver_domain_id_active_propagation_timeout (context). This provides more flexibility in situations where you might need to change the Topic Resolution Domain (TRD) ID values for contexts.
Log messages 'Core-5688-1882' and 'Core-5688-1891' now display delay times in seconds and milliseconds, instead of seconds only.

Persistence Enhancements for 6.7.1 <-

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

Ultra Messaging Persistence Edition is now available on the HP NonStop platform. For information on limitations, see the Documentation Introduction.

Queuing Enhancements for 6.7.1 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionality is retained.

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

None.

Dynamic Router Enhancements for 6.7.1 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.7.1 <-

Streaming Fixed Problems and Limitations for 6.7.1 <-

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

Change Request	Description
3944	The '`lbmpong.c`' sample application might cause the following fatal assert: `FATAL: failed assertion [src->exbq!=NULL] at line 2155 in ../../../../src/lib/lbm/lbmsrc.c`
6186	If the function lbm_deserialize_response() has a NULL pointer for the second variable, the function returns an LBM_EINVAL. As a solution, the lbm_deserialize_response() function now fatally asserts if NULL is passed for the '`lbm_context_t`' and/or '`lbm_serialized_response_t`' arguments.
7526	If an Ultra Messaging application's context thread processing is delayed significantly, the LBT-RM or LBT-RU receiver activity might time out before the application adds a receiver socket file descriptor to the Ultra Messaging file descriptor set. This causes a memory corruption.
7945	When delivering a no source notification to a UM wildcard receiver application, it may experience a segmentation fault.
8428	The lbm_event_dispatch() function might invoke a user callback before the associated event queue has been shut down. As a solution, the lbm_event_dispatch() function now checks the event queue shutdown status before calling a user callback, but still always processes UNBLOCK events.
8517	An Ultra Messaging application using fd management type select might fatally assert with the following message: `FATAL: failed assertion [index<fdm->select_fd_count]`
8750	An HFX receiver with option receiver_callback_service_time_enabled (context) option set to 1 might crash or operate without getting any data.
8788	Ultra Messaging Datagram Bypass Layer (DBL) still uses Myricom DBL version 1. As a solution, Ultra Messaging now uses Myricom DBL version 3.
8812	Ultra Messaging range configuration options pairs do not validate values to ensure that the low range value is less or equal to the high range value.
8856	The lbmrd process no longer requires a license to run, but the help menu still references the "-f" command line option/value, which has no effect.
8874	When referenced from an IDE, the Ultra Messaging .NET API libraries do not specify Informatica as creator.
8879	An Ultra Messaging application using fd management type `epoll` might have file descriptors silently become unregistered.
8898	A Windows receiver using FD management type wincompport might crash with the following log message: `Core-5688-3839: lbm_fd_handle_events line 4463: wincport recv WSA err 0 (Not a WSA error.) from peer not a connected socket`
8919	For the LBT-RM transport, the lbm_rcv_transport_stats_lbtrm_t::nak_stm_min and lbm_rcv_transport_stats_lbtrm_t::nak_tx_min statistics might contain incorrect values, such as MAX_INT+1 or 0x100000000, due to being incorrectly initialized. As a solution, these statistics are now correctly initialized to 0.
9013	Ultra Messaging unicast applications might process topic resolution data from lbrmd resolver daemons that they are not configured to use.
9040	When sending serialized Ultra Messaging responses via the DRO, the Ultra Messaging request application might not receive them.
9077	When you set option resolver_multicast_incoming_address (context) to 0.0.0.0, the Ultra Messaging application exits during topic resolution.

Persistence Fixed Problems and Limitations for 6.7.1 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
8933	An Ultra Messaging Java application might crash when using the com::latencybusters::lbm::UMERegistrationIdExCallbackInfo or com::latencybusters::lbm::UMERecoverySequenceNumberCallbackInfo callback methods.
5141	If you run the Java umesrc sample application without specifying a store, the application should exit, but does not. As a solution, the Java umesrc now displays an error message and exits if you do not specify a store.
6959	When a UMP receiver subscribes to a UMP source with option ume_use_store (receiver) enabled, the application can not disable the option use_late_join (receiver).
8140	When option source_includes_topic_index (context) is enabled, the source string delivered to the UME recovery sequence number callback does not include the topic index.
8963	If a store with receiver paced persistence enabled experiences transport-level loss, then a UMP source might fail to decrement the flight size count and block indefinitely without sending.
8995	The .NET umesrc sample application crashes when using the "-S" command line option to input a valid store IP and port.
9010	The .NET umesrc sample application sometimes crashes when the store name length equals 0.

Queuing Fixed Problems and Limitations for 6.7.1 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionality is retained.

The following bug fixes apply to the UMQ product.

Change Request

Description

8950

When a Java source uses ULB and sends messages with com::latencybusters::lbm::LBMSourceSendExInfo without a per-send client object, a memory leak occurs. As a solution, the call to the lbm_src_send_count_expected_terminals() function occurs only when there is a per-send client present.

8966

When a queue daemon terminates and restarts with a reset state, the source might resubmit a message that the queue daemon has already stabilized.

8967

When the queue daemon receives messages via UMQ pro-active retransmission, some of these messages might not have the LBM_MSG_FLAG_UMQ_RESUBMITTED flag.

Dynamic Router Fixed Problems and Limitations for 6.7.1 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request

Description

8859, 8871, 9002

On UNIX platforms, DRO daemons using single-tcp peer links might incorrectly declare peer links as inactive, and attempt to tear down and re-establish the peer connection. As a solution, for UNIX platforms the DRO now forces the peer portal option fd_management_type (context) to 'select' regardless of the user's configuration settings.

8873

When a DRO peer link closes the connection, the other peer issues the following log message:
Gwd-6033-618: peer portal [GW_0_to_GW_2] inbound connection destroyed due to socket failure
As a solution the other peer now issues the following correct log message:
Gwd-6033-618: peer portal [name] inbound connection destroyed due to disconnect

8979 Incorrect DRO endpoint Domain IDs propagate continuously, without a mechanism for resetting other than restarting all contexts in the TRD.

UM Version 6.7 <-

The most significant update to UM version 6.7 is interoperability with pre-6.0 versions of UM. Applications and persistent stores at version 6.7 are able to exchange messages and control information with 5.x applications, especially 5.3.6.

However, note that 6.7 applications are not able to interoperate with daemon components of 5.x, including the persistent store and the 5.x gateway. Also, 5.x applications are not able to interoperate with version 6.7 DRO.

Attention: There are some special upgrade instructions for UM versions 6.7 and beyond that will affect a small percentage of users upgrading from pre-6.7 versions of UM. See Special Upgrade Instructions for 6.7. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.7 <-

Streaming Enhancements for 6.7 <-

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

Receive-Side Batching - reduces latency and increases throughput in UM applications by bundling multiple messages to deliver. This bypasses the need to perform a boundary crossing for each delivered message.

You enable Receiver-Side Batching with configuration option delivery_control_message_batching (context). With C and .NET applications, you must be using an event queue for this feature (this is not a requirement for Java applications).
The unicast resolver daemon, lbmrd, no longer requires an Ultra Messaging license to run.
The unicast resolver daemon, lbmrd, now has command-line options to set buffer size in bytes for the receive socket buffer ("-r" flag) and the send socket buffer ("-s" flag).
In addition to Receive-Side Batching, other improvements have further reduced the latency and increased the throughput of the Java API.
When an error occurs on a socket while sending an ACK in LBT-RU, UM now generates an EOS immediately.
You can now set a source activity timeout for LBT-TCP sessions, with new configuration option transport_tcp_activity_timeout (source).
For UM XML configuration files and UMP store daemon XML configuration files you can use the 'XInclude' mechanism to merge multiple configuration files.

Persistence Enhancements for 6.7 <-

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

Throttled Delivery - you can limit the number of message fragments that a persistent receiver delivers to a receiver application beyond the current highest consumed message fragment. This limits the amount of memory a receiver uses when that receiver consumes messages at rate much slower than the recovery rate from a UMP store or slower than the UMP source stream. To use UMP Throttled Delivery, set the new option ume_application_outstanding_maximum (receiver).
Enhanced Quorum/Consensus Store Registration and Message Stability
- Quorum/Consensus functionality is enhanced in the following ways:
  - When setting option ume_retention_intragroup_stability_behavior (source) to 'all-active', the source requires, minimally, a quorum of stores to successfully stabilize a message within the group.
  - The ume_retention_intragroup_stability_behavior (source) and ume_retention_intergroup_stability_behavior (source) options now apply to registration behavior, as well as message stability behavior. With versions earlier than 6.7, intragroup registration was quorum-based only, and intergroup registration completion always occurred after the first store group was registered.
  - During the first cycle of the ume_registration_interval (source) period, a source does not declare Registration Complete unless all stores in all groups respond. With versions earlier than 6.7, a source declares Registration Complete as soon as all stores in one group respond.
  - During subsequent cycles of the ume_registration_interval (source) period, a source declares Registration Complete as soon as the configured settings for the ume_retention_intragroup_stability_behavior (source) and ume_retention_intergroup_stability_behavior (source) options are satisfied. With versions earlier than 6.7, a source declares Registration Complete as soon as a quorum of stores in one group respond.
UM now propagates a source's session ID to receivers. The session ID is visible during registration events as well as during the recovery sequence number callback.

Queuing Enhancements for 6.7 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionality is retained.

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

Dynamic Router Enhancements for 6.7 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

The DRO now checks configuration option values to ensure that they are within valid ranges.
For DRO XML configuration files you can use the 'XInclude' mechanism to merge multiple configuration files.

Fixed Problems and Limitations for 6.7 <-

Streaming Fixed Problems and Limitations for 6.7 <-

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

Change Request	Description
2551	With adaptive batching enabled, applications sometimes issue a warning assertion, `WARNING: failed assertion [imbq->stats.ttss_mean<=imbq- >stats.ttcs_mean]` As a solution, since the condition is harmless, the warning is removed.
5242	Web monitor support link text displays, "29West Ultra Messaging Support". This is now changed to display, "Informatica Ultra Messaging Support".
5626	Ultra Messaging client XML configuration validation sometimes fails needlessly. As a solution, XML configuration parsing now tolerates invalid values such that you can use a single XML config file or UMM configuration template across multiple platforms, even if it contains option values that are not valid for all platforms.
7261	If automatic monitoring is misconfigured, instead of silently failing the creation and proceeding with a context or event queue setup, Ultra Messaging now logs the following messages: `Could not create automon controller: CoreApi-5688-3059: automatic monitoring initialization failed [4099] [Transport module source init function returned -1, lbmaux_context_attr_setopt_from_file() failed CoreApi-5688-4374: invalid configuration line in mcast.cfg, line 1: xxxxxxx
7917	Destroying a source that matches a wildcard pattern, while dispatching an event queue with events from that source, creates a race condition.
7939	LBT-RU does not indicate in the packet when a datagram is a retransmission. As a solution, Ultra Messaging now marks retransmitted LBT-RU datagrams with a retransmit flag. This flag is visible only with packet dissection tools such as Wireshark.
7944	Using the function lbm_context_attr_dup() might cause a `src->res_ucast_daemons!=NULL` assert when the original attributes do not contain a setting for the UM configuration option resolver_unicast_daemon (context) and when that option is then set after the original is created.
8024	For Late Join, OTR, or Request/Response, Ultra Messaging does not perform NAT translation correctly.
8065	When using DROs, Ultra Messaging applications can cache old data that later can cause errors when creating and deleting wildcard receivers. The Ultra Messaging application context now cleans out this old data when it receives DRO proxy source delete messages.
8108	Ultra Messaging accepts configuration option resolver_unicast_daemon (context) when it specifies more than one address. As a solution, incorrectly setting this option now issues message `CoreApi-7875-1` indicating that multiple values are not allowed for this option.
8114	The lbmrd resolver sometimes issues message `LOG Level 6: Core-5688-3375: unicast resolver xxx.xxx.xxx.xxx:xxxx went inactive` while the resolver is active.
8153	When a receiver receives increasingly large messages, a memory leak might occur.
8150	Ultra Messaging may now declare fragments requested for retransmission by a receiver from a store as unrecoverable prior to the retransmission request timeout, if all stores have declared that fragment unrecoverable.
8160	On a 64-bit UNIX platform using a UM XML configuration file, certain context names, event queue names, topic names, and wildcard patterns are not picked up, even though the configuration file specifies them.
8198	Mellanox Ultra Messaging applications with option ud_acceleration (context) set to 1 were forcing the VMA_SELECT_POLL environment variable to 0, resulting in poor latency performance. Applications can now set VMA_SELECT_POLL to the desired value, or can allow the Mellanox default value.
8277	LBT-SMX transport statistics include unsupported request/response statistics. As a solution the field lbm_reqs_rcved is renamed to '`reserved1`' in the lbm_rcv_transport_stats_lbtsmx_t structure.
8283	LBMMON statistics receivers now report correct values for SMX transport statistics.
8295	The lbmrd unicast resolver daemon propagates certain non-LBMR messages to clients. As a solution, lbmrd now ignores these messages.
8444	When using LBT-RU and Source Side Filtering, a `bvec->buffs[0]!=NULL` fatal assert can occur when receivers are connecting, messages are being sent, and there is loss and retransmissions. As a solution, Ultra Messaging now takes the proper lock when sending the Source Side Filtering initialization message.
8557	When you configure LBT-RU context and receiver port ranges to overlap, Ultra Messaging allows this and logs many copies of `Core-5688-1796` messages. As a solution, Ultra Messaging now throttles this message as shown in the following example: `LOG Level 6: THROTTLED MSG: Core-5688-1796: LBT-RU receiver received unknown packet type 6. Origin: 10.29.3.187:16001 0.9995 secs. 0 msgs/sec. 0 bps` `LOG Level 6: ...previous THROTTLED MSG repeated 25 times in 3 seconds`
8591	Sometimes for invalid receiver configuration combinations, Ultra Messaging repeats warning log messages for every transport joined. As a solution, invalid receiver configuration combinations now issue this warning once at receiver creation time.
8608	A Java or .NET hot failover receiver that experiences loss might assert with fatal assertion:[d_entry->topic_entry != NULL].
8610	Message properties do not clear in Java and C# before loading the properties of the next message to be delivered.
8633	The function lbm_context_process_events() returns -1 for non-critical errors without further description. As a solution, Ultra Messaging no longer returns -1 from lbm_context_process_events() for non-critical errors.
8662	In the Java API, the array of stores returned by com::latencybusters::lbm::LBMSourceAttributes::getStores() contains an incorrect number of entries when using named stores. In addition to the solution for this, the com::latencybusters::lbm::UMEStoreEntry class now contains a new field to provide store name information.
8682	The lbm_serialize_response() function does not include the Domain ID in the serialized message. When a serialized response message traverses a DRO to a different topic resolution domain, the message cannot reach the requester, and the lbm_deserialize_response() function logs the following warning: `Core-6259-25: Deserialize Response: Context in domain 1 received response with no domain...` As a solution, serialized response messages now include the topic resolution domain ID.
8726	If you set ume_retention_unique_confirmations (source) to 0 and ume_confirmed_delivery_notification (source) to 3, the first delivery confirmation sets the UNIQUE_ACKS flag. As a solution, this flag now sets only if you set option ume_retention_unique_confirmations (source) to a value greater than 0 and the number of confirmations received are enough to exceed the threshold.
8732	With option hf_duplicate_delivery (receiver) and ordered delivery enabled, hot failover receivers might deliver duplicate messages before the original messages. With this solution, messages flagged as duplicate are always be delivered after messages not flagged as duplicate.
8733	Hot failover receivers might leak memory when processing HF reset commands or when deleted.
8743	An Ultra Messaging application or daemon fatally asserts with message: `[dest] at line 481 in ../../../../src/lib/lbm/lbmrxrctlr.c` if the application receives malformed data on an Ultra Messaging tcp socket or under other rare conditions.
8797	Java method com::latencybusters::lbm::LBM::setDebugMask() sets incorrect mask values on 32-bit platforms.
8868	In the Java and .NET APIs, some objects accessible from an LBMMessage object are sometimes newly created for each LBMMessage delivered, in violation of the Zero Object Delivery (ZOD) functionality. The affected objects include com::latencybusters::lbm::LBMMessageChannelInfo for messages received on a spectrum channel, com::latencybusters::lbm::UMQIndexInfo for queueing messages with an index, and com::latencybusters::lbm::UMQMessageId for all queueing or ULB messages received. As a solution, com::latencybusters::lbm::LBMMessage objects now re-use these object types for each new message delivery, rather than creating new objects. Note You might have applications that no longer work correctly because of this change. To use the '`LBMMessageChannelInfo`', '`UMQIndexInfo`', or '`UMQMessageId`' objects outside of the onReceive callback, you must first make a copy of the object using its constructor, or call promote() on the LBMMessage object.

Persistence Fixed Problems and Limitations for 6.7 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
1013	When a umestored configuration file sets the '`<log>`' type attribute to the unsupported value of syslog, the umestored daemon reports the following error message: `daemon section log entity must have a value` As a solution, the umestored daemon now reports the following error message: `daemon log does not currently support syslog type`
3894	When both registration IDs and session IDs are present, Ultra Messaging issues a log message stating that registration IDs are being ignored, but then fails to ignore them.
5273	Upon startup, a store could delay persistence of messages for up to the configured retransmit_request_generation_interval value, while attempting to recover messages from the source that the source has already reclaimed. As a solution, the source reports the non-availability of the requested messages back to the store, and the store can begin persistence without extra delay.
5498	The umestored daemon warns that option resolver_active_threshold (context) is deprecated. This warning is now removed. Setting this option continues to have no effect.
6112	The umercv sample application prints session IDs in decimal format. As a resolution, all sample applications now print Session IDs in hexadecimal, and continue to print registration IDs in decimal.
7282, 8223	A store might fail in certain incorrect registration scenarios. As a solution, if applications present invalid session ID and registration ID combinations, they now receive a registration error.
8171	An RPP-configured source can get an assert with the following log message: `LOG Level 1: FATAL: failed assertion [info->sqn==ctlr->trail_sqn] at line 305 in ../../../../src/lib/lbm/lbmrxsctlr.c` This can happen when the source re-registers with a reduced-fd repository.
8185	RPP stores can now send a stability ack for a message that was lost but later recovered via retransmission.
8245	Configuring UMP stores using non-increasing group index order, such as configuring storeA in group 2 before storeB in group 1, causes erroneous registration changes and indeterminate receiver behavior.
8677	With the Java API, on a Persistence deregistration event, the Ultra Messaging library delivers a com::latencybusters::lbm::UMEDeregistrationCompleteInfo with invalid contents. As a solution, since there is no information associated with this event, the com::latencybusters::lbm::LBMMessage::deregistrationCompleteInfo() method now always returns null.
8704	Ultra Messaging handles stability acknowledgements on the same thread as retransmissions, affecting the consistency of latency. As a solution, stability acknowledgements now use a different thread.
8710	With option ume_confirmed_delivery_notification (source) set to 3, after ume_retention_unique_confirmations (source) is reached, the whole message confirmed flag is not set for delivery confirmations for all receivers.
8711	In the .NET (C#) API, there are no methods to access objects com::latencybusters::lbm::UMESourceEventDeregistrationSuccessInfo and com::latencybusters::lbm::UMESourceEventDeregistrationCompleteInfo. As a solution, the C# library now includes accessor methods.
8747	Sometimes an application receives and acts upon retransmit response information intended for a different application. This solution makes retransmit requests more unique to the application issuing the request to prevent potential cross-contamination of retransmit response information during application restarts.
8766	UMP stores might accept messages from a UMP source that has not completed the registration process, resulting in the following fatal assertion: `[EMERGENCY]: FATAL: failed assertion [MUL_SQN_GTE(info->sqn, next_avail_sqn)] at line 1221 in ../../../../src/stored/umerepo.c`
8804	If there is a disk error modifying the state file on receiver registration, the umestored daemon writes to an invalid location, possibly causing a corrupted state file or umestored segmentation fault. As a solution, umestored no longer writes to an invalid location but instead issues a log-message warning.
8808	Store daemons sometimes issue a Store-5688-5258 message. As a solution, the umestored configuration code now disallows using multiple async write callbacks. This prevents situations where multiple writes could be executed out of order, causing data corruption.

Queuing Fixed Problems and Limitations for 6.7 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionalty is retained.

The following bug fixes apply to the UMQ product.

Change Request	Description
8315	In the .NET API, Ultra Messaging reuses com::latencybusters::lbm::LBMMessageChannelInfo, com::latencybusters::lbm::UMQMessageId, and com::latencybusters::lbm::UMQIndexInfo objects between different com::latencybusters::lbm::LBMMessage objects for delivery, reducing garbage collection overhead.
8325	ULB reassigns messages even if option umq_ulb_application_set_message_max_reassignments (source) is set to 1.
8536	When restarting the UMQ daemon while handling zero-length-messages, the daemon sometimes fails with the following fatal assertion: `[EMERGENCY]: FATAL: failed assertion [msg->lbm_msg!=NULL] at line 3896 in ../../../../src/stored/umqsinc.c`
8601	An Ultra Messaging application crashes when ULB or UMQ receivers send a Consumption Report for a message after their source transport had been torn down.

Dynamic Router Fixed Problems and Limitations for 6.7 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

Change Request	Description
7276	When using an aggressive keepalive configuration on a DRO peer link, the DRO might fatally terminate.
8256	When configuring a DRO Peer Connection on a Microsoft Windows machine, the single-tcp configuration option can result in no message traffic across the link. As a solution, Ultra Messaging now handles all documented error conditions, instead of only '`WSAECONNREFUSED`'. This solution addresses issues where a DRO would not reconnect with a peer under timeout conditions.
8303	A DRO might crash when peer connections between two DROs quickly disconnect and reconnect.
8446	For Windows and 32-bit UNIX platforms, the web monitor displays non-zero values for the statistic "Transport topic fragments/bytes dropped due to blocking", but Ultra Messaging does not log the message `[information] Gwd-6945-2: Portal [xxx] dropping data due to high volume.`
8459	Single TCP connections repeatedly disconnect and reconnect under certain conditions.
8461	DRO peer connections, both dual and single TCP, might encounter an error and not be restarted. One side effect for the solution to this is that the DRO now logs every connection attempt failure, resulting in more log messages if the other peer is not up.
8752	Error message: `Core-5688-1890: handle events returned error 4 [CoreApi-5688-3837: WFMO: (87) The parameter is incorrect]` sometimes occurs, primarily in a peer portal connection.
8763	The DRO sometimes asserts with the messages: `WARNING: failed assertion [Portal->peer.adjacent_node_id==0] at line 2679 in ../../../../src/gateway/tnwgpeer.c` and: `FATAL: failed assertion [void_o_entry!=NULL] at line 4205 in ../../../../src/gateway/ tnwgpeer.c`

Special Upgrade Instructions for 6.7 <-

UM version 6.7 is the first version that supports a smooth upgrade path for UM versions prior to 6.0.

Disposing Received Messages in Java <-

In earlier versions of UM, it was possible for Java subscribers to simply release all references to a received message and allow Java to garbage collect the message objects.

In UM version 6.7 and beyond, it is necessary for Java subscribers to dispose of all received message objects by calling the com::latencybusters::lbm::LBMMessage::dispose() method after the application is finished using the message object.

See Java Message Reception for more information.

Note that with .NET, there are some simple use cases where it will work to release all references to a received message and let the .NET framework garbage collect the message objects. However, this capability may change in the future. Informatica recommends following the same rules for .NET as for Java.

Remove lbm_reqs_rcved from SMX <-

In UM version 6.1, the SMX transport was introduced. The UM transport statistics for SMX, lbm_rcv_transport_stats_lbtsmx_t, mistakenly contained a field named "lbm_reqs_rcved". However, the SMX transport does not support request/response. As of UM version 6.7, this field was changed to "reserved1".

Users who have written statistics-oriented code should remove any reference to "lbm_reqs_rcved" and rebuild.

Upgrading From Version Pre-6.0 <-

With the introduction of the DRO, several changes needed to be made to the "wire format" of UM command and control messages. This resulted in 6.0-based applications not being interoperable with pre-6.0 applications. For many customers, this did not pose a significant problem since they were able to upgrade all of their systems in a single step. I.e. there was no need for pre-6.0 applications to exchange messages with 6.0 applications.

However, for many customers, this kind of "flash" upgrade is simply not practical. Therefore, starting with UM version 6.7, an upgrade path was developed which allows different applications to be upgraded at different times, while still allowing those mixed-version applications to exchange messages.

Note: When you upgrade from a previous version, you must set option ume_store_activity_timeout (source) to 10,000 and UMP store option keepalive-interval to 3,000. This avoids unexpected behavior during a phased upgrade.

To upgrade Ultra Messaging from version 5.3.x to version 6.7 and beyond, perform the following procedure:

If the current installation is earlier than 5.3, upgrade all applications and components except UMDS servers to version 5.3.6 or later. (UMDS customers should contact Informatica Support for upgrade advice.)
Pre-6.0 versions of UM are not ABI compatible with 6.0 and beyond. C language application programs must be re-compiled.
If using UMP stores, ensure that all source settings for option ume_store_behavior (source) are set to 'qc' or 'quorum-consensus', and not 'rr' or 'round-robin'.
Upgrade all lbmrd resolver daemons to this release. No configuration changes are required.
If using UMP stores, upgrade all umestored daemons in groupings that observe the following requirements:
- A single source cannot specify a mixture of 5.3.x and this release's umestored daemons.
- Separate sources on the same context can specify daemons of different versions.
- Do not start upgraded daemons with 5.3.x state and cache files.
Note
When upgrading from 5.3.x, if you neglect to set compatibility_include_pre_um_6_0_behavior (context) to 1, receivers incorrectly receive messages without persistence.
Upgrade source and receiver applications. You can upgrade these one by one, in any order. As you upgrade each application, set the following configuration options:
- compatibility_include_pre_um_6_0_behavior (context) to 1
- transport_tcp_use_session_id (source) to 0
These settings must remain during the period when the network contains both applications based on 5.3.x and this release.
If you use Late Join or OTR, review the settings for Late Join or OTR per-message timeout options. Note that option otr_request_duration (receiver) was deprecated in 6.0, and the following options are added:
After all components are upgraded to this release, set the following configuration options:
- compatibility_include_pre_um_6_0_behavior (context) to 0
- transport_tcp_use_session_id (source) to 1

Log Messages During Upgrade <-

For 5.3.x applications on the same TRD as this release, you might see the following log messages:

LBMC unknown next header 64: Informational. You can ignore this message. You can reduce the frequency of this message by increasing the value for context option response_tcp_deletion_timeout (context).

LBMR Topic Info Record malformed. Dropping remainder: Issued for every TIR that contains a TCP Session ID. You must set option transport_tcp_use_session_id (source) to 0 during the interim migration period.

LOG Level 5: Core-5688-3387: LBMR Extended Type 0x7 incorrect (10.29.3.49:40633 len 102). [...D.....<.............1I...........(>..............store-name............ (>.........................$]. Dropping.: Informational. This occurs if UMP store umestored daemons are present and configured with a discoverable name. For each name advertisement, all contexts drop the packet and log this warning.

[WARNING]: Core-5688-516: LBMC cntl unknown next header: 55.: Informational. Issued once per transport session when receiving an SRI from a UMP source.

Previous Special Instructions <-

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

UM Version 6.5 <-

The most significant update to UM version 6.5 is the introduction of the Ultra Messaging System Monitoring option.

Warning: UM version 6.5 does not interoperate reliably with versions of UM prior to 6.0 It was not until UM version 6.7 and beyond that interoperability was introduced between the 6.x version line and the 5.x version line.

Attention: There are some special upgrade instructions for UM versions 6.5 and beyond that will affect a small percentage of users upgrading from pre-6.5 versions of UM. See Special Upgrade Instructions for 6.5. For general upgrade instructions, see Upgrade Procedure. You are also advised to inspect the full list of Deprecations.

Enhancements for 6.5 <-

Streaming Enhancements for 6.5 <-

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

Change Request

Description

7911

You can now configure Ultra Messaging to use Solarflare Onload to select transport sockets for acceleration. Onload is a kernel-bypass technology that accelerates message traffic and operates with Solarflare 10GbE Ethernet NICs. See Solarflare Onload for more information.

7974

The lbmrd daemon now includes command line option "-f" or "--lic-file" to let you specify the Ultra Messaging license file.

Persistence Enhancements for 6.5 <-

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

Change Request	Description
7478	The Persistent Store Web Monitor now displays the Session ID on the Store page, Source page, and Receiver page.

Queuing Enhancements for 6.5 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionalty is retained.

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

None.

Dynamic Router Enhancements for 6.5 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

Change Request	Description
7694	You can now use the LBT-SMX transport to send ingress message traffic to a DRO. The DRO no longer ignores topic resolution traffic from a LBT-SMX source. You still cannot, however, use LBT-SMX to send egress traffic from a DRO.

Ultra Messaging System Monitoring Option <-

In conjunction with the Ultra Messaging 6.5 release, Informatica has introduced the Ultra Messaging System Monitor Option (UMSM). Administrators can use UMSM to monitor components of an Ultra Messaging deployment. The UMSM dashboard displays the status of components, such as UM hosts, transports, topic resolution domains, and application instances, as well as UM statistics.

UMSM monitors the messaging traffic of Ultra Messaging versions 5.0 and later.

With the Ultra Messaging 6.5 release, Ultra Messaging Automatic Monitoring sends the following aggregated receiver statistics and subscription information to UMSM:

Aggregate number of topic-level sequence numbers received out of order.
Aggregate number of topic-level sequence numbers declared unrecoverably lost by the delivery of either an LBM_MSG_UNRECOVERABLE_LOSS or LBM_MSG_UNRECOVERABLE_LOSS_BURST event to the receiving application.
Receiver callback service time statistics. Ultra Messaging tracks the mean time, maximum time, and minimum time to service receiver callbacks.

As the collection of aggregated statistics can increase the latency of message delivery, Ultra Messaging does not collect them by default. You can enable UMSM to collect the aggregated message loss statistics with the UM configuration options, monitor_interval (receiver) and monitor_interval (wildcard_receiver). You can access the aggregated receiver statistics with UMSM. The lbmmon API does not provide access to the aggregated receiver statistics.

The Ultra Messaging 6.5 release contains a third new UM configuration option, receiver_callback_service_time_enabled (context), which enables UMSM to maintain receiver callback service times. The lbmmon API does not provide access to the receiver callback service times.

Fixed Problems and Limitations for 6.5 <-

Streaming Fixed Problems and Limitations for 6.5 <-

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

Change Request	Description
7103	FIXED: The lbmsrc.java example application throws an exception if the application sent SDM messages or variable message lengths. lbmsrc.java now correctly adjusts the message buffers as needed.
7125	FIXED: The following two Java send methods that do not work properly when used with a callback object (cbArg): send(byte[] message, int messageLength, int flags, java.lang.Object cbArg) send(java.nio.ByteBuffer message, int startPosition, int messageLength, int flags,java.lang.Object cbArg) These methods are now deprecated. Use the send method that accepts an LBMSourceSendExInfo object instead.
7374	FIXED: An internal synchronization issue can cause LBM_EWOULDBLOCK errors when messages are sent by sources or by MIM.
7602	FIXED: A problem with the lbmmon transport option "wctopic" prevents lbmmon from collecting statistics for sources sending on topics that match the wildcard pattern.

Persistence Fixed Problems and Limitations for 6.5 <-

The following bug fixes apply to UMP and UMQ products.

Change Request

Description

7401, 7527

FIXED: A persistent source using adaptive batching can crash with a segmentation fault.

7627

Converted UM log messages "Core-5688-3110" and "Core-5688-31" to debug log messages. These messages are not essential to normal operation of the Store. If you want to see them, set the LBM_DEBUG_FLAG to LBM_DEBUG_UME.

Queuing Fixed Problems and Limitations for 6.5 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionalty is retained.

The following bug fixes apply to the UMQ product.

None.

Dynamic Router Fixed Problems and Limitations for 6.5 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

Special Upgrade Instructions for 6.5 <-

UM 6.5 Context Stats Expansion <-

In UM version 6.5, the data structure lbm_context_stats_t was expanded with the addition of five fields:

This broke ABI compatibility.

If your application uses the lbm_context_stats_t structure and was originally built with a UM version prior to 6.5, it will have to be recompiled to work with UM 6.5 and beyond. This is because the application allocates the smaller pre-6.5 size. But if that binary is executed with UM 6.5 or beyond, the lbm_context_retrieve_stats() function will assume that it is the larger 6.5-and-beyond size, and will write past the end of the application's structure allocation. This can produce program crashes and corrupted data.

If your program does not use the lbm_context_stats_t structure, then recompiling is not necessary.

UM Version 6.1 <-

The most significant update to UM version 6.1 is the introduction of the LBT-SMX transport type. See New Transport LBT-SMX.

There are no special upgrade instructions from UM version 6.0 to 6.1.

Warning: UM version 6.1 does not interoperate reliably with versions of UM prior to 6.0 It was not until UM version 6.7 and beyond that interoperability was introduced between the 6.x version line and the 5.x version line.

Enhancements for 6.1 <-

Streaming Enhancements for 6.1 <-

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

Change Request	Description
	Added LBT-SMX
7529	Added the polling of context events when using lbm_context_process_events() with operational_mode (context) set to `sequential`. You can now set the lbm_context_process_events() parameter '`msec`' to 0 (zero), which results in the UM context making one pass to process timers, sockets and then timers again before returning the thread to the application without any delay. (Previously, if you set the msec parameter to 10 and the UM context took 5 msecs to process all events, it would wait another 5 msecs before returning the thread to the application.)
7664	Ultra Messaging no longer sends a Topic Management Record (TMR) when an application deletes a receiver in a standard way with, for example lbm_rcv_delete(), when Dynamic Routers do not exist in the Topic Resolution domain. TMRs specifically inform a Dynamic Router that a receiver for a particular topic has been shutdown. (Without the presence of Dynamic Routers, TMRs become unnecessary network traffic.)
7551	Added SIGTERM to the list of signals that initiate clean shutdown of all Ultra Messaging daemons.
4785	Added the ability in the Java and .NET APIs to restrict receiver objects to a single LBMReceiverCallback with a new API: com::latencybusters::lbm::LBMReceiverAttributes::enableSingleReceiverCallback(). You can reduce latencies and increase throughput by using a single callback which removes the need for any synchronization of multiple callbacks within UM during message delivery.
7752	The Java API now supports Java version 1.7.

New Transport LBT-SMX <-

The LBT-SMX (shared memory acceleration) transport is an Interprocess Communication (IPC) transport you can use for the lowest latency message streaming. LBT-SMX is faster, though more-restrictive than the LBT-IPC transport. Like LBT-IPC, sources can publish topic messages to a shared memory area from which receivers can read topic messages. Unlike LBT-IPC, the native APIs for the LBT-SMX transport are not thread safe and do not support all UM features such as message batching or fragmentation.

You can use either the native LBT-SMX API calls, lbm_src_buff_acquire() and lbm_src_buffs_complete() to send over LBT-SMX or you can use lbm_src_send_*() API calls. The existing send APIs are thread safe with SMX, but they incur a synchronization overhead and thus are slower than the native LBT-SMX API calls.

LBT-SMX operates on the 64-bit Solaris (X86), Linux (X86) and Windows platforms.

The example applications lbmlatping.* and lbmlatpong.* show how to use the native LBT-SMX API calls. All three APIs (C API, Java API, and .NET API) have identically named example applications. Other example applications can use the LBT-SMX transport with the use of a UM configuration file containing source transport lbtsmx. You cannot use LBT-SMX with example applications for features not supported by LBT-SMX, such as lbmreq.*, lbmresp.*, lbmrcvq.* or lbmwrcvq.*.

The LBT-SMX configuration options are similar to the LBT-IPC transport options. See Transport Transport LBT-SMX Operation Options.

You can use Automatic Monitoring, UM API retrieve/reset calls, and LBMMON APIs to access LBT-SMX source and receiver transport statistics. To increase performance, the LBT-SMX transport does not collect statistics by default. Set the UM configuration option transport_lbtsmx_message_statistics_enabled (context) to 1 to enable the collection of transport statistics.

Persistence Enhancements for 6.1 <-

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

None.

Queuing Enhancements for 6.1 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionalty is retained.

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

None.

Dynamic Router Enhancements for 6.1 <-

The following new features and enhancements apply to the Dynamic Routing Option (DRO).

None.

Fixed Problems and Limitations for 6.1 <-

Streaming Fixed Problems and Limitations for 6.1 <-

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

Change Request	Description
7656	Fixed a problem with lbm_set_umm_info() that caused it to always return 0 (success). The function now returns -1 on a parsing error of a returned UMM configuration file, UMM Daemon login error or a communications error with the UMM Daemon.

Persistence Fixed Problems and Limitations for 6.1 <-

The following bug fixes apply to UMP and UMQ products.

Change Request	Description
7606	When a receiver tries to register with a store using a RegID in use by another receiver, the application error log message now includes the RegID: `UME registration error: error in UME registration, RegID 1508542809 is in use by a different receiver at store 0` Previously the message always displayed RegID 0 and no store number.
7604 7666	When a source tries to register with a store using a RegID in use by another source, the application error log message now includes the RegID, store number and the store's IP address and port: `Error registering source with UME store: error in UME registration, RegID 2323214065 is in use by a different source at store 1 192.168.101.130.21112` Previously the message always displayed RegID 0 and no store information.
7543	Corrected a problem with UMP stores that resulted in stability acknowledgements sent from a persistent store to the source during a store proxy source election contained invalid topic and transport indexes. As a result, the source discarded the stability acknowledgements.
7658	The umestored Web Monitor has been changed to correctly display the Request Receive Rate, Service Rate and Drop Rate. Previously the rates only showed activity for the last second instead of a true activity per second rate. As a result the rates often displayed 0 (zero). A link has been added to the Persistent Store Page to reset the rate calculation. The rates can be reset on a per store basis.
7262	When a store receives a retransmission request from an unknown source, the error log message now includes the IP address and port number of the unknown source: `Core-5688-696: received retransmit request for unknown source 192.168. 101.112:45512`

Queuing Fixed Problems and Limitations for 6.1 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionalty is retained.

The following bug fixes apply to the UMQ product.

Change Request	Description
7545	Corrected an issue that prevented a UMQ receiver for a dead letter topic from registering with a queue if any queue instance did not have a record of the creation of the dead letter topic.

Dynamic Router Fixed Problems and Limitations for 6.1 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

UM Version 6.0 <-

The most significant update to UM version 6.0 is the introduction of the Dynamic Routing Option (DRO). The DRO component fully replaces the "Gateway" component, which is discontinued as of UM 6.0. See the Dynamic Routing Guide for full information.

Warning: UM version 6.0 does not interoperate reliably with any previous version of UM. It was not until UM version 6.7 and beyond that interoperability was introduced between the 6.x version line and the 5.x version line.

Enhancements for 6.0 <-

Streaming Enhancements for 6.0 <-

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

The receiver configuration options retransmit_request_generation_interval (receiver) and otr_request_duration (receiver) have been deprecated. Late join and OTR now track a total duration for each message that begins when a receiver sends the first retransmission request for the message. See retransmit_request_message_timeout (receiver).
Linux platforms now automatically produce a backtrace listing to the log file upon encountering a fatal assertion.
Added the following configuration options to help control receiver start-up traffic:
Network Address Translation with the Unicast Resolver Daemon (lbmrd) using LBT-RU with Session IDs is now enabled. Previously this combination only worked with Session IDs disabled.
The context setting network_compatibility_mode (context) has been disabled. Specifying it does not cause an error, but it will be ignored.
Added TCP Session IDs to prevent the use of outdated data in the Topic Resolution Cache. You enable session ids for TCP with the configuration option transport_tcp_use_session_id (source).
Removed a fatal assert that was produced if a message was delivered from a TSNI request.
The Off-Transport Recovery (OTR) feature has been updated to include a new option otr_message_caching_threshold (receiver) and to use option retransmit_message_caching_proximity (receiver), both of which provide ways to control receiver buffer growth and otherwise premature unrecoverable loss declarations. Also, option otr_request_duration (receiver) is deprecated and replaced with the new option otr_request_message_timeout (receiver).
The Late Join option retransmit_request_generation_interval is deprecated and replaced with new option retransmit_request_message_timeout (receiver). The new option defines an RX give-up interval on a per-message basis.

Persistence Enhancements for 6.0 <-

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

Proactive Retransmissions - This feature address two types of loss:
- Loss of message data between the source and a store.
- Loss of stability acknowledgments (ACK) between the store and the source.
See Proactive Retransmissions in Chapter 8 of the UM Guide for Persistence. This feature also resolves the Known Issue: "UMP stores sometimes fail to send message stability acknowledgements to sources for messages sent while the store was being reported unresponsive by the source."
The persistence registration process has been improved for greater reliability, efficiency and to better inform receivers of store registration changes. Persistence now sends store registration information over the transport and not via Topic Resolution advertisements. Several new configuration options have been added to tune registration latency/bandwidth usage.
Added the following configuration options to help control receiver start-up traffic.
- ume_sri_request_interval (receiver)
- ume_sri_request_maximum (receiver)
The ume_store (source) configuration option now accepts an optional DomainID parameter.
Made context name resolution more efficient. Several new UM configuration options have been added to tune context name resolution. Context name resolution now has the potential to quiesce over time. New log messages have been added to facilitate duplicate context name detection. For more information, see:
- Store (context) Name Resolution
- Identifying Persistent Stores
The store option retransmission-request-forwarding is now interpreted differently. If enabled (value = 1), the store forwards retransmission requests to sources (if and only if it does not have the data). If disabled (value = 0), the store never forwards requests to sources.
Enhanced the proxy source election process in the following ways:
- Proxy source elections can now occur among stores located in different topic resolution domains when using the DRO.
- The election now occurs as part of the registration process instead of over the topic resolution channel, so it is more bandwidth efficient.
- The election process no longer restarts in the event of a tie, so it will always complete in a deterministic amount of time.
This update also resolves the Known Issue: "Persistence proxy source elections can only occur among stores in the same topic resolution domain connected directly via peer links."
The persistent store no longer logs Beginning of Session (BOS) and End of Session (EOS) events.
When a store restarts, the store now renames and stores state and cache files that are thought to be corrupted instead of deleting them. These files will be renamed from '<regid>-<state/cache>' to <regid>-<state/cache>.<pid>.<month_day_year>. Persistent stores the files in the same cache/state directories as specified in the store's configuration file.
A rare error case that occurred when handling a keepalive at the persistent store now logs a warning instead of fatal assert.
Changed the Persistent Store (umestored) to ignore UM Spectrum configuration options which results in the delivery of all messages to the store without any filtering. See Spectrum.

Queuing Enhancements for 6.0 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionalty is retained.

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

Added support in Ultra Messaging JMS for store names in the JMSConfig.xml so that UM JMS can be configured to work with the DRO for UMS/UMP functionality.
Wildcard topics can now be created programmatically in Ultra Messaging JMS. Use '<FactoryAttributes>' in either a UM Configuration File or the JMSConfig.xml file support this new feature.
- wildcards_enabled
- wildcard_type
- wildcard_enterprise_mode - Provides compatibility with other JMS vendors. If the topic name contains "*" or ">", UM JMS creates a PCRE wildcard topic pattern. For example, the topic 'PRICE.STOCK.*.IBM' creates a wildcard receiver with a topic pattern of '^PRICE\.STOCK\.[^/]+\.IBM$'.
- wildcard_um_values - If the topic name contains any of the characters:
  [ \ ^ $ . | ? + ( ) { } *
  UM JMS creates a PCRE wildcard topic pattern.
- The option 'wildcard_enterprise_wildcard_delimiter' supports any character as a delimiter except:
  [ \ ^ $ . | ? + ( ) { } *
Changed the "wait for source registration" Ultra Messaging JMS functionality to apply to send calls rather than source creation. The two relevant config options (wait_for_source_registration and SOURCE_REGISTRATION_TIMEOUT) are no longer considered during source creation but instead cause a producer to (optionally) have a send call block until source registration occurs. This change removes the need for the producer to explicitly handle the "not registered" exception that would otherwise be thrown and need to be handled by the application. The existing Ultra Messaging JMS configuration option 'SOURCE_CREATION_DELAY' has not been changed.
The UM JMS source code examples have been moved out of the '<platform>/jmsclient/bin' directory and up to the '<platform>/example' directory.
Changed the store names in the JMS config.xml file from uJMSStore1, uJMSStore2 and uJMSStore3 to JMSStore1, JMSStore2 and JMSStore3. Also renamed the Queue from uJMSQueue to JMSQueue.

Dynamic Router Enhancements for 6.0 <-

UM 6.0 is the first version which offers the Dynamic Routing Option (DRO). See the Dynamic Routing Guide for full information.

Fixed Problems and Limitations for 6.0 <-

Streaming Fixed Problems and Limitations for 6.0 <-

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

Corrected a problem with UM rate controls that resulted in rate limits being applied unequally among more than one transport session. Limits are now applied equally to all active transport sessions.
Changed the implementation of the default value for mim_sqn_window_increment (context) to match the documented value of 8192, which is the recommended default.
Corrected a problem with plain text (non-XML) UM configuration files greater than 1024 bytes that when loaded via a URL (http or FTP) would result in line malformed errors. This fix resolves the Known Issue: "Retrieving plain text (not XML) configurations files via an http or FTP request is limited to configuration files of 1K in size..."
Fixed a problem on Microsoft Windows where an interface could be incorrectly chosen internally as the default interface even though its operational status was not "up".
Corrected an invalid single-byte memory write that could occur if passing in a named interface setting into any of the *_interface configuration options.
Corrected calls to socket 'recv/recvfrom' that were not correctly handling EWOULDBLOCK/EAGAIN errors. This has been resolved.
The following Known Issue was resolved in UM 5.3.1 but mistakenly omitted from the list of Bug Fixes: "The .NET API does not support message selectors with Unicode symbols and causes receiver creation to fail."
Fixed a problem that could cause a crash while binding TCP ports.
Fixed a '[msg==NULL]' fatal assert that could occur if an application received a response to a Late Join Information request that contained a message, and not Late Join Information.
Corrected an issue with an event queue that could contain events, but never be dispatched. This issue could occur only on the AIX and NonStop platforms.
Corrected a problem with receivers that produced Unrecoverable Loss if UM delivered a TSNI to the receiver during Late Join recovery.

Persistence Fixed Problems and Limitations for 6.0 <-

The following bug fixes apply to UMP and UMQ products.

Fixed a problem that logs a keep alive sent from a store during UMP source de-registration as an error. This event no longer logs an error in the store log file.
Fixed a condition that could cause sources with high retransmit_request_size_threshold/limit settings to experience high CPU usage when a store daemon (umestored) was restarted.
Fixed a problem that could cause a crash if a source tried to de-register from a store with which it had never registered or whose context name had not been resolved.
Fixed the incorrect retention of the receiver-specified ume_activity_timeout (source) and ume_state_lifetime (receiver) values across store restarts. The receiver-activity-timeout configured in the stores' XML configuration file was used instead and the receiver-state-lifetime was ignored. Stores now correctly save receivers' configured activity timeout and state lifetime and use the saved values upon store restart.
Resolved the Known Issue: "The UMP store daemon, umestored, stops persisting messages to disk if the store has a loss condition which is not resolved prior to an EOS event..."
Corrected a problem that caused segfaults during long running store recoveries by delaying the store's check of sources if the store has not yet finished initializing.
Fixed an issue that occurred if the store index was uninitialized when a de-registration success event was delivered.
Fixed a bug that could prevent a receiver from successfully deregistering from a store.
Corrected a problem that prevented receivers from declaring completed deregistration although the receiver successfully deregistered from all the stores with which it was registered. Now a receiver declares completed deregistration as soon as it receives deregistration success from all the stores with which it was registered.
Corrected a number of problems with UMP Proxy Source Elections that resulted in numerous failed assertion warnings and the continuous creation and duplication of proxy sources.
Corrected a problem with source re-registration to a store that caused the store to incorrectly log warning messages such as, "Core-5688-1881: handle events returned error 4" and "CoreApi-5480-28: could not insert rcvdc_loss_rec ASL map."
Corrected a problem with the persistent store operating in RPP mode that caused a fatal assert if the store restarted with a prematurely ending cache file.
Corrected a problem that caused a store to perpetually send TSNI requests to a source at the configured retransmit_request_interval (receiver), even after live data was seen on the transport.
Fixed a problem with sending large messages using message properties that could cause a crash due to message reclaim source events.
Corrected a problem with the umestored daemon that resulted in the premature deletion of source state information if umestored was restarted. If the source had an active receiver before umestored was shut down, the configured source-state-lifetime was not restored, so the default lifetime of 0 seconds and default source-activity-timeout of 30 seconds was enforced.

Queuing Fixed Problems and Limitations for 6.0 <-

Note: The brokered queuing and UM JMS functionalities were replaced in version 6.8, so most of these notes do not apply to more-recent versions of UM. However, ULB functionalty is retained.

The following bug fixes apply to the UMQ product.

Corrected a problem with UM JMS that caused a JMSExcpetion when using lower case variants of the 'ConnectionFactory' attributes receiver_creation_delay, 'source_creation_delay', and source_registration_timeout in a config.xml file. You can now enter these ConnectionFactory attributes in lower case.
Resolved a problem in UM JMS that caused an exception and a loss of messages from a queue when restarting a receiver. Messages unacknowledged by a receiver that shuts down are now put back onto the queue. These messages are available for resending to the receiver when it restarts.
Fixed a problem with the UMQ daemon (umestored) that could lead to a crash if you kept queue browsing support enabled (default) and multiple queue instances are rapidly killed and restarted in sequence. The crash would only potentially occur if log messages appeared in the umestored log file indicating that a message "was already present in SINC msg list".
Fixed a rare bug that could lead to a crash in the UMQ daemon (umestored) when configured to use a disk and many sending threads, which is not the default.

Dynamic Router Fixed Problems and Limitations for 6.0 <-

The following bug fixes apply to the Dynamic Routing Option (DRO).

None.

Deprecations <-

To make UM more maintainable, functionality is sometimes removed from UM. Informatica understands that this can be disruptive to users, so we try to restrict such deprecations to features that, to our knowledge, are not needed by our users. Typically the depreciation is announced prior to the functionality being removed to give users time to replace the deprecated functionality with the recommended replacement.

Informatica recommends careful reading of each version's release notes to learn which features are being deprecated. If you are upgrading across multiple versions of UM, the deprecations for all intervening versions should be examined.

If you discover that a feature is deprecated which is important to your use case, please contact Informatica Support.

Deprecations for 6.16 <-

32-bit. Support for 32-bit applications and daemons is dropped. See Eliminate 32-bit.

Deprecations for 6.15 <-

UN-DEPRECATED: Store Groups. UM version 6.13 announced the deprecation of Store Groups. This decision has been reversed. Store groups will continue to be fully supported into the future.
REMOVED: "Reduced FD" Store. In UM version 6.13.1, we announced deprecation of the "Reduced FD" Store. In version 6.15 the reduced FD functionality has been removed from the Store. This included the removal of the LevelDB database code from the Store.
DEPRECATED: Daemon Monitoring Formats. The binary daemon monitoring formats for the Store and DRO are deprecated. The JSON daemon monitoring format for the SRS is deprecated.

We currently do not plan to remove these deprecated formats, but new monitoring features will not be added to them.

Informatica recommends transitioning to the "protocol buffer" format for Store, DRO, and SRS. See Monitoring Formats.

Deprecations for 6.14 <-

DEPRECATED: "HFX" feature. This is a heavier-weight version of Hot Failover in which multiple contexts are used to receive the duplicated data streams. This provides greater flexibility on selecting different network interfaces to carry the data.

The feature turned out not to be of interest to our customers. If you use this feature, please contact Informatica Support.

See Hot Failover Across Multiple Contexts (HFX).
DEPRECATED: Enabling daemon statistics on Store and DRO using "<daemon-monitor>". The C-style binary structures format of Store and DRO daemon statistics are enabled with the "<daemon-monitor>" element.

Informatica requests users to migrate to using the UM configuration file to enable automatic monitoring with Protocol Buffer monitoring format for Store and DRO by setting monitor_format (context) to "pb".

See Monitoring UM Daemons.
DEPRECATED: Monitoring Format CSV. Prior to UM version 6.14, the only monitoring formatter available was CSV (comma-separated values).

Starting in UM 6.14, CSV is deprecated in favor of proto buffs. We do not plan to remove existing CSV functionality, and we will continue to support it in its current state. But we do not plan to enhance CSV in the future.

To take advantage of new monitoring capabilities, Informatica requests that users migrate to proto buffs.

See Monitoring Formats.
DEPRECATED: Monitoring transports UDP and SNMP.

Starting in UM 6.14, monitoring transports UDP and SNMP are deprecated in favor of LBM. We do not plan to remove existing UDP or SNMP functionality, and will continue to support them in their current states. But we do not plan to enhance UDP or SNMP in the future.

To take advantage of new monitoring capabilities, Informatica requests that users migrate to the LBM transport.
DEPRECATED: SNMP Monitoring Agent.

Starting in UM 6.14, the SNMP Monitoring Agent is deprecated in favor of MCS. We do not plan to remove existing SNMP agent functionality, and will continue to support it in its current state. But we do not plan to enhance the SNMP agent in the future.

To take advantage of new monitoring capabilities, Informatica requests that users migrate to Monitoring Collector Service (MCS).
DEPRECATED: Store web monitor.

Starting in UM 6.14, the Store Web Monitor is deprecated in favor of MCS. We do not plan to remove existing web monitor functionality, and will continue to support it in its current state. But we do not plan to enhance the web monitor in the future.

To take advantage of new monitoring capabilities, Informatica requests that users migrate to Monitoring Collector Service (MCS).
DEPRECATED: DRO web monitor.

Starting in UM 6.14, the DRO Web Monitor is deprecated in favor of MCS. We do not plan to remove existing web monitor functionality, and will continue to support it in its current state. But we do not plan to enhance the web monitor in the future.

To take advantage of new monitoring capabilities, Informatica requests that users migrate to Monitoring Collector Service (MCS).

Deprecations for 6.13.1 <-

DEPRECATED: "Datagram Acceleration" feature. This is a little-known (barely documented) experimental feature offered to a few customers. The feature turned out not to be of interest to our customers. See datagram_acceleration_functions (context).

Deprecations for 6.13 <-

DEPRECATED: "Reduced FD" Stores. The Store configuration option repository-type of "reduced-fd" is now deprecated, and will be removed from a future UM version. Users of "reduced-fd" are advised to contact Informatica Support for advice on migrating to repository type "disk".
NOT DEPRECATED: Store Groups. UM version 6.13 included a deprecation announcement of multiple Q/C groups. This feature was un-deprecated in 6.15 and will be fully supported in future releases. (At no time was the functionality removed or disabled.)
DEPRECATED: "No Cache" Stores. The Store configuration option repository-type of "no-cache" is now deprecated, and will be removed from a future UM version. Users of "no-cache" are advised to contact Informatica Support for advice on migrating to repository type "disk".
DEPRECATED: Arrival Order Delivery, No Reassembly Deprecation. The Arrival Order, Fragments Not Reassembled feature (ordered_delivery 0) is still operational but may be removed in a future release.

Users are advised to use Arrival Order, Fragments Reassembled (ordered_delivery -1) instead.
DEPRECATED: Application Headers Deprecation. The Application Headers feature is still operational but may be removed in a future release.

Users are advised to use Message Properties instead.
DEPRECATED: UM configuration attribute "application_data" and the corresponding <application-data> XML configuration element. This feature was never fully implemented, and it is now formally deprecated and may be removed in a future release.

Platform Deprecations for Daemons <-

As of UM version 6.16, no 32-bit components are supported. See Eliminate 32-bit.

As of UM version 6.13, there is a reduction in supported platforms for UM daemons.

The UM daemons are:

Starting with UM version 6.13, the daemons will only be supported on the following platforms:

Daemon	Linux 64	Windows 64	Windows 32
Persistent Store (stored)	YES	YES	no
DRO - Dynamic Routing Option (tnwgd)	YES	YES	YES
Unicast Resolver Daemon (lbmrd)	YES	YES	no
SRS - Stateful Resolution Service	YES	YES	no
UMM Ultra Messaging Manager (ummd)	YES	YES	no
ActiveMQ broker	YES	YES	no
UMDS Server (umdsd)	YES	no	no

Platforms not mentioned in the above table are not supported for the UM daemon components, including 32-bit Linux, Solaris, AIX, Darwin (MacOS) IBM Power CPUs.

Note that there is no change in support for applications. UM daemons running on the reduced set of platforms will be able to service applications running on the full range of supported platforms.

Deprecations for 6.11.1 <-

Attention: The original 6.11.1 release notes announced the deprecation of certain platforms for UM daemons, claiming that they would be discontinued in UM version 6.12. However, some users requested more time for the transition. As of UM version 6.12, these deprecated daemon platforms have not yet been removed, and are therefore still fully supported in 6.12. Starting with UM version 6.13, the UM daemons will no longer be available on certain platforms. See Platform Deprecations for Daemons.

Note: User applications will continue to be fully supported on all platforms. These deprecations only apply to UM daemon executables, such as the Store Daemon and the Dynamic Router daemon.

UM daemons will continue to be available on the following platforms:

Persistent Store daemon ("stored"): Linux 64-bit, Windows 64-bit.
UM Dynamic Router daemon ("tnwgd"): Linux 64-bit, Windows 64 and 32-bit.
UM Manager daemon ("ummd"): Linux 64-bit, Windows 64-bit.
UM Resolution daemon ("lbmrd"): Linux 64-bit, Windows 64-bit.
UM Queue Broker (ActiveMQ): Linux 64-bit, Windows 64-bit.

The planned deprecated daemon platforms are:

Solaris (X86 and Sparc)
AIX
Darwin (MacOS)
Linux 32-bit
Windows 32-bit (except Dynamic Router "tnwgd", which will continue on 32-bit)

User applications deployed on these platforms will fully interoperate with daemons running on the reduced set of platforms.

Contact Informatica Support if any of these planned deprecations interfere with your existing or planned deployments.

Deprecations for 6.10 <-

Streaming Deprecations for 6.10 <-

DEPRECATED: Adaptive Batching. Adaptive batching is still operational, but planned to be removed in a future release.
DEPRECATED: Explicit Batching. Explicit Batching is still operational, but planned to be removed in a future release.
DEPRECATED: Hypertopics. HyperTopics is still operational, but planned to be removed in a future release.
DEPRECATED: TCP-LB. The "bounded_latency" selection for transport_tcp_multiple_receiver_behavior (source) is still operational, but planned to be removed in a future release.
DEPRECATED: RDMA transport. The "lbt-rdma" selection for transport (source) no longer functions. The underlying third-party library is no longer available from the vendor. Users should use UD Acceleration for Mellanox Hardware Interfaces.

Persistence Deprecations for 6.10 <-

Java APIs deprecated:
- DEPRECATED: UMEBlockSrc class
- DEPRECATED: LBMContext.setUMQInflight() method
- DEPRECATED: LBMContext.setUMQMessageStable() method

Dynamic Router Deprecations for 6.10 <-

DEPRECATED: Dual-TCP peer links. UM DRO version 6.10 no longer supports dual-TCP peer links. The XML configuration elements '<tcp>' and '<companion>' will generate errors. Upgrading customers should use <single-tcp> instead.

Deprecations for 6.8 <-

Persistence Deprecations for 6.8 <-

For Persistent Stores, the '<topic>' option type value 'regexp' is deprecated.
The Round-Robin store failover configuration, which was deprecated in UM 6.7, is now removed from Ultra Messaging 6.8 and is no longer available.

Queuing Deprecations for 6.8 <-

The following configuration options are deprecated and no longer function.

umq_flight_size (context)
umq_flight_size_behavior (context)
umq_msg_total_lifetime (context)
umq_message_retransmission_interval (context)
umq_message_stability_notification (context)
umq_queue_check_interval (context)
umq_queue_name (source)
umq_queue_participants_only (source)
umq_queue_query_interval (context)
umq_require_queue_authentication (context)
umq_retention_intergroup_stability_behavior (context)
umq_retention_intragroup_stability_behavior (context)
umq_retention_intergroup_stability_behavior (source)
umq_retention_intragroup_stability_behavior (source)

The following C API functions are deprecated and no longer function:

The following Java and .NET API functions are deprecated and no longer function:

UMEBlockSrc class
LBMContext.setUMQInflight() method
LBMContext.setUMQMessageStable() method

Dynamic Router Deprecations for 6.8 <-

The '<regex-pattern>' configuration option element is deprecated.

Deprecations for 6.7 <-

Streaming Deprecations for 6.7 <-

The lbmmon_attr_get_contextid() function is deprecated. Instead, use lbmmon_attr_get_objectid().

Persistence Deprecations for 6.7 <-

The Round-Robin Store failover configuration is deprecated.
The 'repository-disk-max-write-async-cbs' option is deprecated.

Deprecations for 6.5 <-

Streaming Deprecations for 6.5 <-

The Java send methods that accept a callback object (cbArg) are deprecated:
- send(byte[] message, int messageLength, int flags, java.lang.Object cbArg)
- send(java.nio.ByteBuffer message, int startPosition, int messageLength, int flags,java.lang.Object cbArg)
Use the send method that accepts an LBMSourceSendExInfo object instead.

Deprecations for 6.0 <-

Streaming Deprecations for 6.0 <-

The receiver configuration options retransmit_request_generation_interval (receiver) and otr_request_duration (receiver) have been deprecated. Late join and OTR now track a total duration for each message that begins when a receiver sends the first retransmission request for the message. See retransmit_request_message_timeout (receiver).
Option otr_request_duration (receiver) is deprecated and replaced with the new option otr_request_message_timeout (receiver).
The Late Join option retransmit_request_generation_interval is deprecated and replaced with new option retransmit_request_message_timeout (receiver). The new option defines an RX give-up interval on a per-message basis.

Deprecations for pre-6.0 <-

Deprecations for UM versions prior to 6.0.

Functions lbm_context_set_name() and lbm_context_get_name() are deprecated and no longer have any functionality. Use configuration option context_name (context) instead.
The constants LBM_SRC_EVENT_UME_REGISTRATION_SUCCESS, LBM_MSG_UME_REGISTRATION_SUCCESS, LBM_SRC_EVENT_UME_MESSAGE_STABLE, LBM_SRC_EVENT_UME_DELIVERY_CONFIRMATION, and the structures lbm_src_event_ume_registration_t, lbm_msg_ume_registration_t. are no longer used.

Applications must instead use LBM_SRC_EVENT_UME_REGISTRATION_SUCCESS_EX, LBM_MSG_UME_REGISTRATION_SUCCESS_EX, LBM_SRC_EVENT_UME_MESSAGE_STABLE_EX, LBM_SRC_EVENT_UME_DELIVERY_CONFIRMATION_EX, and the structures lbm_src_event_ume_registration_ex_t, lbm_msg_ume_registration_ex_t, lbm_src_event_ume_ack_ex_info_t.

For other deprecations made in pre-6.0 versions of UM, see the Change Log document the UM version 5.3.6 Documentation Set.

Known Problems and Limitations <-

Streaming Known Problems and Limitations <-

The following open limitations apply to UMS, UMP, and UMQ products.

Change Request	Description
11327	When a subscriber joins an IPC source, the IPC thread can fail to initialize properly, resulting in receiver "deafness" to IPC sources. One symptom of this is "rolling EOS events" (repeated LBM_MSG_EOS receiver events without any LBM_MSG_BOS events and without any message reception). WORKAROUND: use IPC Sequential Mode (not available for Java or .NET).
11268	The Store operational tool "umedcmd" cannot be used on a Store that is configured for protobuf-based daemon monitoring.
11266	The "lbmmon.c" and "lbmmon.java" example applications do not support the SRS protobuf-based stats. (Note that the MCS does support them.)
10985	Request to add a configurable maximum number of TSNIs per datagram. For users of kernel bypass drivers who set their datagram max size above a network MTU, this can lead to undesirable IP fragmentation when a TSNI uses most of the configured max datagram size. At this time, this request is not planned to be implemented. Instead, the Dynamic Fragmentation Reduction feature should be used to avoid IP fragmentation.
11038	A low-traffic topic that transitions across a DRO can produce a series of "EOS" events on a receiver. This happens when the receiver is created after the source's TSNIs become inactive (60 seconds by default; see transport_topic_sequence_number_info_active_threshold (source)). Creation of the receiver triggers the creation of a proxy source on the DRO's portal. But in the absence of either user messages or TSNIs, the proxy source never starts sending session messages, resulting in the receiver timing out and re-creating the transport session. WORKAROUND: Set transport_topic_sequence_number_info_active_threshold (source) to zero for the source that is causing the problem. This causes TSNIs to be sent in the absence of user data for unlimited time.
11036	Request to officially support .NET Core on Windows. At the present time, UM's .NET Core implementation has only been tested on Linux.
11018	When TLS encryption is used, the OpenSSL package will attempt to open some files with paths that correspond to where the package was originally built. For example, you might see OpenSSL attempt to open the file: /home/ssawalski/openssl-p/Linux-glibc-2.5-x86_64/cert.pem. Note: as of UM version 6.12.1, only users of the TLS encryption features will see this happen. See OpenSSL Dependency.
10937	In UM version 6.13, the lbmrd default interface stopped working properly. The default interface is defined to be "0.0.0.0", (INADDR_ANY). In UM versions prior to 6.13, this binding allowed lbmrd to accept TR packets on any host interface. In UM 6.13 the behavior changed to being an interface matching specification, which caused UM to select and bind to the first interface it finds, which is typically 127.0.0.1 (localhost). This rejects TR packets from remote hosts. WORKAROUND: an interface matching specification must be provided, either via the command-line using the "-i" option (see Lbmrd Man Page), or via the "<interface>" XML configuration element (see LBMRD Element "<interface>"). Note that an easy and flexible method for specifying the interface is using CIDR notation, such as "10.0.0.0/8". This matches any interface whose IP address starts with 10. See Add LBMRD Interface.
10933	In UM version 6.5, the data structure lbm_context_stats_t grew in size. This means that applications compiled with UM versions prior to UM 6.5 but executed with a UM version 6.5 or beyond do not allocate enough space for that structure when calling lbm_context_retrieve_stats(). This can lead to unpredictable behavior. SOLUTION: any application compiled with UM versions prior to UM 6.5 must be recompiled prior to being used with a UM version 6.5 or beyond. See Upgrade Procedure.
10833	Running 6.13 or beyond applications with pre-6.13 DRO can lead to DRO logging: `Core-5688-516: LBMC cntl unknown next header 1f, ignoring header.` No incorrect behavior results, and the log message can be ignored. This happens because starting with UM 6.13, persistent receivers can request "ranged recovery" from a Persistent Store, but pre-6.13 DROs do not understand the new control message. SOLUTION: follow the recommended Order of Upgrades.
10897	The Windows version of the umedcmd command does not process registration IDs greater than 2147483647. This is because the program uses "atoi()", which does not define behavior for out-of-range values. WORKAROUND 1: Modify umedcmd.c to use atoll() and rebuild. WORKAROUND 2: Use the Linux executable. Although it is not guaranteed, glibc will internally overflow the conversion in such a way as to produce the correct 32-bit unsigned value.
10772	Starting with UM version 6.10, the UM library built for Darwin (MacOS) no longer supports fd_management_type (context) of "kqueue".
10498	Security Vulnerability: the Persistent Store web monitor function can be used to read arbitrary files on the host running the Store daemon. Note that even when this issue is resolved, the Persistent Store web monitor is not a secure system, and is not intended to be exposed to unauthorized users. In particular, the web monitor cannot be configured for authentication or encryption, including UM's own Encrypted TCP. Users are expected to prevent unauthorized access to the web monitor through normal firewalling methods (e.g. only allowing access to the port from specific remote IP addresses). Users who are unable to limit access to a level consistent with their overall security needs should disable the store web monitor. See Webmon Security for more information. Note The UM daemon designs are evolving away from simple web-based monitoring and towards a publish/subscribe model of distributing monitoring events and statistics.
10609	The DRO daemon statistics message type tnwg_portal_peer_dstat_record_t has 3 improper fields: remote_interest_topics, remote_interest_pcre_patterns, and remote_interest_regex_patterns. They are improper because those counts do not apply to a peer portal. In UM versions prior to 6.13, the tnwg_portal_peer_dstat_record_t messages can have uninitialized values in those fields. Workaround: a monitoring application should ignore those 3 fields. Note: to maintain backwards compatibility, Informatica does not plan to remove these fields from the data structure. As of UM version 6.13, these fields are set to zero (instead of possibly being uninitialized).
10136	When an XML file is used to configure UM, an invalid configuration option or value logs appropriate error messages, but does not return failure status to the application. As a workaround, the application logger callback can check for logged messages that start with "Core-5626-" and trigger their own error handler. Note that setting up the logger callback has a clientd (see lbm_log()), so a shared structure can be established for the logger callback to communicate any matches it finds to the application thread calling lbm_config().
9964	The use of Doxygen to generate the .NET documentation has resulted in the omission of the "LBMCS.chm" windows help package.
9718	The encryption feature does not implement elliptic curve encryption. Cipher suites with "ECDH", "ECDHE", and "ECDSA" cannot be used. Use "DHE" and "RSA" instead.
4126	When using LBT-IPC transports, 64-bit applications cannot interoperate with 32-bit applications. This includes router endpoint portals.
6553, 6441	You cannot use Unicode PCRE characters in wildcard receiver patterns on any system that communicates with a HP-UX or AIX system.
6828, 6830, 6831	There are severe restrictions on the use of NAT with UM. Normally, a DRO should be used with peer links to transit a NAT. However, there are very restrictive scenarios where Unicast Topic Resolution with `lbmrd` can be used to establish direct communication across a NAT. See Network Address Translation (NAT).
7762	When using Event Queues with the Java API on Mac OS X kernel 9.4, core dumps have occurred. Mac OS X kernel versions before 9.4 have not produced this behavior.
7992, 7984, 7990	The LBT-SMX transport does not support Topic Sequence Number Information (TSNI) messages. Thus, if LBT-SMX traffic routes through one or more DROs, and the original LBT-SMX source does not send messages regularly, remote receivers do not detect and notify the application of topic- level tail loss. Also, UM might not deliver midstream topic-level loss notifications in a timely manner. Remote receivers may also experience repeated transport disconnects and reconnects, and may miss Beginning Of Session (BOS) messages for the remote transport that carries data from the originating SMX source. Remote receivers may also experience head loss, similar to what would occur if the remote DRO had started after the originating SMX source starts sending. When configuring SMX sources to send through a DRO, ensure receiving applications do not rely upon these missing TSNI-related behaviors.
8042	It is possible for a thread deadlock to occur in the Java HotSpot Virtual Machine when initializing direct byte buffers. To avoid this bug, upgrade to Java 1.6.0_18 or later. For more information see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6791815.
8266	With Ultra Messaging on the AIX platform, you might encounter library linking problems due to an older version of '`libcrypto.a`' in the Ultra Messaging core package. To avoid this, set the LIBPATH in such a way that it takes the system libcrypto.a ahead of the Ultra Messaging '`libcrypto.a`'.
8727, 8603	You cannot use lbm_rcv_retrieve_transport_stats() to retrieve transport statistics from receivers with SMX sources. Instead, to retrieve these statistics use Automatic Monitoring.
8735, 8323	In AIX systems, you cannot send messages with a zero-length payload.
8744	If the lbmrd configuration file does not specify the version attribute within the '`<lbmrd>`' element, the daemon quits immediately without an error message. To resolve this issue, change the '`<lbmrd>`' element to '`<lbmrd version="1.0">`'.
8794, 8475	Configuring sources with LBT-RU, source-side filtering, and adaptive batching might cause a crash. Note that adaptive batching is deprecated and will be removed from a future release.
8820, 7368	Setting transport_tcp_activity_method (receiver) to '`SO_KEEPALIVE`' without setting transport_tcp_activity_timeout (receiver) to a value other than the default value of 0 causes a receiver create fatal assert: '`s_entry->topic.rcv!=NULL`'. Also, any other configuration that causes a receiver create to fail triggers the fatal assert: '`s_entry->topic.rcv!=NULL`'.
9030, 8799	You cannot set transport options in-line for lbmmon using a UM XML configuration file. Instead, use a Plain Text configuration file to set these options.

Persistence Known Problems and Limitations <-

The following open limitations apply to UMP and UMQ products.

Change Request	Description
11328	The persistent source event LBM_SRC_EVENT_FLIGHT_SIZE_NOTIFICATION can deliver notifications out of order. This behavior is not considered a bug; applications must handle this. See Source Flight Notification Event for details and suggestions.
11006	Store can misbehave if a UM XML configuration file is supplied with settings that are invalid for the Store. Request that either the invalid settings be automatically corrected, or at least log a user-friendly error message. WORKAROUND: Take care to omit the following options from the Store's LBM configuration: ordered_delivery (receiver) umq_queue_participation (receiver) use_late_join (receiver) null_channel_behavior (receiver) unrecognized_channel_behavior (receiver)
9337	It is requested that UM support running multiple instances of the Store as a Windows service on one host. Currently, service parameters are stored in the registry as fixed names, which prevents multiple instances from having different configuration files, CPU affinity, etc.
10504	When an LBM configuration file in XML format is used to set options based on topic name, those settings are not applied when a wildcard receiver matches a source with that topic name. For example, given: <topic topicname="abc"> <options type="receiver"> <option name="transport_lbtrm_send_naks" default-value="0"/> </options> </topic> If a wildcard receiver is created with pattern "ab.*", the above option will not be set on the underlying UM receiver.
10676	When a Store experiences packet loss (typically due to overload), it can delay or block the sending of stability ACKs to the Source until the loss is repaired or declared unrecoverable. Note: this issue was mistakenly listed as "fixed" when UM version 6.13 was released.
10984	In UM version 6.12 and beyond, a subscribing application that enables both XSP and Persistence has a small chance of encountering a crash during the Store registration process.
10171	A set of default operational configuration options do not satisfy Persistence recommendations. Hung registrations can result. Persistence users are advised to follow the recommendations in Preventing Store Registration Hangs.
2982	Receivers using event queues and Spectrum with UMP can experience a SIGSEGV while shutting down if events still exist on the event queue when the application deletes the event queue. As a workaround, use LBM_EVQ_BLOCK when dispatching event queues. During application shutdown, call lbm_evq_unblock() after deleting receivers associated with the event queue, but before deleting any context objects. When the dispatch thread exits, you can continue with context deletion.
4543	When running a store on a Solaris machine, you may experience registration failures after a few minutes. The store repeatedly reports the error: `[WARNING]: wait returned error 4 [select: (22) Invalid argument]` Setting fd_management_type (context) to '`devpoll`' prevents this problem.
4667	Multi-transport Threads (MTT) do not support Persistence. Note that as of UM 6.11 MTT is removed, replaced by the new XSP feature, which provides improved multi-threading for receivers, and is compatible with Persistence. See Transport Services Provider (XSP).
5841	A UMP store daemon, umestored, may shut down unexpectedly if you enable proxy sources and UM is not able to create a transport session for a needed proxy source. For example, if the store is configured to use TCP transports for proxy sources (the default), and transport_tcp_port_high (context) minus transport_tcp_port_low (context) is 8, then when the 9th proxy source is created, UM will be unable to assign a port for that transport session. This is because UM will attempt to create up to transport_tcp_maximum_ports (context) transport sessions, which defaults to 10. transport_tcp_port_high (context) minus transport_tcp_port_low (context) must be at least transport_tcp_maximum_ports (context), and may need to be even larger if other applications and/or daemons on the same machines are configured to use ports from the same range. Informatica recommends configuring large port ranges appropriate to the transport type.
6843	An overly aggressive configuration on the source can cause the source to declare the store unresponsive while the source processes stability acknowledgements or confirmed delivery notifications or both. Using "strong RegIDs" prevents the source from sending messages until the store's source-activity-timeout expires on the store. After the activity timeout expires, the source can reregister.
7014, 6840	Java applications that create multiple receivers for the same topic in the same context may shut down unexpectedly when calling Dispose() if the topic is in a persistent data stream. Informatica recommends that you either avoid concurrent calls to Dispose() or use a single receiver for each topic and use application code to deliver messages to different callbacks.
7937, 7771	With liveness detection enabled for a UMP source and receiver; the receiver sends liveness keepalives to the source regardless of whether or not the receiver successfully registered with the Store.
8728, 8151	You cannot use receiver liveness detection for sources running on a SPARC-based system.
8755	For message consumption acknowledgements, you must not enable both acknowledgement batching and explicit acknowledgements simultaneously. However, if you do enable both, Ultra Messaging does not inhibit this configuration, and you see unexpected behavior.
8870, 8768	When using UMP with Windows, if you terminate a umestored process that was started from a command line window, it might corrupt data that is being written when the process is terminated. This does not apply to umestoreds, which runs as a service. To avoid this problem, ensure that sources are quiescent when stopping the Windows umestored process.

Queuing Known Problems and Limitations <-

The following open limitations apply to UMQ product.

Change Request	Description
11256	There are cases where three brokers are configured for High Availability Installation and two brokers are brought down and then brought back up, UM can fail to re-synchronize the brokers. A clean from-scratch restart of the brokers is necessary to recover.
9211	Option umq_queue_activity_timeout (context) has no effect.
9473, 9444	The default paging or "cursor" settings for ActiveMQ might cause poor performance when multiple JMS durable subscribers are added to the same destination. This might cause logs messages similar to the following display: `2014-11-05 17:19:17,205 \| WARN \| duplicate message from store ID:Server-45448-1415232622173-1:1:1:1:49, redirecting for dlq processing \| org.apache.activemq.broker.region.Topic \| ActiveMQ Transport: tcp:///10.0.0.1:45449@21868` You can improve performance by changing the cursor used by durable subscribers to a vm cursor. However, you then lose the ability in the broker to page messages from memory to disk as memory usage increases. To change to vm cursors for subscribers, update the activemq.xml config file as shown in the following example: `<policyEntry topic="\>" >` `...` `<pendingSubscriberPolicy>` `<vmCursor />` `</pendingSubscriberPolicy>` `<pendingDurableSubscriberPolicy>` `<vmDurableCursor/>` `</pendingDurableSubscriberPolicy>` `...` `</policyEntry>`
9474, 9446	If a broker restarts and is later elected as active, previously assigned messages might be reassigned to consumers without being marked as redelivered.

Dynamic Router Known Problems and Limitations <-

The following open limitations apply to the Dynamic Routing Option (DRO).

Change Request	Description
9718	The encryption feature does not implement elliptic curve encryption. Cipher suites with "ECDH", "ECDHE", and "ECDSA" cannot be used. Use "DHE" and "RSA" instead.
8736, 8082	When shutting down and restarting a DRO, the DRO sometimes does not complete its shutdown fully, requiring that it be forcible killed.
Restriction	You cannot configure two endpoint portals on a DRO to have the same adjacent domain id.
Restriction	You cannot configure two peer portals on a DRO to connect to the same adjacent DRO.
Restriction	The DRO ignores UM Spectrum configuration options, which results in DROs forwarding all channel data without applying any filtering. See Spectrum.

Upgrade Procedure <-

Most upgrades from one version to the next are straightforward and uneventful. This is because Informatica strives to introduce new features without affecting existing functionality.

However, users are strongly encouraged to read and understand the release notes for each intermediate version between their existing system and their intended upgrade target.

Order of Upgrades <-

Informatica makes every effort to support interoperability between different versions of UM. We understand the difficulty for users to upgrade every component and application at the same time. We also understand the infeasibility for users to upgrade to every new UM version that is released.

For users who upgrade gradually, a few components at a time, Informatica strongly recommends users upgrade UM Daemons first, followed by applications. (This ordering of upgrades does not apply to users who upgrade all components in a single step.)

The UM daemons are:

When upgrading to a new version, you should not have a newer application using an older UM daemon. (There is no particular recommended order among the daemon types.)

When upgrading Persistent Stores from a pre-6.13 version to UM 6.13 and beyond, Informatica recommends upgrading any DROs before the Persistent Stores. See bug 10833.

Users of the UMDS daemon (umdsd) should contact Informatica Support for advice on upgrading.

Rebuilding Applications <-

Informatica makes an effort to ensure compatibility of its ABI (Application Binary Interface). This allows applications to be upgraded by simply replacing the UM library, without having to recompile the applications. Unless otherwise noted in a UM version's special upgrade procedures, ABI compatibility is maintained across all minor versions of a given major version.

However, there are times that ABI compatibility must be broken to support new functionality. This happened with the introduction of UM version 6.5; certain applications that were built with UM version 6.0 and 6.1 need to be recompiled when upgrading to 6.5 and beyond. See UM 6.5 Context Stats Expansion.

Retesting Applications <-

Informatica has extensive automated regression test frameworks that generally do a good job of ensuring the quality of each new software version. However, no testing methodology can test all combinations of configurations across all possible use cases. So regressions are always possible.

The user has a responsibility to test his application system after upgrading to a new version of UM. The degree of testing depends on the amount of change that that UM has undergone between the old and new versions. For example, there are generally very few changes when upgrading from a version to an Emergency Bug Fix (EBF) of that version. So minimal re-testing is needed. The release notes can provide an idea of how much testing should be done after an upgrade. Contact Informatica Support for assistance in the analysis.

Special Upgrade Instructions <-

In addition to the general upgrade instructions above, there are version-specific special upgrade instructions associated with many versions. You may need to apply multiple of these special instructions depending on how many UM versions you are skipping as you upgrade. Here are the special instructions for UM versions 6.x:

Note that upgrading from versions prior to 6.0 requires special care. UM version 6.7 is the first 6.x version that is compatible with pre-6.0 versions, so the Special Upgrade Instructions for 6.7 must be followed.