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.
  • Order of upgrades.
  • 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.


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.

To ensure a smooth upgrade path, Informatica strongly recommends users upgrade UM Daemons first, followed by applications.

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 Known Limitation 10833.


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

  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.