Release Notes
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.

In particular, there are four areas that deserve special consideration:

  • Default values for configuration options.
  • Deprecations.
  • Upgrading brokered queuing and JMS applications to 6.8 or beyond from pre-6.8.
  • Upgrading to 6.0 or beyond from pre-6.0 versions.
Note
Important: If you are upgrading from Ultra Messaging Version 5.x or earlier, you must recompile and relink your applications to this version's libraries.


Default Values for Configuration Options  <-

While Informatica attempts to set configuration option defaults to values that represent good trade offs, there are times when new information or customer feedback demonstrates that a different value delivers more value for the average customer. In many cases, customers will benefit from these new values. However, it is also possible that for specific use cases, a previous default value is better.

Informatica recommends that users evaluate each changed default individually and determine if the new value is appropriate for their use cases. In those cases where the previous default is better, the user must explicitly set the option to that value.

Contact Informatica Support for more information and deeper understanding of UM's configuration options.


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.

Informatica recommends careful reading of each version's release notes to learn which features are being deprecated. If you discover that a feature is deprecated which is important to your use case, please contact Informatica Support.


Platform Deprecations for Daemons  <-

In a future version of UM, there will be a reduction in supported platform for UM daemons.

The UM daemons are:

  • Unicast Resolver Daemon (lbmrd)
  • Persistent Store (stored)
  • DRO - UM Router (tnwgd)
  • Stateful Resolution Service (SRS)
  • UMM Ultra Messaging Manager (ummd)
  • ActiveMQ broker

Starting with a future version of UM, the daemons will only be supported on the following platforms:

Daemon Linux 64 Windows 64 Windows 32
Unicast Resolver Daemon (lbmrd) YES YES no
Persistent Store (stored) YES YES no
DRO - UM Router (tnwgd) YES YES YES
SRS - Stateful Resolution Service YES YES no
UMM Ultra Messaging Manager (ummd) YES YES no
ActiveMQ broker YES YES no

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.


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.


Upgrading From Version Pre-6.0  <-

With the introduction of the UM Router, 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:

  1. If the current installation is earlier than 5.3, upgrade all applications and components except UMDS servers to version 5.3.6 or later.

  2. Pre-6.0 versions of UM are not ABI compatible with 6.0 and beyond. C language application programs must be re-compiled.

  3. 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'.

  4. Upgrade all lbmrd resolver daemons to this release. No configuration changes are required.

  5. 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.
  6. 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:

    These settings must remain during the period when the network contains both applications based on 5.3.x and this release.

  7. 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:

  8. After all components are upgraded to this release, set the following configuration options:


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.