Release Notes
|
The most-significant update to UM version 6.7 is interoperability with pre-6.0 versions of UM. Applications and persistent stores at version 6.7 are able to exchange messages and control information with 5.x applications, especially 5.3.6.
However, note that 6.7 applications are not able to interoperate with daemon components of 5.x, including the persistent store and the 5.x gateway. Also, 5.x applications are not able to interoperate with version 6.7 UM Router (DRO).
The following new features and enhancements apply to UMS, UMP, and UMQ products.
Receive-Side Batching - reduces latency and increases throughput in UM applications by bundling multiple messages to deliver. This bypasses the need to perform a boundary crossing for each delivered message.
You enable Receiver-Side Batching with configuration option delivery_control_message_batching (context). With C and .NET applications, you must be using an event queue for this feature (this is not a requirement for Java applications).
The unicast resolver daemon, lbmrd, no longer requires an Ultra Messaging license to run.
The unicast resolver daemon, lbmrd, now has command-line options to set buffer size in bytes for the receive socket buffer (-r
flag) and the send socket buffer (-s
flag).
In addition to Receive-Side Batching, other improvements have further reduced the latency and increased the throughput of the Java API.
When an error occurs on a socket while sending an ACK in LBT-RU, UM now generates an EOS immediately.
You can now set a source activity timeout for LBT-TCP sessions, with new configuration option transport_tcp_activity_timeout (source).
XInclude
' mechanism to merge multiple configuration files.
The following new features and enhancements apply to UMP and UMQ products.
Throttled Delivery - you can limit the number of message fragments that a persistent receiver delivers to a receiver application beyond the current highest consumed message fragment. This limits the amount of memory a receiver uses when that receiver consumes messages at rate much slower than the recovery rate from a UMP store or slower than the UMP source stream. To use UMP Throttled Delivery, set the new option ume_application_outstanding_maximum (receiver).
Enhanced Quorum/Consensus Store Registration and Message Stability
all-active
', the source requires, minimally, a quorum of stores to successfully stabilize a message within the group.
The following new features and enhancements apply to the UMQ product.
The following new features and enhancements apply to the Dynamic Routing Option (DRO).
XInclude
' mechanism to merge multiple configuration files.
The following bug fixes apply to UMS, UMP, and UMQ products.
Change Request | Description |
---|---|
2551 | With adaptive batching enabled, applications sometimes issue a warning assertion, |
5242 | Web monitor support link text displays, "29West Ultra Messaging Support". This is now changed to display, "Informatica Ultra Messaging Support". |
5626 | Ultra Messaging client XML configuration validation sometimes fails needlessly. As a solution, XML configuration parsing now tolerates invalid values such that you can use a single XML config file or UMM configuration template across multiple platforms, even if it contains option values that are not valid for all platforms. |
7261 | If automatic monitoring is misconfigured, instead of silently failing the creation and proceeding with a context or event queue setup, Ultra Messaging now logs the following messages: |
7917 | Destroying a source that matches a wildcard pattern, while dispatching an event queue with events from that source, creates a race condition. |
7939 | LBT-RU does not indicate in the packet when a datagram is a retransmission. As a solution, Ultra Messaging now marks retransmitted LBT-RU datagrams with a retransmit flag. This flag is visible only with packet dissection tools such as Wireshark. |
7944 | Using the function lbm_context_attr_dup() might cause a |
8024 | For Late Join, OTR, or Request/Response, Ultra Messaging does not perform NAT translation correctly. |
8065 | When using UM Routers (DRO), Ultra Messaging applications can cache old data that later can cause errors when creating and deleting wildcard receivers. The Ultra Messaging application context now cleans out this old data when it receives UM Router proxy source delete messages. |
8108 | Ultra Messaging accepts configuration option resolver_unicast_daemon (context) when it specifies more than one address. As a solution, incorrectly setting this option now issues message |
8114 | The lbmrd resolver sometimes issues message |
8153 | When a receiver receives increasingly large messages, a memory leak might occur. |
8150 | Ultra Messaging may now declare fragments requested for retransmission by a receiver from a store as unrecoverable prior to the retransmission request timeout, if all stores have declared that fragment unrecoverable. |
8160 | On a 64-bit UNIX platform using a UM XML configuration file, certain context names, event queue names, topic names, and wildcard patterns are not picked up, even though the configuration file specifies them. |
8198 | Mellanox Ultra Messaging applications with option ud_acceleration (context) set to 1 were forcing the VMA_SELECT_POLL environment variable to 0, resulting in poor latency performance. Applications can now set VMA_SELECT_POLL to the desired value, or can allow the Mellanox default value. |
8277 | LBT-SMX transport statistics include unsupported request/response statistics. As a solution the field lbm_reqs_rcved is renamed to ' |
8283 | LBMMON statistics receivers now report correct values for SMX transport statistics. |
8295 | The lbmrd unicast resolver daemon propagates certain non-LBMR messages to clients. As a solution, lbmrd now ignores these messages. |
8444 | When using LBT-RU and Source Side Filtering, a |
8557 | When you configure LBT-RU context and receiver port ranges to overlap, Ultra Messaging allows this and logs many copies of |
8591 | Sometimes for invalid receiver configuration combinations, Ultra Messaging repeats warning log messages for every transport joined. As a solution, invalid receiver configuration combinations now issue this warning once at receiver creation time. |
8608 | A Java or .NET hot failover receiver that experiences loss might assert with fatal assertion:[d_entry->topic_entry != NULL]. |
8610 | Message properties do not clear in Java and C# before loading the properties of the next message to be delivered. |
8633 | The function lbm_context_process_events() returns -1 for non-critical errors without further description. As a solution, Ultra Messaging no longer returns -1 from lbm_context_process_events() for non-critical errors. |
8662 | In the Java API, the array of stores returned by com::latencybusters::lbm::LBMSourceAttributes::getStores() contains an incorrect number of entries when using named stores. In addition to the solution for this, the com::latencybusters::lbm::UMEStoreEntry class now contains a new field to provide store name information. |
8682 | The lbm_serialize_response() function does not include the Domain ID in the serialized message. When a serialized response message traverses a UM Router (DRO) to a different topic resolution domain, the message cannot reach the requester, and the lbm_deserialize_response() function logs the following warning: |
8726 | If you set ume_retention_unique_confirmations (source) to 0 and ume_confirmed_delivery_notification (source) to 3, the first delivery confirmation sets the UNIQUE_ACKS flag. As a solution, this flag now sets only if you set option ume_retention_unique_confirmations (source) to a value greater than 0 and the number of confirmations received are enough to exceed the threshold. |
8732 | With option hf_duplicate_delivery (receiver) and ordered delivery enabled, hot failover receivers might deliver duplicate messages before the original messages. With this solution, messages flagged as duplicate are always be delivered after messages not flagged as duplicate. |
8733 | Hot failover receivers might leak memory when processing HF reset commands or when deleted. |
8743 | An Ultra Messaging application or daemon fatally asserts with message: |
8797 | Java method com::latencybusters::lbm::LBM::setDebugMask() sets incorrect mask values on 32-bit platforms. |
8868 | In the Java and .NET APIs, some objects accessible from an LBMMessage object are sometimes newly created for each LBMMessage delivered, in violation of the Zero Object Delivery (ZOD) functionality. The affected objects include com::latencybusters::lbm::LBMMessageChannelInfo for messages received on a spectrum channel, com::latencybusters::lbm::UMQIndexInfo for queueing messages with an index, and com::latencybusters::lbm::UMQMessageId for all queueing or ULB messages received. As a solution, com::latencybusters::lbm::LBMMessage objects now re-use these object types for each new message delivery, rather than creating new objects.
|
The following bug fixes apply to UMP and UMQ products.
Change Request | Description |
---|---|
1013 | When a umestored configuration file sets the ' |
3894 | When both registration IDs and session IDs are present, Ultra Messaging issues a log message stating that registration IDs are being ignored, but then fails to ignore them. |
5273 | Upon startup, a store could delay persistence of messages for up to the configured retransmit_request_generation_interval value, while attempting to recover messages from the source that the source has already reclaimed. As a solution, the source reports the non-availability of the requested messages back to the store, and the store can begin persistence without extra delay. |
5498 | The umestored daemon warns that option resolver_active_threshold (context) is deprecated. This warning is now removed. Setting this option continues to have no effect. |
6112 | The umercv sample application prints session IDs in decimal format. As a resolution, all sample applications now print Session IDs in hexadecimal, and continue to print registration IDs in decimal. |
7282, 8223 | A store might fail in certain incorrect registration scenarios. As a solution, if applications present invalid session ID and registration ID combinations, they now receive a registration error. |
8171 | An RPP-configured source can get an assert with the following log message: |
8185 | RPP stores can now send a stability ack for a message that was lost but later recovered via retransmission. |
8245 | Configuring UMP stores using non-increasing group index order, such as configuring storeA in group 2 before storeB in group 1, causes erroneous registration changes and indeterminate receiver behavior. |
8677 | With the Java API, on a Persistence deregistration event, the Ultra Messaging library delivers a com::latencybusters::lbm::UMEDeregistrationCompleteInfo with invalid contents. As a solution, since there is no information associated with this event, the com::latencybusters::lbm::LBMMessage::deregistrationCompleteInfo() method now always returns null. |
8704 | Ultra Messaging handles stability acknowledgements on the same thread as retransmissions, affecting the consistency of latency. As a solution, stability acknowledgements now use a different thread. |
8710 | With option ume_confirmed_delivery_notification (source) set to 3, after ume_retention_unique_confirmations (source) is reached, the whole message confirmed flag is not set for delivery confirmations for all receivers. |
8711 | In the .NET (C#) API, there are no methods to access objects com::latencybusters::lbm::UMESourceEventDeregistrationSuccessInfo and com::latencybusters::lbm::UMESourceEventDeregistrationCompleteInfo. As a solution, the C# library now includes accessor methods. |
8747 | Sometimes an application receives and acts upon retransmit response information intended for a different application. This solution makes retransmit requests more unique to the application issuing the request to prevent potential cross-contamination of retransmit response information during application restarts. |
8766 | UMP stores might accept messages from a UMP source that has not completed the registration process, resulting in the following fatal assertion: |
8804 | If there is a disk error modifying the state file on receiver registration, the umestored daemon writes to an invalid location, possibly causing a corrupted state file or umestored segmentation fault. As a solution, umestored no longer writes to an invalid location but instead issues a log-message warning. |
8808 | Store daemons sometimes issue a Store-5688-5258 message. As a solution, the umestored configuration code now disallows using multiple async write callbacks. This prevents situations where multiple writes could be executed out of order, causing data corruption. |
The following bug fixes apply to the UMQ product.
Change Request | Description |
---|---|
8315 | In the .NET API, Ultra Messaging reuses com::latencybusters::lbm::LBMMessageChannelInfo, com::latencybusters::lbm::UMQMessageId, and com::latencybusters::lbm::UMQIndexInfo objects between different com::latencybusters::lbm::LBMMessage objects for delivery, reducing garbage collection overhead. |
8325 | ULB reassigns messages even if option umq_ulb_application_set_message_max_reassignments (source) is set to 1. |
8536 | When restarting the UMQ daemon while handling zero-length-messages, the daemon sometimes fails with the following fatal assertion: |
8601 | An Ultra Messaging application crashes when ULB or UMQ receivers send a Consumption Report for a message after their source transport had been torn down. |
The following bug fixes apply to the Dynamic Routing Option (DRO).
Change Request | Description |
---|---|
7276 | When using an aggressive keepalive configuration on a UM Router (DRO) peer link, the UM Router might fatally terminate. |
8256 | When configuring a UM Router (DRO) Peer Connection on a Microsoft Windows machine, the single-tcp configuration option can result in no message traffic across the link. As a solution, Ultra Messaging now handles all documented error conditions, instead of only ' |
8303 | A UM Router (DRO) might crash when peer connections between two UM Routers quickly disconnect and reconnect. |
8446 | For Windows and 32-bit UNIX platforms, the web monitor displays non-zero values for the statistic "<i>Transport
topic fragments/bytes dropped due to blocking</i>", but Ultra Messaging does not log the message |
8459 | Single TCP connections repeatedly disconnect and reconnect under certain conditions. |
8461 | UM Router (DRO) peer connections, both dual and single TCP, might encounter an error and not be restarted. One side effect for the solution to this is that the UM Router now logs every connection attempt failure, resulting in more log messages if the other peer is not up. |
8752 | Error message: |
8763 | The UM Router (DRO) sometimes asserts with the messages: WARNING: failed assertion [Portal->peer.adjacent_node_id==0] at line 2679 in ../../../../src/gateway/tnwgpeer.c and: FATAL: failed assertion [void_o_entry!=NULL] at line 4205 in ../../../../src/gateway/ tnwgpeer.c |
The Round-Robin Store failover configuration is deprecated.
repository-disk-max-write-async-cbs
' option is deprecated.