Updated the UM Gateway to append its log file by default instead of starting with a new log file everytime. You now have the option to remove any previous logging information from the UM Gateway log file at your discretion.
Implemented the following new Hot Failover features in the C API, the Java API and the .NET API.
Hot Failover for Wildcard Receivers
64-bit Hot Failover sequence numbers
Reduced size of Hot Failover message headers
Added lbm_hf_src_send_rcv_reset() to allow hot-failover
receivers to reset their state.
All example applications have been updated with these new features.
Compatibility Issues:
All normal Hot Failover (no gaps or optional messages) work fine across all versions.
New Receivers can handle intentional gap and optional messages from any version.
Pre-UM Core 5.1.1 receivers will not be able to handle intentional gap and optional messages from 5.1.1 sources.
Corrected a file descriptor problem that caused a fatal assert if a file descriptor was closed before it was cancelled within UM.
Fixed an issue with ordering Hot Failover intentional gaps that could, in rare cases involving loss, cause a segfault.
Resolved a Topic Resolution issue where certain inputs on the topic resolution socket could cause a buffer overrun, sometimes resulting in a crash.
Corrected the handling of socket errors, such as when a TCP socket could not be connected on a Unix system. This error results in the repetition of the following error message: lbm_socket_recv recv/recvfrom: (107) Transport endpoint is not connected.
Fixed an issue where bad input on a TCP stream could cause a buffer overrun, sometimes resulting in a crash.
Fixed an issue where a malformed context advertisement could cause a SEGV in certain cases.
Fixed several places where a malformed packet could cause parsing to go into an infinite loop or cause a fatal assert.
Changed the behavior of UM when it cannot locate the UM library. Previously, UM printed a warning. Now UM exits when it cannot locate the UM library.
Corrected lbm_msg_properties_get() to set the length
parameter to the actual length of the property, and to accept a length which is larger
than the required length of the property.
Corrected a problem with the UM Gateway that prevented a UMP store name from being properly resolved through two consecutive gateway peer hops.
Removed a number of fatal asserts in the message processing path that could cause a process to abort due to bad network input.
Fixed an issue when receiving fragmented messages containing message properties that could result in a fatal assert or incorrect message length. Although no fatal assert now occurs in this situation, UM ignores message properties if ordered_delivery is set to arrival order without reassembly (option value = 0).
Corrected a problem that caused boolean message property values to be inverted when retrieved with the .NET API.
Changed the parsing of the context, source and receiver scoped ume_session_id setting to allow octal, decimal, or hexadecimal values (e.g. 01, 1, 0x1, respectively). Parsing previously assumed that all strings were in hexadecimal.
When using the LBT-IPC Resource Manager tool to view the currently allocated IPC transport sessions, the Session ID is presented in the reverse byte order from what is given to the application via the source string.
Hot Failover is not currently supported with Multitransport 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 Multitransport Threads feature. Informatica does not support nor test the operation of Multitransport Threads across the UM Gateway.
Multitransport 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.
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 gateway failover, MIM, persistence, queuing, JMS, or Ultra Load Balancing. Gateway support of these features is in development.
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).
Although UMS 5.0 applications should run well with LBM 4.2 UM Gateways, all Gateways should always run the same version.
Operations Guide - Added the first edition of the Ultra Messaging® Operations Guide. This first edition contains monitoring strategies and troubleshooting information for supporting the operation of UMP. Future editions will include more problem resolution scenarios and error message descriptions.
Informatica has demonstrated operation with JDBC interfaces to MySQL™ and Oracle® databases. You may be able to use other JDBC databases, but Informatica has only tested with MySQL and Oracle.
Changed how the UMP store behaves when it runs out of disk space. Previously, the store continually logged error messages in the umestored log. Now the store logs a warning ([WARNING]: Store-5688-5265: [WARNING] aio_proactor GQCS: (112) There is not enough space on the disk) and exits when it can no longer write to disk.
Changed the severity level of the error message disk-cache file ends prematurely that appears in the UMP store log file when the store restarts. This is now only a warning.
Fixed a compatibility problem between the UMM GUI and Java Version 1.7. The AttributesDialog was using the same method name as the Dialog object.
Fixed an issue that could cause a UMP store daemon (umestored) to improperly delete receiver state information during shutdown.
Fixed a problem that caused sources (persistent publishers) to ignore message stability acknowledgements from stores marked as inactive. Sources now process message stability acknowledgements from inactive stores.
Corrected a problem with restarted stores that prevented the registration of proxy sources.
Fixed an issue with wildcard receivers using event queues where under certain circumstances messages would not be automatically deleted. In this case, UMP does not send delivery confirmations to the source.
UMP stores sometimes fail to send message stability acknowledgements to sources for messages sent while the store was being reported unresponsive by the source. Informatica is investigating this problem.
A UMP store daemon, umestored, may crash if you enable proxy sources and the daemon is configured with a very restrictive port range, ( transport_lbtrm_multicast_address_low - transport_lbtrm_multicast_address_high, transport_tcp_port_low - transport_tcp_port_high, etc.). Informatica recommends that you use a wide port range (at least 1000 ports) in your UM configuration file if you enable proxy sources for umestored. Informatica is investigating this problem.
The UMP store daemon, umestored, stops persisting messages to disk if the store has a loss condition which is not resolved prior to an EOS event. As a workaround, Informatica recommends that you enable receiver delivery_control_loss_check_interval 2500 in the UM configuration file, not the umestored XML configuration file. The value of 2500 assumes the default *_nak_generation_interval. See Preventing Undetected Loss for more information. Informatica is investigating this problem.
If a source application stops and you restart it before the receiving application declares the EOS event, the receiving application does not send a new keepalive message. The source requires a keepalive message in order to declare a receiver "alive." Informatica is investigating this problem.
Receivers using event queues and Spectrum with UMP 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. Informatica 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.
JMS Queue Browser - Added support for this JMS specification for the C API, the Java API and the JMS API. The .NET API will be supported in a future release. The JMS Queue Browser allows the following. (See also Queue Browser.)
Retrieving a list of topics and application sets from a running queue daemon via the
new LBMContext.queueTopicList() Java API call.
Retrieving a list of currently-enqueued message IDs from a running queue daemon via
the new LBMReceiver.queueMessageList() Java API call.
Retrieving specific messages by message ID from a running queue daemon via the new
LBMReceiver.queueMessageRetrieve() Java API call.
Added the following Ultra Messaging configuration options to support the JMS Queue Browser.
Added the umestored daemon option, lbm-password-file and the queue option, require-client-authentication, to support the requirement for clients to authenticate with the queue before performing Queue Browsing actions such as, listing all topics within a queue or retrieving a specific message by ID.
Added two new return values for lbm_geterr().
LBM_ENO_QUEUE_REG returns when a message send by source, which is connected to both a store and a queue, fails because the source has lost registration with the queue.
LBM_ENO_STORE_REG returns when a message send by source, which is connected to both a store and a queue, fails because the source has lost registration with the store.
LBM_EUMENOREG has been changed to return when a message send by a source fails because the source has lost registration with either a single store, a single queue or both a store and a queue with which the source was simultaneously connected.
Resolved the Known Issue: When using multiple sending threads, a Queue (umestored) can deadlock. As a workaround, Informatica suggests that you specify only a single sending thread. Note that 1 sending thread is the current default. You can now use multiple sending threads within a queue.
Fixed a race condition that could cause a reclaim source event to be delivered before all stability source events were delivered for a particular UMQ message. This occurred if the message was sent to a queue configured with more than one queue group. (Sending to a single group containing multiple queue instances was not affected.)
Corrected an issue in JMS when sending messages larger than 64K resulted in the error message, Core-5688-4383: JNI detected an exception in (jni_src_cb:423):java.lang.NullPointerException.
The UM configuration file specified for a queue cannot also contain source attributes for a store such as, source ume_store 127.0.0.1:14567 or source ume_store_name NYstore2.
| Prev | Home | Next |
| Release UMS 5.3 / UMP 5.3 / UMQ 5.3 - June - 2012 | Release UMS 5.2.1 / UMP 5.2.1 / UMQ 5.2.1 - February 2012 |
Copyright (c) 2004 - 2014 Informatica Corporation. All rights reserved.