|
Release Notes
|
The following open limitations apply to UMS, UMP, and UMQ products.
| Change Request | Description |
|---|---|
| 11327 | When a subscriber joins an IPC source, the IPC thread can fail to initialize properly, resulting in receiver "deafness" to IPC sources. One symptom of this is "rolling EOS events" (repeated LBM_MSG_EOS receiver events without any LBM_MSG_BOS events and without any message reception). WORKAROUND: use IPC Sequential Mode (not available for Java or .NET). |
| 11268 | The Store operational tool "umedcmd" cannot be used on a Store that is configured for protobuf-based daemon monitoring. |
| 11266 | The "lbmmon.c" and "lbmmon.java" example applications do not support the SRS protobuf-based stats. (Note that the MCS does support them.) |
| 10985 | Request to add a configurable maximum number of TSNIs per datagram. For users of kernel bypass drivers who set their datagram max size above a network MTU, this can lead to undesirable IP fragmentation when a TSNI uses most of the configured max datagram size. At this time, this request is not planned to be implemented. Instead, the Dynamic Fragmentation Reduction feature should be used to avoid IP fragmentation. |
| 11038 | A low-traffic topic that transitions across a DRO can produce a series of "EOS" events on a receiver. This happens when the receiver is created after the source's TSNIs become inactive (60 seconds by default; see transport_topic_sequence_number_info_active_threshold (source)). Creation of the receiver triggers the creation of a proxy source on the DRO's portal. But in the absence of either user messages or TSNIs, the proxy source never starts sending session messages, resulting in the receiver timing out and re-creating the transport session. WORKAROUND: Set transport_topic_sequence_number_info_active_threshold (source) to zero for the source that is causing the problem. This causes TSNIs to be sent in the absence of user data for unlimited time. |
| 11036 | Request to officially support .NET Core on Windows. At the present time, UM's .NET Core implementation has only been tested on Linux. |
| 11018 | When TLS encryption is used, the OpenSSL package will attempt to open some files with paths that correspond to where the package was originally built. For example, you might see OpenSSL attempt to open the file: /home/ssawalski/openssl-p/Linux-glibc-2.5-x86_64/cert.pem. Note: as of UM version 6.12.1, only users of the TLS encryption features will see this happen. See OpenSSL Dependency. |
| 10937 | In UM version 6.13, the lbmrd default interface stopped working properly. The default interface is defined to be "0.0.0.0", (INADDR_ANY). In UM versions prior to 6.13, this binding allowed lbmrd to accept TR packets on any host interface. In UM 6.13 the behavior changed to being an interface matching specification, which caused UM to select and bind to the first interface it finds, which is typically 127.0.0.1 (localhost). This rejects TR packets from remote hosts. WORKAROUND: an interface matching specification must be provided, either via the command-line using the "-i" option (see Lbmrd Man Page), or via the "<interface>" XML configuration element (see LBMRD Element "<interface>"). Note that an easy and flexible method for specifying the interface is using CIDR notation, such as "10.0.0.0/8". This matches any interface whose IP address starts with 10. See Add LBMRD Interface. |
| 10933 | In UM version 6.5, the data structure lbm_context_stats_t grew in size. This means that applications compiled with UM versions prior to UM 6.5 but executed with a UM version 6.5 or beyond do not allocate enough space for that structure when calling lbm_context_retrieve_stats(). This can lead to unpredictable behavior. SOLUTION: any application compiled with UM versions prior to UM 6.5 must be recompiled prior to being used with a UM version 6.5 or beyond. See Upgrade Procedure. |
| 10833 | Running 6.13 or beyond applications with pre-6.13 DRO can lead to DRO logging: This happens because starting with UM 6.13, persistent receivers can request "ranged recovery" from a Persistent Store, but pre-6.13 DROs do not understand the new control message. SOLUTION: follow the recommended Order of Upgrades. |
| 10897 | The Windows version of the umedcmd command does not process registration IDs greater than 2147483647. This is because the program uses "atoi()", which does not define behavior for out-of-range values. WORKAROUND 1: Modify umedcmd.c to use atoll() and rebuild. WORKAROUND 2: Use the Linux executable. Although it is not guaranteed, glibc will internally overflow the conversion in such a way as to produce the correct 32-bit unsigned value. |
| 10772 | Starting with UM version 6.10, the UM library built for Darwin (MacOS) no longer supports fd_management_type (context) of "kqueue". |
| 10498 | Security Vulnerability: the Persistent Store web monitor function can be used to read arbitrary files on the host running the Store daemon. Note that even when this issue is resolved, the Persistent Store web monitor is not a secure system, and is not intended to be exposed to unauthorized users. In particular, the web monitor cannot be configured for authentication or encryption, including UM's own Encrypted TCP. Users are expected to prevent unauthorized access to the web monitor through normal firewalling methods (e.g. only allowing access to the port from specific remote IP addresses). Users who are unable to limit access to a level consistent with their overall security needs should disable the store web monitor. See Webmon Security for more information.
|
| 10609 | The DRO daemon statistics message type tnwg_portal_peer_dstat_record_t has 3 improper fields: remote_interest_topics, remote_interest_pcre_patterns, and remote_interest_regex_patterns. They are improper because those counts do not apply to a peer portal. In UM versions prior to 6.13, the tnwg_portal_peer_dstat_record_t messages can have uninitialized values in those fields. Workaround: a monitoring application should ignore those 3 fields. Note: to maintain backwards compatibility, Informatica does not plan to remove these fields from the data structure. As of UM version 6.13, these fields are set to zero (instead of possibly being uninitialized). |
| 10136 | When an XML file is used to configure UM, an invalid configuration option or value logs appropriate error messages, but does not return failure status to the application. As a workaround, the application logger callback can check for logged messages that start with "Core-5626-" and trigger their own error handler. Note that setting up the logger callback has a clientd (see lbm_log()), so a shared structure can be established for the logger callback to communicate any matches it finds to the application thread calling lbm_config(). |
| 9964 | The use of Doxygen to generate the .NET documentation has resulted in the omission of the "LBMCS.chm" windows help package. |
| 9718 | The encryption feature does not implement elliptic curve encryption. Cipher suites with "ECDH", "ECDHE", and "ECDSA" cannot be used. Use "DHE" and "RSA" instead. |
| 4126 | When using LBT-IPC transports, 64-bit applications cannot interoperate with 32-bit applications. This includes router endpoint portals. |
| 6553, 6441 | You cannot use Unicode PCRE characters in wildcard receiver patterns on any system that communicates with a HP-UX or AIX system. |
| 6828, 6830, 6831 | There are severe restrictions on the use of NAT with UM. Normally, a DRO should be used with peer links to transit a NAT. However, there are very restrictive scenarios where Unicast Topic Resolution with |
| 7762 | When using Event Queues with the Java API on Mac OS X kernel 9.4, core dumps have occurred. Mac OS X kernel versions before 9.4 have not produced this behavior. |
| 7992, 7984, 7990 | The LBT-SMX transport does not support Topic Sequence Number Information (TSNI) messages. Thus, if LBT-SMX traffic routes through one or more DROs, and the original LBT-SMX source does not send messages regularly, remote receivers do not detect and notify the application of topic- level tail loss. Also, UM might not deliver midstream topic-level loss notifications in a timely manner. Remote receivers may also experience repeated transport disconnects and reconnects, and may miss Beginning Of Session (BOS) messages for the remote transport that carries data from the originating SMX source. Remote receivers may also experience head loss, similar to what would occur if the remote DRO had started after the originating SMX source starts sending. When configuring SMX sources to send through a DRO, ensure receiving applications do not rely upon these missing TSNI-related behaviors. |
| 8042 | It is possible for a thread deadlock to occur in the Java HotSpot Virtual Machine when initializing direct byte buffers. To avoid this bug, upgrade to Java 1.6.0_18 or later. For more information see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6791815. |
| 8266 | With Ultra Messaging on the AIX platform, you might encounter library linking problems due to an older version of ' |
| 8727, 8603 | You cannot use lbm_rcv_retrieve_transport_stats() to retrieve transport statistics from receivers with SMX sources. Instead, to retrieve these statistics use Automatic Monitoring. |
| 8735, 8323 | In AIX systems, you cannot send messages with a zero-length payload. |
| 8744 | If the lbmrd configuration file does not specify the version attribute within the ' |
| 8794, 8475 | Configuring sources with LBT-RU, source-side filtering, and adaptive batching might cause a crash. Note that adaptive batching is deprecated and will be removed from a future release. |
| 8820, 7368 | Setting transport_tcp_activity_method (receiver) to ' Also, any other configuration that causes a receiver create to fail triggers the fatal assert: ' |
| 9030, 8799 | You cannot set transport options in-line for lbmmon using a UM XML configuration file. Instead, use a Plain Text configuration file to set these options. |
The following open limitations apply to UMP and UMQ products.
| Change Request | Description |
|---|---|
| 11328 | The persistent source event LBM_SRC_EVENT_FLIGHT_SIZE_NOTIFICATION can deliver notifications out of order. This behavior is not considered a bug; applications must handle this. See Source Flight Notification Event for details and suggestions. |
| 11006 | Store can misbehave if a UM XML configuration file is supplied with settings that are invalid for the Store. Request that either the invalid settings be automatically corrected, or at least log a user-friendly error message. WORKAROUND: Take care to omit the following options from the Store's LBM configuration: |
| 9337 | It is requested that UM support running multiple instances of the Store as a Windows service on one host. Currently, service parameters are stored in the registry as fixed names, which prevents multiple instances from having different configuration files, CPU affinity, etc. |
| 10504 | When an LBM configuration file in XML format is used to set options based on topic name, those settings are not applied when a wildcard receiver matches a source with that topic name. For example, given: <topic topicname="abc"> <options type="receiver"> <option name="transport_lbtrm_send_naks" default-value="0"/> </options> </topic> If a wildcard receiver is created with pattern "ab.*", the above option will not be set on the underlying UM receiver. |
| 10676 | When a Store experiences packet loss (typically due to overload), it can delay or block the sending of stability ACKs to the Source until the loss is repaired or declared unrecoverable. Note: this issue was mistakenly listed as "fixed" when UM version 6.13 was released. |
| 10984 | In UM version 6.12 and beyond, a subscribing application that enables both XSP and Persistence has a small chance of encountering a crash during the Store registration process. |
| 10171 | A set of default operational configuration options do not satisfy Persistence recommendations. Hung registrations can result. Persistence users are advised to follow the recommendations in Preventing Store Registration Hangs. |
| 2982 | Receivers using event queues and Spectrum with UMP can experience a SIGSEGV while shutting down if events still exist on the event queue when the application deletes the event queue. 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. When the dispatch thread exits, you can continue with context deletion. |
| 4543 | When running a store on a Solaris machine, you may experience registration failures after a few minutes. The store repeatedly reports the error: |
| 4667 | Multi-transport Threads (MTT) do not support Persistence. Note that as of UM 6.11 MTT is removed, replaced by the new XSP feature, which provides improved multi-threading for receivers, and is compatible with Persistence. See Transport Services Provider (XSP). |
| 5841 | A UMP store daemon, umestored, may shut down unexpectedly if you enable proxy sources and UM is not able to create a transport session for a needed proxy source. For example, if the store is configured to use TCP transports for proxy sources (the default), and transport_tcp_port_high (context) minus transport_tcp_port_low (context) is 8, then when the 9th proxy source is created, UM will be unable to assign a port for that transport session. This is because UM will attempt to create up to transport_tcp_maximum_ports (context) transport sessions, which defaults to 10. transport_tcp_port_high (context) minus transport_tcp_port_low (context) must be at least transport_tcp_maximum_ports (context), and may need to be even larger if other applications and/or daemons on the same machines are configured to use ports from the same range. Informatica recommends configuring large port ranges appropriate to the transport type. |
| 6843 | An overly aggressive configuration on the source can cause the source to declare the store unresponsive while the source processes stability acknowledgements or confirmed delivery notifications or both. Using "strong RegIDs" prevents the source from sending messages until the store's source-activity-timeout expires on the store. After the activity timeout expires, the source can reregister. |
| 7014, 6840 | Java applications that create multiple receivers for the same topic in the same context may shut down unexpectedly when calling Dispose() if the topic is in a persistent data stream. Informatica recommends that you either avoid concurrent calls to Dispose() or use a single receiver for each topic and use application code to deliver messages to different callbacks. |
| 7937, 7771 | With liveness detection enabled for a UMP source and receiver; the receiver sends liveness keepalives to the source regardless of whether or not the receiver successfully registered with the Store. |
| 8728, 8151 | You cannot use receiver liveness detection for sources running on a SPARC-based system. |
| 8755 | For message consumption acknowledgements, you must not enable both acknowledgement batching and explicit acknowledgements simultaneously. However, if you do enable both, Ultra Messaging does not inhibit this configuration, and you see unexpected behavior. |
| 8870, 8768 | When using UMP with Windows, if you terminate a umestored process that was started from a command line window, it might corrupt data that is being written when the process is terminated. This does not apply to umestoreds, which runs as a service. To avoid this problem, ensure that sources are quiescent when stopping the Windows umestored process. |
The following open limitations apply to UMQ product.
| Change Request | Description |
|---|---|
| 11256 | There are cases where three brokers are configured for High Availability Installation and two brokers are brought down and then brought back up, UM can fail to re-synchronize the brokers. A clean from-scratch restart of the brokers is necessary to recover. |
| 9211 | Option umq_queue_activity_timeout (context) has no effect. |
| 9473, 9444 | The default paging or "cursor" settings for ActiveMQ might cause poor performance when multiple JMS durable subscribers are added to the same destination. This might cause logs messages similar to the following display: You can improve performance by changing the cursor used by durable subscribers to a vm cursor. However, you then lose the ability in the broker to page messages from memory to disk as memory usage increases. To change to vm cursors for subscribers, update the activemq.xml config file as shown in the following example: |
| 9474, 9446 | If a broker restarts and is later elected as active, previously assigned messages might be reassigned to consumers without being marked as redelivered. |
The following open limitations apply to the Dynamic Routing Option (DRO).
| Change Request | Description |
|---|---|
| 9718 | The encryption feature does not implement elliptic curve encryption. Cipher suites with "ECDH", "ECDHE", and "ECDSA" cannot be used. Use "DHE" and "RSA" instead. |
| 8736, 8082 | When shutting down and restarting a DRO, the DRO sometimes does not complete its shutdown fully, requiring that it be forcible killed. |
| Restriction | You cannot configure two endpoint portals on a DRO to have the same adjacent domain id. |
| Restriction | You cannot configure two peer portals on a DRO to connect to the same adjacent DRO. |
| Restriction | The DRO ignores UM Spectrum configuration options, which results in DROs forwarding all channel data without applying any filtering. See Spectrum. |