Release Notes
|
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:
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.
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.
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.
See Queuing Upgrade Considerations for more information about upgrading brokered queuing applications.
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.
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.
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.
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.
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:
For 5.3.x applications on the same TRD as this release, you might see the following log messages: