|
Release Notes
|
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.
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.
The following new features and enhancements apply to UMP and UMQ products.
UM 6.8 introduces the following new API call:
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.
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 (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_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 ' |
| 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. |
The following new features and enhancements apply to the UMQ product.
Robust commodity-based JMS/AMQP broker features:
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.
For more information on upgrading queuing applications, see Queuing Upgrade Considerations.
The following new features and enhancements apply to the Dynamic Routing Option (DRO).
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 ' |
| 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: |
| 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 ' |
| 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: |
| 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 ' |
| 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 |
| 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: |
| 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 ' |
| 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: |
| 9372 | When you enable ' |
| 9436 | Message selectors that consist of only white space cause a message selector parsing error. |
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: 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. |
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 ' |
| 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. |
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: |
| 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 ' |
| 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. |
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) |
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.
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).
If you are upgrading from a UM version prior to 6.8, you must also examine the Special Upgrade Instructions for 6.7.