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.
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.
In a future version of UM, there will be a reduction in supported platform for UM daemons.
The UM daemons are:
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.
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 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.
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: