Sometimes an application receives and acts upon retransmit response information intended for a different application. This solution makes retransmit requests more unique to the application issuing the request to prevent potential cross-contamination of retransmit response information during application restarts.
A source sends Late Join responses with an unintialized header field, which can cause a fatal assertion on the requesting receiver.
When calling lbm_src_send() from the context thread inside a lbm_timer callback, a source can freeze when it hits rate limiter limits, requiring an application restart.
Fatal assertion [dest] at line 481 in ../../../../src/lib/lbm/lbmrxrctlr.c in a UM application or daemon if the application receives malformed data on a UM tcp socket or under other extreme edge case conditions.
Configurations with multiple queue instances (slaves) can lead to inconsistent states, which can cause message loss, crashes or an inability to restart without removal of files (also resulting in message loss). For guidance, see Section 2.2.8 of the Ultra Messaging Guide for Persistence and Queuing.
A queue instance may crash with the following log message if allow-queue-browsing is set to 1: [EMERGENCY]: FATAL: failed assertion [sinc_q_msg_info_node!=NULL] at line 5998 in ../../../../src/stored/umqueue.c.
UMQ flags reassigned messages upon delivery, but when a queue restarts, UMQ may re-deliver some messages without flagging them.
Queues may occasionally crash upon restart if the queue option forwarding-behavior is set to store-while-forward. Set this option to store-then-forward.
A queue instance may crash with the following log message if messages are of 0 length: [EMERGENCY]: FATAL: failed assertion [msg->lbm_msg!=NULL] at line 3896 in ../../../../src/stored/umqsinc.c
Prev | Home | Next |
UMS / UMP / UMQ Change Log | Release UMS 5.3.5 / UMP 5.3.5 / UMQ 5.3.5 - November - 2013 |
Copyright (c) 2004 - 2014 Informatica Corporation. All rights reserved.