7. Release UMS 5.3.1 / UMP 5.3.1 / UMQ 5.3.1 - September - 2012

Ultra Messaging® Manager has been added to UMS. Previously this feature was only available with UMP and UMQ This 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.

The UM log message, Core-5688-1866, has been changed from Warning to an INFO message.

Performance has been improved by converting locks for srcs and imbq to spinlocks in the Windows code. The environment variable LBM_WINDOWS_RATELIMITER_SPINLOCK_COUNT sets the spinlock count. InitializeCriticalSection will be used if the variable is not set. InitializeCriticalSectionAndSpinCount will be used when the variable is set.

Fixed a problem in the .NET API that caused an exception when assigning a UNICODE string to the LBMReceiver topic attribute.

Fixed an issue on AIX platforms that resulted in the message selector string unknown to be parsed incorrectly as true.

Corrected a problem in PDM that caused out of bounds exceptions when calling setValue(PDMMessage []) after modifying a PDM message that is part of a MESSAGE_ARR field within another serialized PDM message. After modifying a PDM message that is member of a MESSAGE_ARR type field, You must call setValue(PDMMessage []) to allow PDM to update the internal version of the message.

Changed the fd_management_type epoll so that it no longer asserts when closing STDIN.

Corrected a problem with multiple receivers for a topic in adjacent Topic Resolution Domains serviced by a UM Gateway that caused topic interest to not be properly represented in the adjacent domains. This resulted in remote receivers not getting the expected message data.

Fixed a problem with Message Selectors which could result in a failure when comparing NaN values.

Fixed a problem that caused receivers to get corrupted packets when the source does a non-blocking send over TCP without an event queue.

Fixed a problem that could result in the error log message, CoreApi-5688-3233: TCP server listen: (98) even if TCP ports are still available.

Fixed an issue with PDM that caused a segfault when using different message versions and a different number of fields. This correction was applied to the C API, the Java API and the .NET API.

Reversed a UM 5.3 bug fix because it was shown to produce receiver deafness across a UM Gateway. The UM 5.3 bug fix change log entry appears below.

Added additional validation logic to Topic Resolution advertisement (TIR) processing to prevent malformed packets from causing an invalid memory access, potentially leading to a crash.

Corrected a problem that now allows Late Join to work properly when using the network_compatibility_mode.

Fixed an issue that caused a JVM crash if multiple contexts were created with the same port.

Corrected problems with uninitialized attribute values for context, source, receiver, and event queue attributes.

Fixed a problem with sending and receiving message properties between platforms using different endian formats.

JMS now creates its own MessageID rather than using one based on the underlying JMS system. Also added are UM-layer functions that create a JMSMessageId, to add compatibility between JMS and the other UM senders/receivers.

Fixed a problem that exposed LBMC to possible Denial of Service (DoS) attacks.

Fixed a problem that caused a fatal assert Core-5688-7: FATAL: failed assertion that could happen when setting network_compatibility_mode.

Fixed another problem that sometimes caused fatal assert Core-5688-7: FATAL: failed assertion. UM now creates a unique mutex name that results in successful creation of a named Mutex, thus avoiding the assert.

Retrieving plain text (not XML) configurations files via an http or ftp request is limited to configuration files of 1K in size. Configuration files over 1K will result in an error: error reading config file. Informatica will fix this in a future release. A workaround is to convert the plain text configuration file to an XML configuration file.

The .NET API does not support message selectors with unicode symbols and causes receiver creation to fail.

UM does not support the use of Unicode PCRE characters in wildcard receiver patterns on any system that communicates with a HP-UX or AIX system.

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.

The notice Core-5688-3847 can be received when setting the fd_management_type to wincompport only. The occurrence of this notice has been changed so that after the first 5 occurrences, the notice only prints every 10,000th consecutive occurrence. An example of this notice: Core-5688-3847: NOTICE: wincport 000000000893BE90 line 4615 WSA err 10061, Connection refused (peer 10.29.3.56:23005) (op 4)

Added identifying information such as RegID, store name and store index to registration error responses.

The UM persistent store has been modified to retain state and cache files when the store restarts that may be corrupted instead of deleting them. The store renames these files to regid-state/cache.pid.month_day_year. These files remain indefinitely in the same cache/state directories as specified in the store's XML configuration file.

Corrected a problem that prevented a restarted store from correctly persisting the receiver lifetime timeouts. NOTE: Be sure to delete the old state files when upgrading your system to this release.

Corrected a problem where a restarted umestored process generated unneeded log messages upon encountering empty cache files.

Corrected a problem that caused a memory store to attempt to late-join messages from the source that the repository has already received. This occurred after the source re-registers with the store. Now the repository only initiates Late Join for messages that it has not received.

Corrected a potential memory corruption issue in the store daemon (umestored), that was introduced in UM 5.3. The memory corruption could occur when the store, upon startup, detects and deletes a corrupt or empty cache file.

Corrected a condition where a UMP store configured with Receiver-paced Persistence and a repository-type of disk could stop persisting new data if messages at the end of the cache file were not consumed by all registered receivers and there was available space at the beginning of the cache file.

Corrected a problem with receivers registering with Quorum/Consensus stores that resulted in the log message: Core-5688-3113: NOTICE: UME receiver "name" source "LBTRM:10.29.3.16:14390:228383bb:224.10.10.10:14400" registration consensus sequence number 0 less than highest seen 51c. Using consensus. Receivers now properly register with all stores in the group.

Fixed an issue that would incorrectly allow multiple receivers on the same topic with the same ume_session_id to both be registered with the store simultaneously.

Fixed a problem that caused a large delay in receiver re-registration if a source goes down and the store creates a proxy source or if the source simply restarts.

Fixed the store daemon (umestoreds) shutdown issue on Microsoft® Windows® so that the store does not log an error message when the store shutdown command is issued via the Service Control Manager (SCM).

Corrected a problem with store initialization that could cause a segfault during long running store recoveries.

Corrected a problem with restarted stores that produced the error log message, LOG Level 5: Core-5688-3167: WARNING: received keepalive from non-active store 0. Now a store does not send keepalives to a source if the source is not registered to the store.

Corrected a problem where a receiver on the opposite side of a gateway did not receive a persistent message until a persistent source in the same context sent one.

Creating multiple receivers on the same topic in the same context using the Java API may result in a crash when calling Dispose() if the topic is a persistent data stream. It is recommended to either protect the calls to Dispose() to prevent concurrent calls or use a single receiver per topic and use application code to deliver messages to different callbacks. This will be fixed in a future release.

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.

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.

Added umq_command_outstanding_maximum to control the maximum number of outstanding UMQ commands (registrations, de-registrations, indexed queuing commands, message list commands, etc.) a client is allowed at one time. Outstanding commands are not yet acknowledged by the queue.

Updated the JMS example, Reply.java, to fix a case where it would fail to reply to a native source that did not correctly set the JMSReplyTo property. Also, updated an internal exception to more cleanly handle the case where an application attempts to send to a null destination.

Fixed a problem that could cause a persistent UMQ queue daemon (umestored) to occasionally fail to start up if it previously had registered receivers that used UMQ session IDs.

Fixed an issue that could cause a non-UMQ context receiving a unicasted UMQ control message to crash. This only happened if a non-UMQ context was created and re-used a request port from a previously running UMQ context.

Fixed a small memory leak during the clean shutdown of a slave instance of the UMQ queue daemon (umestored). This leak had no impact during normal operation.

Fixed a problem that could cause UMQ clients to crash if they had over 65535 currently outstanding queue commands. This many queue commands could accumulate if you performed a very large message retrieve command or attempted to register tens of thousands of clients with a queue in a very short period of time.

Fixed a problem that could cause a persistent, disk queue daemon (umestored) to sometimes fail to restart with a anode!=NULL assertion.

Corrected problems with UMQ session IDs and observer receivers ( umq_queue_participation = 2) that could cause the queue daemon (umestored) to crash upon shutdown if multiple observer receivers on the same topic with different session IDs were used.

Fixed a problem with how Ultra Messaging JMS tracks sources within a context that resulted in sources on a topic being created multiple times.

Corrected a problem in Ultra Messaging JMS that prevented multiple MessageProducers with the same topic on the same connection.

Corrected a problem that caused a crash when UMQ Ultra Load Balancing receivers were assigned incorrect Application IDs during registration.

Fixed an issue that resulted in received message timestamp values to be set to 0 (zero) for UMQ messages.

Fixed a problem that caused the JMS redelivered flag to not be set on redelivered messages when UMQ was in linear mode.

Added the following new constants to lbm.h, lbm.java and lbm.cs to aid in interoperability with Ultra Messaging JMS.

LBM_TEXTMESSAGE =        0;
LBM_BYTEMESSAGE =        1;
LBM_MAPMESSAGE =         2;
LBM_MESSAGE =            3;
LBM_OBJECTMESSAGE =      4;
LBM_STREAMMESSAGE =      5;
LBM_JMSDeliveryMode =    "JMSDeliveryMode";
LBM_JMSExpiration =      "JMSExpiration";
LBM_JMSPriority =        "JMSPriority";
LBM_JMSMessageID =       "JMSMessageID";
LBM_JMSTimestamp =       "JMSTimestamp";
LBM_JMSCorrelationID =   "JMSCorrelationID";
LBM_JMSType =            "JMSType";
LBM_JMSRedelivered =     "JMSRedelivered";
LBM_LBMMessageType =     "LBMMessageType";
LBM_JMSTopicType =       "JMSTopicType";
LBM_JMSReplyToName =     "JMSReplyToName";
LBM_JMSReplyToWildcard = "JMSReplyToWildcard";
LBM_JMSReplyToType =     "JMSReplyToType";
               

The method, getJMSRedelivered for a message always returns false for redelivered messages when using Queue Session IDs along with the topic's message-reassignment-timeout set to 0 (zero).

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.

When servicing large message retrieval requests from a queue browser, the queue may become busy enough that the receiver perceives it as unresponsive and re-registers with the queue, canceling the message retrieval request. Informatica recommends limiting large message retrievals to 1000 messages at a time, waiting for each retrieval to finish before beginning the next retrieval request