Release Notes
UM Version 6.11

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.


Enhancements for 6.11  <-


Streaming Enhancements for 6.11  <-

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.

  • Rolling Log Files for Persistent Store and UM Router (DRO). To prevent unbounded disk file growth, the Persistent Store and the UM Router now support rolling log files. See Store Rolling Logs and UM Router Rolling Logs for details.


Persistence Enhancements for 6.11  <-

The following new features and enhancements apply to UMP and UMQ products.


Queuing Enhancements for 6.11  <-

The following new features and enhancements apply to the UMQ product.

  • None.


Dynamic Router Enhancements for 6.11  <-

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 UM Router now logs an informational message each time its internal routing table changes giving the reason for the change. Messages of this form will be printed during normal startup, to give status as the UM Router network establishes connectivity, and they will also be printed when a disruption causes a change in connectivity. The messages are of the form "Gwd-9574-xx".


Fixed Limitations for 6.11  <-


Streaming Fixed Limitations for 6.11  <-

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 "lbm_request_t **reqp" parameter can be returned with NULL.

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 lbmrd operation. This does not work with Java Properties.

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:
cattr.setProperty("resolver_unicast_daemon", "10.3.29.181:5555,10.3.29.185:5555,10.3.29.190:5555");

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'.


Persistence Fixed Limitations for 6.11  <-

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:

  • FATAL: failed assertion [buff->len<=LBMUIM_APDU]
  • WARNING: failed assertion [ntohl(ohdr->sqn)==rec->sqn]
  • WARNING: failed assertion [ntohs(ohdr->msglen)<=rxbuff->maxlen]
  • WARNING: failed assertion [ntohs(ohdr->msglen)==rec->disk_len]

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.


Queuing Fixed Limitations for 6.11  <-

The following bug fixes apply to the UMQ product.

  • None.


Dynamic Router Fixed Limitations for 6.11  <-

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.