18. Release UMS 5.0 / UMP 5.0 / UMQ 5.0 - August 2011

Attention - Name Change: Beginning with this release, the LBM product has been renamed to Ultra Messaging® Streaming Edition (UMS) and the UME product has been renamed to Ultra Messaging Persistence Edition (UMP). UMQ retains its name, Ultra Messaging Queuing Edition (UMQ). Also with this release, the version number for these core UM products will be the same.

18.1. UMS 5.0

18.1.1. New Features

  • Documentation TOC and Search Page - The UM Readme file is now presented in a framed, HTML page. The left pane contains a Table of Contents for all documentation and a search function box, providing easier access to the UM documentation.

  • XML Configuration Files - Added the ability to use XML configuration files. See XML Configuration Files.

  • Pre-Defined Messaging (PDM) - Added Pre-Defined Messaging (PDM) that provides an API similar to the SDM API that allows you to define messages once and then use the definition to create messages that may contain self-describing data. See Pre-Defined Messaging.

18.1.2. Updates

  • Multiple Unicast Resolver Daemons (lbmrd) - Added the ability to specify multiple Unicast Resolver Daemons (lbmrd), to be used in a warm-warm failover mode. When using multiple lbmrds, all applications should specify the same set of lbmrds. See Unicast Topic Resolution Resilience.

  • Optimize Implicit Batching - Changed the implicit batching feature to use a fixed-size array instead of a a queue that was not allowed to exceed a predefined maximum size. Preallocating an array of the maximum size removes a malloc/free combination from the message path for every message. This change improves performance by about 30 percent.

  • Added the LBMObjectRecycler and LBMObjectRecyclerBase classes in the Java API and the .NET API to provide a way to reuse objects and reduce garbage collection. These classes support all of the Statistics types as well as the LBMMessage type so promoted messages can be recycled. The lbmhfxrcv, lbmsrc, lbmpong, lbmrcv, lbmreq, lbmresp, lbmmsrc, umercv, umesrc, umqrcv, and umqsrc Java example applications and .NET example applications have been updated to demonstrate the use of these classes.

  • Added the murmur2 hash function as a built-in option to the resolver_string_hash_function context configuration option. murmur2 can perform better than the existing built-in hash functions for long topic strings.

  • Added support for setting UMS wildcard receiver options to the UM Gateway.

  • Added the public LBMMessage.promote() method. If applications intend to hold messages for later processing, they should call promote() to guarantee that messages are not reclaimed by UMS.

  • Added getAttributeValue and setAttributeValue methods to LBMHFXReceiver to provide the same functionality as other UM objects.

  • Added a new UM Gateway Web Monitor statistic to show the number of retransmit requests received by an endpoint for an unknown source.

18.1.3. Bug Fixes

  • The UM Gateway now logs an error message if the initialization of gateway monitoring fails.

  • Corrected a problem with Automatic Monitoring that caused incorrect clean up of implicitly spawned reactor contexts. Other problems fixed occurred when using epoll with ud_acceleration causing the UD Acceleration library to report errors during clean up. When UD Acceleration was not used, the base epoll file descriptor leaked.

  • In the UM Gateway, corrected a memory leak of 64 bytes for each <regex-pattern> in an ACL.

  • Fixed a condition where a regular receiver's callback function could be called before the user application's lbm_rcv_t pointer is set.

  • Added the -E option to the lbmmrcv.java example application to allow it to exit upon receiving an EOS like the C example application.

  • Corrected a problem in the UM Gateway that occurred if you create a context with request_tcp_bind_request_port = 0, and a source created on that context provides late_join. This configuration disabled Late Join. Now lbm_src_topic_alloc() returns the following error. late join not allowed when request_tcp_bind_request_port is disabled.

  • Corrected a problem in the UM Gateway that caused errors relating to the creation of unicast forwarding associations to be incorrectly reported.

  • Fixed an issue that could lead to a crash if implicit batching was being used and a particular OS socket send call failed, which is relatively rare failure.

  • Fixed an issue that could cause a crash if using Adaptive Batching and you delete a source with messages still outstanding in the batch buffer.

  • Fixed an issue in the Java API that caused a NullReferenceException if you passed in null for the third parameter to the LBMHFXReceiver constructor.

  • Corrected a problem in the UM Gateway that caused deafness in wildcard receivers due to case-insensitive topic patterns. The UM Gateway now uses case-sensitive string compares when mapping topics and patterns.

  • Corrected a problem in the UM Gateway that caused receivers using TCP, IPC, or LBT-RDMA transports to encounter the warning assertion: MUL_SQN_GT(sqn,ctlr->stream_high_sqn) and receive data out of order despite Ordered Delivery was enabled.

  • Removed a lock taken during a call to lbm_context_delete() which could cause a running IPC or RDMA receiver thread to deadlock during context deletion.

  • Fixed an issue with the Java API where setting both a context source event callback via LBMContextAttributes.setContextSourceEventCallback and also enabling receipt of topicless immediate messages via calling LBMContext.enableImmediateMessageReceiver could cause a crash upon receipt of a topicless immediate message. Setting only one (or none) of the two callbacks was successful, and setting both callbacks was successful if the newer, preferred LBMContextAttributes.setImmediateMessageCallback method was used to set the topicless immediate message callback instead of LBMContext.enableImmediateMessageReceiver.

  • Optimized memory usage of the resolver cache for contexts on a network with LBM 3.6 or earlier sources.

  • Corrected a problem that caused the C APIs lbm_*_attr_dump() and their Java API / .NET API equivalents to return strings containing garbage values for deprecated or unsupported options.

  • Updated the version of libpre bundled with the AIX install packages to match the version of libpre Informatica uses to build the AIX UM packages.

18.1.4. Known Issues

  • Hot Failover is not currently supported with Multi-Transport Threads.

  • Configuring sources with LBT-RU, source-side filtering, and adaptive batching may cause a crash. All three options must be set to cause the problem. Informatica is working to address this issue.

  • When using the UM Gateway Informatica recommends that you do not enable the Multi-Transport Threads feature. Informatica does not support nor test the operation of Multi-Transport Threads across the UM Gateway.

  • Multi-Transport Threads do not support persistent stores (UMP) or queues (UMQ).

  • 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. Informatica is investigating this issue.

  • Sending LBT-IPC messages larger than 65,535 bytes is not supported when ordered_delivery has been set to 0 (zero) unless you set transport_lbtipc_behavior to receiver_paced.

  • When using the LBT-RDMA transport with Java applications, a segfault can occur if you kill a receiver with Ctrl-C. As a workaround, use the JVM option, -Xrs. Informatica is investigating this problem.

  • If you use the current version of VMS (3.2.8), UMS 4.1 issues the following warning: LOG Level 5: LBT-RDMA: VMS Logger Message (Error): vmss_create_store: 196[E] vms_listen: rdma_bind_addr failed (r=-1). This warning indicates that rdma_bind failed for ethernet interfaces, which is expected behavior. Currently, VMS attempts rdma_bind on all interfaces. When released, VMS version 3.2.9 will only run rdma_bind on infiniband-capable interfaces.

  • When using Automatic Monitoring with ud_acceleration and the epoll file descriptor option, UMS may leave a monitoring thread running after context deletion. Informatica is investigating this problem.

  • The UM Gateway does not currently support responses that exceed the maximum datagram size.

  • At the present time, 32-bit applications cannot interact with 64-bt applications using the LBT-IPC transport. As a result, a 64-bit UM Gateway cannot interact with a 32-bit application using LBT-IPC. It can only interact with a 64-bit application. Likewise, a 32-bit UM Gateway can only interact with a 32-bit application.

  • The UM Gateway does not currently support queuing at this time, only streaming and persistence. This will be resolved in a future release.

  • The UM Gateway is not supported as a standalone Windows service at this time. This will be resolved in a future release.

  • The UM Gateway does not currently support a four gateway "full-mesh" configuration (i.e., all gateways connected).

  • If using LBT-RDMA across the UM Gateway and you exit the gateway with Ctrl-C, you may see a segfault. Informatica is aware of this and has not observed any ill effects from this segfault.

  • Informatica recommends against configuring UM Gateways in a ring of peer portals - use configurations utilizing gateway endpoints (parallel paths) to break the ring.

  • Informatica recommends not stopping and restarting UM Gateways within the transport's activity timeout period (transport_*_activity_timeout defaults to 60 seconds for LBTRU and LBTRM).

18.2. UMP 5.0

18.2.1. New Features

  • Ultra Messaging Manager - This new feature ensures the consistency and reliability of enterprise production applications by enabling IT administrators to control what configurations messaging applications can use and what users can operate them. See Ultra Messaging Manager.

18.2.2. Updates

  • Batching Acknowledgments - Added the ability configure UMP to acknowledge message consumption to a store(s) for a series of messages independent of when the receiving application consumed the messages. This option works well if multiple threads process messages off of an event queue, which may result in messages being consumed out of order. See Batching Acknowledgments.

  • Object-free Explicit Acknowledgments - When using explicit ACKs in a Java or .NET application, you can enable Zero Object Delivery (ZOD) and extract ACK information from messages and then send acknowledgements to the store(s) for any sequence number. See Object-free Explicit Acknowledgments.

  • Added new configuration option, ume_allow_confirmed_delivery.

18.2.3. Bug Fixes

  • lbm_msg_ume_send_explicit_ack() now returns 0 (zero) for success instead of the number of bytes sent. It still returns -1 for failure.

  • Fixed a problem originating from a source configured to use both UMP and ULB at the same time. This configuration caused the following assert: WARNING: failed assertion [buff->umesendexcd!=NULL] at line 2543 in .../../../../src/lib/lbm/lbmsrc.c.

  • Corrected a problem that appeared if you did not configure any UMP stores and set either ume_confirmed_delivery_notification or ume_message_stability_notification to deliver per message notifications as opposed to merely per fragment notifications.

  • Fixed a rare condition that could briefly cause a single UMP receiver to be registered with a store multiple times for the same source.

  • Corrected a fatal assertion that occurred when sending a combination of fragmented and non fragmented hot failover messages when running a Java receiver with ume_use_ack_batching enabled. The fatal assertion was [MUL_SQN_GTE(first,ctlr->expected_sqn)] at line 1555 in ../../../../src/lib/lbm/ume/umerctlr.c

  • Fixed a rare issue that could cause a UM application (including umestored) to crash on startup with FATAL: failed assertion[info->umq_ack.flags&LBMC_UMQ_ACK_FLAG_TYPE_STABLE].

18.2.4. Known Issues

  • Receivers using event queues and Spectrum with UME can experience a SIGSEGV while shutting down if events still exist on the event queue when it is deleted. As a workaround, use LBM_EVQ_BLOCK when dispatching event queues. During application shutdown, call lbm_evq_unblock() after deleting receivers associated with the event queue, but before deleting any context objects. Once the dispatch thread exits, it is safe to proceed with context deletion. 29West is working on a solution to this problem.

  • When running a store on a Solaris machine, you may experience registration failures after a few minutes. The store repeatedly reports the error, [WARNING]: wait returned error 4 [select: (22) Invalid argument]. Changing fd_management_type to devpoll prevents this problem. Informatica is investigating this problem.

  • UMP proxy source elections can only occur among stores in the same topic resolution domain connected directly via peer links. Informatica is investigating this problem.

18.3. UMQ 5.0

18.3.1. Updates

  • Indexed Ultra Load balancing (ULB) - Added indexing features to ULB, which is similar to indexed queueing and uses the same APIs (lbm_rcv_umq_index_start_assignment(), lbm_rcv_umq_index_release(), etc.), specifying the ULB source string in place of a queue name. See Indexed Ultra Load Balancing (ULB).

  • Added the ability to set a message's total lifetime for both UMQ and ULB sources. See Message Lifetimes and Reassignment.

  • Local JMS Transaction Support - UM JMS now supports local transaction.

  • JMS Application Header Attribute- Added the ConnectionFactory. attribute, USE_APP_HEADER, allowing you to turn off the use of App Headers which can greatly increases performance. See FactoryAttributes.

  • Removed the restriction requiring that the umq_ulb_application_set source option be specified prior to setting any other umq_ulb_application_set_* or umq_ulb_receiver_* options.

18.3.2. Bug Fixes

  • Fixed an issue with ULB that prevented ULB receivers from completing registration when they attempted to register with a ULB source using an assignment ID (internal 32-bit identifier generated randomly at receiver startup) already in use by a different receiver at that source. This issue could cause the log warning : received ACK with out-of-range appset index 65535/1.

  • Fixed a problem in the Java API that caused a UMP store or UMQ queue to fail to acknowledge messages that are passed off to a different thread to be disposed.

  • Added LBM as a DEFAULT_TOPIC_TYPE and DEFAULT_TEMP_TOPIC_TYPE in the JMS App Header. This allows Request/Reply to work without UMP.

Copyright (c) 2004 - 2014 Informatica Corporation. All rights reserved.