52. Release LBM 3.3.9 / UME 2.0.7 - December 2008

Known Issue: 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.

Feature Resumption: String caching for the Java and .NET APIs has been re-enabled. Rather than creating a new string for the topic and source when each message is delivered, LBM uses a reference to a cached string which improves performance. In addition, the previously disabled per-source client object has been reintroduced. The object returned from the per-source creation callback is now available in the receiver and per-source deletion callbacks.

Added support in Java and .NET for changing the callbacks associated with an LBMRecieverAttributes object during the WildcardReceiverCreateCallback.

Added performance enhancements to Self Describing Messaging (SDM) which included a new attribute option, integer_fieldname which allows you to substitute a non-negative integer for a field name, which enhances field array indexing. In addition, added a new function, lbmsdm_msg_parse_reuse(), which allows parsing a message into an existing lbmsdm_msg_t structure. SDM clears the message before parsing, removing all existing fields from the message. See the API documentation for more information ( C API, Java API or .NET API).

LBM now only supports 64-bit systems on MAC OS X. LBM no longer supports 32-bit MAC OS X systems.

Added a log warning for Microsoft® Windows® users to advise on possible loss from the combination of high settings for the rate limiter and low source side buffer settings used with LBT-RM or LBT-RU.

Introduced code to properly avoid allowing callback objects from being garbage collected prematurely. New code also aids in the implementation of string caching. For Java and .NET only.

Fixed a case where an internal reference count could become negative when using wildcard receivers. This resulted in the wrong receiver attributes being used in cases where multiple receivers for the same topic were being used by a wildcard receiver whose pattern matched the topic in question.

Fixed a problem that caused the WildcardReceiverCreateCallback to not be called in instances where a previous receiver for that topic already existed.

Added a WildcardReceiverDeleteCallback. This callback is symmetric with the WildcardReceiverCreateCallback, and provides notification when one of the underlying receivers created by a wildcard receiver is deleted.

Resolved an issue in .NET with a NullReferenceException that was generated when statistics were received by an LBMMonitorReceiver. LBMStatistics now correctly handles the timestamp received from lbmmon.

LBM now prints a warning message every time a source or receiver joins a transport session that has settings for certain attributes different from what the source or receiver has configured. As always, the source or receiver must use the existing transport session's attributes.

Resolved an issue with calling lbm_rcv_topic_lookup without a corresponding lbm_rcv_create that caused a double free upon context deletion. LBM now correctly disposes of the topic upon context deletion.

Fixed a deadlock issue on Microsoft Windows caused by creating attribute objects on multiple threads simultaneously.

Corrected a utility queue removal function (utl_queue_remove_timedwait()). The function held the queue lock too long, causing one thread to monopolize the lock, preventing another thread from accessing the queue. This problem only occurred on Microsoft Windows.

Reverted the LBMTimer.cancel() method in the Java API to not take arguments. This corrects an inadvertent change in LBM 3.3.7 that required developers to change their applications to call LBMTimer.cancel(false) instead of LBMTimer.cancel().

Fixed an issue when using the devpoll fd_management_type on Solaris which could cause a fatal assertion if the application was interrupted with a signal.

Fixed an issue regarding an unexpected interaction between the WildcardReceiverCreateCallback and the recovery sequence number callback that resulted in a segfault in Java. This error occurred when using UME and registering for the WildcardReceiverCreateCallback.