43. Release LBM 3.6.ea2 / UME 3.0ea2 - September 2009

Added to the LBM Gateway the ability to configure multiple connection sections. This permits a receive-side Gateway to fail over when a connection to the source-side Gateway fails

Added support for Spectrum to the Java and .NET APIs.

Added the <daemon> section to the lbmrd XML configuration file. Child elements are <port>, <log>, <activity>, <interface>, <ttl> and <resolver_unicast_receiver_socket_buffer>. This element can be used to configure the lbmrd receive buffer size.

Improved performance of all 29West products on Microsoft® Windows® by implementing new build techniques.

Microsoft has recently provided a security update for the C runtime library (msvcr80.dll version: 8.0.50727.4053). In order to avoid potential issues, 29West recommends installing the latest redistributable C runtime library. See http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=766a6af7-ec73-40ff-b072-9112bab119c2 for further details.

Corrected a problem with Java that could cause a JVM crash if a thread received a small response message (less than 8192 bytes) followed by a large response message (greater than 8192 bytes).

Updated the .NET version of lbmpong to be consistent with the C and Java versions by allowing lbmpong to collect data in verbose mode, ignore messages at the head of the stream and calculate the standard deviation, minimum, maximum and average.

Corrected a problem that occurred if a Microsoft Windows application using completion ports ( fd_management_type) in embedded mode ( operational_mode) used a separate thread to create an LBM Context and that thread ended before the LBM Context. For sequential mode, the following warning now appears: lbm_context_process_events: Completion ports warning; Context creation thread has terminated. Some events may be lost. In this case, 29West recommends that you change your application code to keep the context-creating thread around for the lifetime of the context.

Fixed an issue with SDM Unicode strings in .NET. If a Unicode field was the last field in a packet, the length check produced an assertion because the check was made during the unicode string encoding rather than before the encoding. The length check now occurs prior to string encoding.

Added the correct channel flags to Spectrum channel messages.

Modified .NET to pull the source string from the string cache during the registration_id_ex callback.

Corrected a problem with LBM receivers which resulted in the receivers containing an incorrect source port for TCP sources.

Corrected a problem with the creation of a source for a topic which was hashed to the same value as another source topic. This condition caused an infinite loop and has been corrected.

Corrected a problem with lbmrcv.c. This application deleted the receiver before calling lbmmon_rcv_unmonitor(). If the monitoring period expired after the delete but before the unmonitor call, the following assertion appears: LOG Level 1: FATAL: failed assertion [rcv->rcv!=NULL] at line 1576 in ../../../../src/lib/lbm/lbmrcv.c. The receiver delete now occurs after the lbmmon_rcv_unmonitor().

Fixed a Microsoft Windows synchronization problem which resulted in extreme delays if a source object used multiple threads for blocking sends.

Corrected a problem that could cause a JVM crash if a Java application running in Embedded Mode delivered certain logging callbacks.

Fixed a problem with Late Join that occurred when recovering old messages from a source. If loss occurred on the live stream during recovery, the source would either stop or delay the delivery of messages to the application and buffer the messages instead, causing unbounded memory consumption. In addition, any messages that were delivered could be delivered out of order.

Corrected a memory leak that occurred when creating Java LBMContextStatistics objects.

Corrected a problem with the LBT-IPC transport on Microsoft Windows that caused multiple processes that were started in rapid succession to send data to the same shared memory area. This problem produced the following failed assertion at the receiver: MUL_ASSERT((MUL_SQN_GT(sqn, ctlr->stream_high_sqn)));

Increased an internal NAK timer constant for LBT-RM receivers to improve loss handling in high-loss cases.

When using Event Queues with the Java API on Mac OS X kernel 9.4, core dumps have occurred. Mac OS X kernel versions prior to 9.4 have not produced this behavior. 29West is investigating this issue.

Shutting down a source-side LBM Gateway with Control-C can cause the Gateway to become dead locked. 29West is investigating this issue.

If a source LBM Gateway was shutdown and then the receiving Gateway was shutdown as quickly as possible while still carrying traffic, a fatal assert occurs. (MUL_FATAL_ASSERT(Table!=NULL);) 29West is investigating this issue.

LBM Spectrum does not operate correctly with wildcard receivers. The functions lbm_wildcard_rcv_subscribe_channel and lbm_wildcard_unsubscribe_channel (as well as LBMWildcardReceiver.subscribeChannel() and LBMWildcardReciever.unsubscribeChannel() in Java and .NET) should not be called, and the receiver attributes "null_channel_behavior" and "unrecognized_channel_behavior" should not be used if wildcard receivers are being used. This issue will be corrected in a later release.

Fixed an issue in .NET and C where the topic index was not included in the source string passed to the user in the UME registration callbacks set by ume_registration_function and ume_registration_extended_function, which are options for lbm_rcv_topic_attr_setopt().

Queue resiliency is not in place with this release. Multiple Queues with the same name are not supported with this release. In addition, Queues that fail and restart will not work with continually functioning sources and receivers.

Sources must use either UME stores or a UME queue, but not both at the same time. This will be addressed in a future release.

When using a UME Queue, receivers should not rely upon the message sequence number supplied in the lbm_msg_t (or LBMMessage) object as the sequence numbering may change in future releases. Applications should utilize the Message-ID instead.

EOS semantics related to Queuing are somewhat complicated depending on the dissemination model being used. New events may be introduced in future releases to handle additional "EOS-like" concerns associated with the use of a UME Queue.