Release Notes
|
The most-significant updates to UM version 6.11 are the introduction of XSP for multi-threading receivers, and Daemon Statistics for the Store and the UM Router.
The following new features and enhancements apply to UMS, UMP, and UMQ products.
Transport Services Provider (XSP). XSP is a new method of assigning receiver transport sessions to independent threads. XSP gives the application control over how received transport sessions are assigned to threads. It replaces the earlier Multi-Transport Threads (MTT) feature, which is no longer supported. For more information, see Transport Services Provider (XSP).
Enhanced Smart Source feature. The Smart Sources feature now supports more functionality. Some of this support is limited, so please check the corresponding sections for further information.
For this UM version, the Smart Source API is not supported in .net.
The following new features and enhancements apply to UMP and UMQ products.
Smart Sources now support Persistence. See Smart Sources and Persistence. (See also Streaming Enhancements for 6.11 for more enhancements to Smart Sources.)
The following new features and enhancements apply to the UMQ product.
The following new features and enhancements apply to the Dynamic Routing Option (DRO).
Dynamic Router Daemon Statistics. A new method of monitoring the UM Dynamic Router daemon. The same information which is currently available on the daemons' web monitors can now be published on a normal UM topic. See Daemon Statistics.
The following bug fixes apply to UMS, UMP, and UMQ products.
Change Request | Description |
---|---|
10260 | FIXED: When using Smart Source, a source processing NAKs can fatal assert: "(bvec->flags & ~LBTRM_BVEC_SMART_SOURCE_FLAG) == 0". |
10178 | FIXED: An unnecessary sprintf() initializing a string buffer is being called from lbm_context_process_events(). The sprintf() was moved to context creation. |
10135 | FIXED: When using the JAVA interface, if the source has ume_message_stability_notification (source) set to LBM_SRC_TOPIC_ATTR_UME_STABLE_EVENT_PER_MESSAGE, you could get an ArrayIndexOutOfBoundsException on the source event callback. |
10087 | FIXED: Applications and daemons are at risk of a bus error on architectures that require alignment (SPARC, Power). These happen very rarely, and are associated with UIM messages in a UM Routed (DRO) environment. (Note: UIMs are involved with many features, such as Late Join, Persistence, and ULB.) |
10085 | FIXED: Interoperation between little-endian and big-endian architectures was broken in UM version 6.10. This problem also interferes with interoperation between 6.10 and any other version of UM, on big-endian architectures. This affects systems that use any combination of UM Routers (DRO), Persistence, or Hot Failover. Users with big-endian architectures are advised to avoid UM version 6.10. |
10079 | FIXED: Java and .NET programs that use the topic resolution callback by overriding the context object's onResolverEvent() method can generate a segmentation fault, resulting in a JVM dump. |
10071, 10072 | FIXED: SDM: cloning an attribute object does not copy over the state of the "name_tree" attribute. |
10048 | FIXED: If a Java application improperly calls respond() for a message after it had been disposed, a crash results. It is requested that respond() instead throw an exception, to make it easier for application bugs to be diagnosed. |
9973 | FIXED: If lbm_send_request() is called on a heavily-loaded system, and a response is returned very quickly, the |
9963, 10172 | FIXED: In UM version 6.7 a change was made which had the unintended consequence of unnecessarily increasing network traffic related to "final advertisements" (see resolver_send_final_advertisements (source)). |
9913 | Source Send call from within context callbacks is inconsistently documented. The C, Java, and .NET API documents have been updated to be consistent and correct related to context thread callbacks. See lbm_src_send(), lbm_src_send_ex(), lbm_src_sendv(), lbm_src_sendv_ex(), lbm_send_request(), lbm_send_request_ex(), lbm_hf_src_send(), lbm_hf_src_send_ex(), lbm_hf_src_send_rcv_reset(), lbm_hf_src_sendv(), lbm_hf_src_sendv_ex(), lbm_send_response(). |
9829 | FIXED: If a Java application improperly attempts to close a context object before all child objects (sources, receivers) are closed, a crash can result. Now, if an application attempts to close a context that still contains active sources or receivers, a warning is logged and the context is not closed. However, no exception is thrown from the context close; it returns normally. The user must use the error log to identify the application bug. |
9816 | FIXED: The documentation did not inform the user that it is necessary to have a consistent value for transport_lbtrm_datagram_max_size (context). A note has been added to resolver_datagram_max_size (context), transport_lbtsmx_datagram_max_size (source), transport_lbtrm_datagram_max_size (context), transport_lbtru_datagram_max_size (context), transport_tcp_datagram_max_size (context), transport_lbtipc_datagram_max_size (context), transport_lbtrdma_datagram_max_size (context). |
9606 | FIXED: Java properties don't support redundant keys. This creates a problem for the resolver_unicast_daemon (context) configuration option which needs to be specified multiple times for redundant The solution was to modify resolver_unicast_daemon (context) to allow multiple servers to be specified in a single specification, separated by commas or semicolons. For example: |
5555 | FIXED: Message Properties are incompatible with the Spectrum feature. Both cannot be used for the same message. Now a message can be sent both with message properties and to a Spectrum channel. |
7763 | This bug cannot be reproduced in any recent version of UM. The bug is assumed to be FIXED: You cannot send messages larger than 65,535 bytes over the LBT-IPC transport when you set option ordered_delivery (receiver) to 0 (zero) unless you also set transport_lbtipc_behavior (source) to 'receiver_paced '. |
The following bug fixes apply to UMP and UMQ products.
Change Request | Description |
---|---|
10231 | FIXED: The Persistent Store Web Monitor displays truncated values for "Retransmission Request Received Rate" and "Retransmission Request Service Rate". The decimal portion is now correctly displayed. |
6088, 8660, 8955, 4899 | FIXED: Persistent Store log files grow without bounds. Rolling log files are now implemented in the Store and in the UM Router. See Store Rolling Logs and UM Router Rolling Logs for details. |
10201 | FIXED: In a scenario where messages are getting lost and proactive retransmissions are being used between the source and the store, it is possible to get into a state where the source would be infinitely stuck on flight size. |
10196 | FIXED: When a store is not keeping up with incoming messages to the point where it has to intentionally drop incoming messages, there is a possible scenario where the source can get stuck, blocked on flight size. |
10183, 6324 | FIXED: When the store is overwhelmed with incoming messages and has to intentionally drop some messages, it is possible for the state associated with the store to get corrupted and, depending on the next sequence of events, one or more of the following messages can be logged:
followed by either an abort or a segmentation fault. Checks have been added so that the store's state won't be corrupted. |
10176 | The description of message Store-5688-5574 has been corrected. |
10063, 10064 | FIXED: Version 6.10 of the Persistent Store had a condition that could cause rare segmentation faults. When it happens, it is usually associated with the store falling behind the source. |
10036 | FIXED: When using an RPP non-blocking receiver, the source blocks once the store's disk repository fills up. Now, when the store's repository fills up, messages will be deleted if only non-blocking acks are outstanding. |
The following bug fixes apply to the UMQ product.
The following bug fixes apply to the Dynamic Routing Option (DRO).
Change Request | Description |
---|---|
10194 | FIXED: When Peer Links attempt to establish connections, there is a window during which a socket could get closed just before attempting to complete the connection. This can result in a fatal assert "handle==conn_mgr->sock->sock", or could simply result in the peer link not making any more connection attempts, leaving the link permanently disconnected. |
10188 | FIXED: An issue with routing Multicast Immediate Messages (MIM) through a DRO running SPARC 32-bit systems which caused a bus error. |
10163 | FIXED: There are several instances of random message corruption which can cause the UM Router to crash. Defensive checks have been added to protect the DRO against malformed messages. |
10051 | FIXED: Large UIM messages can become corrupted while transiting a DRO network. It happens when message fragments are either dropped (due to link overload) or become out of order. |
10050 | FIXED: In UM 6.10, the UM Router (DRO) crashes when it is paired with the UMS or UMP version of the UM library. |