A Delivery Controller is a receiver-side object created for each source identified by the receiver through topic resolution. A delivery controller performs the following.

Delivers messages to multiple receivers subscribed to the same topic.
Orders received topic messages if ordered_delivery (receiver) is set to 1 (default). This option applies to LBT-RU and LBT-RM transports.
Determines unrecoverable loss and burst loss events for the receiver's topic over LBT-RU and LBT-RM transports.

Unlike the loss depicted in LBT-RM, the image below illustrates how a receiver's Delivery Controller detects unrecoverable tail loss on a topic.

In a non-tail-loss case, the TSNI messages shown above can also be application messages. The point being that the delivery controller does not send NAKs, and instead waits for a transport_lbtrm_nak_generation_interval (receiver) period after the point where the gap is detected (either by an application message or by a TSNI). During that wait interval, the transport may deliver retransmitted message. If not, it is the reception of another message or TSNI after the NAK generation interval expires which triggers delivery of the unrecoverable loss event.

Note: if the source disables TSNIs, tail loss can go undetected unless and until another application is sent on that topic.

Burst Loss <-

This section is moved to the Concepts Guide. See Burst Loss.

Reference <-

channel_map_tablesz (receiver) <-

: The size of the hash table that the receiver uses to store channel subscriptions.

: A larger table means more channels can be stored more efficiently, but takes up more memory. A smaller table uses less memory, but costs more CPU time for large numbers of channel subscriptions.

: See Spectrum for more information.

Scope:	receiver
Type:	size_t
Default value:	10273
When to Set:	Can only be set during object initialization.

delivery_control_loss_check_interval (receiver) <-

: This controls the interval between mandatory topic loss checks for a receiver. See Preventing Undetected Unrecoverable Loss.

: A value of 0 turns this loss check off.

Scope:	receiver
Type:	lbm_ulong_t
Units:	milliseconds
Default value:	0 (disabled)
When to Set:	Can only be set during object initialization.

delivery_control_maximum_burst_loss (receiver) <-

: This controls the size of a topic sequence number gap past which the gap is declared a "burst loss". The minimum usable value is 2.

: See Burst Loss for a detailed explanation of burst loss and its semantics.

Attention: Informatica recommends disabling "burst loss" by setting this option to a very large number, perhaps 1,000,000,000.

Note: the burst loss control takes priority over all recovery methods. For example, if the receiver is reading a persistent stream and OTR is enabled, a gap longer than delivery_control_maximum_burst_loss will immediately declare the gap as unrecoverable without even trying to use OTR to recover. If message integrity is a high priority, delivery_control_maximum_burst_loss should be set to a very large value.

Scope:	receiver
Type:	lbm_uint_t
Units:	number of messages (fragments)
Default value:	1024
When to Set:	Can only be set during object initialization.

delivery_control_maximum_total_map_entries (context) <-

: The maximum number of messages that can be buffered in the Delivery Controller's Order Map.

: When the number of messages stored in a Delivery Controller's Order Map is exceeded, unrecoverable loss is signaled for the oldest gaps and older data is delivered until the Order Map size is below delivery_control_maximum_total_map_entries.

: A value of 0 implies no maximum and allows unbounded growth of the Delivery Controller's Order Map.

: See Delivery Controller for a description of the Order Map. Also see otr_message_caching_threshold (receiver).

: For a persistent receiver that has OTR enabled, this option is typically set to 0 (no limit). This is because the option retransmit_message_caching_proximity (receiver) prevents unbounded growth of the Order Map.

Note: Although this option is context scoped, understand that there is a separate Order Map for each Delivery Controller. Those Order Maps are sized independently.

Scope:	context
Type:	size_t
Units:	map entries
Default value:	200000
When to Set:	Can only be set during object initialization.

delivery_control_message_batching (context) <-

: Controls whether or not to use receive-side batching, which can improve receiver throughput when using event queues and/or Java, but might add latency in some cases.

: See Receive-Side Batching.

Warning: This feature is incompatible with XSP.

Scope:	context
Type:	int
When to Set:	Can only be set during object initialization.

Value

Description

1

Receive-side batching is enabled.

0

Receive-side batching is disabled. Default for all.

mim_delivery_control_loss_check_interval (context) <-

: This controls the interval between mandatory loss checks for MIM.

: A value of 0 turns this loss check off.

: See Multicast Immediate Messaging for general information about MIM.

Scope:	context
Type:	lbm_ulong_t
Units:	milliseconds
Default value:	0 (disabled)
When to Set:	Can only be set during object initialization.
Version:	This option was implemented in LBM 4.2

null_channel_behavior (receiver) <-

: Behavior desired when a message without channel information (i.e. a standard UM message) is received by UM.

: See Spectrum for more information.

Scope:	receiver
Type:	int
When to Set:	Can only be set during object initialization.

String value	Integer value	Description
"deliver"	LBM_RCV_TOPIC_ATTR_CHANNEL_BEHAVIOR_DELIVER_MSGS	Messages sent without channel information will be delivered to the callback specified upon receiver creation. Default for all.
"discard"	LBM_RCV_TOPIC_ATTR_CHANNEL_BEHAVIOR_DISCARD_MSGS	Messages sent without channel information will be discarded.

source_notification_function (receiver) <-

: Callback functions (and associated client data pointer) that are called when a UM receiver creates or deletes a delivery controller associated with a source.

: A receiver can have zero or more Delivery Controllers. Each Delivery Controller maintains internal state for a specific source that the receiver has joined. The application callbacks associated with this configuration option allow the application to track the receiver joining and exiting of the individual source.

: For the creation function, the application has the ability to set the source client data pointer to be used in each message received from the source.

: Contrast this with resolver_source_notification_function (context).

: This callback is called by the context thread and can not use an event queue. Therefore the callback function used should not block or it will delay reception of latency-sensitive messages.

Scope:	receiver
Type:	lbm_rcv_src_notification_func_t
Default value:	NULL
When to Set:	Can only be set during object initialization.
Config File:	Cannot be set from an UM configuration file.

unrecognized_channel_behavior (receiver) <-

: Behavior desired when a message with channel information for a channel not in the receiver's set of subscribed channels is received by UM.

: See Spectrum for more information.

Scope:	receiver
Type:	int
When to Set:	Can only be set during object initialization.

String value

Integer value

Description

"deliver"

LBM_RCV_TOPIC_ATTR_CHANNEL_BEHAVIOR_DELIVER_MSGS

Messages sent with channel information for a channel not in the receiver's set of subscribed channels will be delivered to the callback specified upon receiver creation. Default for all.

"discard"

LBM_RCV_TOPIC_ATTR_CHANNEL_BEHAVIOR_DISCARD_MSGS

Messages sent with channel information for a channel not in the receiver's set of subscribed channels will be discarded.