Configuration Guide=en
User Manual:
Open the PDF directly: View PDF .Page Count: 421
Ultra Messaging (Version 6.12)
Configuration Guide
Copyright (C) 2004-2019, Informatica Corporation. All Rights Reserved.
Contents
1
Introduction
1.1
5
Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1.1
Assignment Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1.2
Assignment Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.1.3
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.4
Which Method Should I Use? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.1.5
Host Name Resolution
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.1.6
Configuration Files
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Plain Text Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2.1
Reading Plain Text Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.3
Plain Text Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.4
XML Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.4.1
Reading XML Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.4.2
Using XML Configuration Files With a UM Application . . . . . . . . . . . . . . . . . . . . .
11
1.4.3
XML Configuration File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.4.4
Merging Multiple XML Configuration Files
12
1.2
2
. . . . . . . . . . . . . . . . . . . . . . . . . . .
XML Configuration File Elements
15
2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4
CONTENTS
2.14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.20
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.21
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3
3.1
Sample XML Configuration File
35
Using the Order and Rule XML Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4
XML Configuration File DTD
39
5
Attributes Objects
41
5.1
Creating An Attributes Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2
Setting an Option from a Binary Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.1
Setting an Option from Arrays of Binary Values . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.3
Setting an Option from a String Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.4
Getting an Option as a Binary Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.5
Getting an Option as a String Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.6
Deleting an Attributes Object
45
6
6.1
6.2
7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Access to Current Operating Options
47
Retrieving Current Option Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
6.1.1
Getting Current Option as a Binary Value . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
6.1.2
Getting Current Option as a String Value . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Modifying Current Option Values
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.2.1
Setting Current Option from a Binary Value . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2.2
Setting Current Option from a String Value . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Example Configuration Scenarios
51
7.1
Highest Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
7.2
Lowest Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
7.3
Creating Multicast Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
7.4
Disabling Aspects of Topic Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
7.4.1
Disabling Topic Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.4.2
Disabling Receiver Topic Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.4.3
Disabling Wildcard Topic Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.4.4
Disabling Store (Context) Name Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.4.5
All But the Minimum Topic Resolution Traffic . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Unicast Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
7.5
CONTENTS
5
7.6
Re-establish Pre-4.0 Topic Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
7.7
Re-establish Pre-LBM 3.3 (Pre-UME 2.0) Port Defaults . . . . . . . . . . . . . . . . . . . . . . . . .
55
7.8
Configure New Port Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
8
Interrelated Configuration Options
57
8.1
Preventing NAK Storms with NAK Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
8.2
Preventing Tail Loss With TSNI and NAK Interval Options . . . . . . . . . . . . . . . . . . . . . . .
58
8.3
Preventing IPC Receiver Deafness With Keepalive Options
. . . . . . . . . . . . . . . . . . . . . .
58
8.4
Preventing Erroneous LBT-RM/LBT-RU Session Timeouts . . . . . . . . . . . . . . . . . . . . . . .
59
8.5
Preventing Errors Due to Bad Multicast Address Ranges . . . . . . . . . . . . . . . . . . . . . . . .
60
8.6
Preventing Store Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
8.7
Preventing ULB Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
8.8
Preventing Unicast Resolver Daemon Timeouts
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
8.9
Preventing Undetected Late Join Loss
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
8.10
Preventing Undetected Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
8.11
Preventing Store Registration Hangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
9
General Configuration Guidelines
65
9.1
Case Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
9.2
Specifying Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
9.2.1
Interface Device Names and XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
9.3
Socket Buffer Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
9.4
Port Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
9.4.1
Ephemeral Ports
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
9.4.2
Network VS Host Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Reference Entry Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
9.5
10 Special Notes
69
10.1
Configuring Multi-Homed Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
10.2
Traversing a Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
11 Major Options
71
11.1
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
11.1.1 broker (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
11.1.2 compatibility_include_pre_um_6_0_behavior (context) . . . . . . . . . . . . . . . . . . . . .
72
11.1.3 context_event_function (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
11.1.4 context_name (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
11.1.5 datagram_acceleration_functions (context) . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
11.1.6 default_interface (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
11.1.7 fd_management_type (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
11.1.8 message_selector (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6
CONTENTS
11.1.9 multiple_receive_maximum_datagrams (context) . . . . . . . . . . . . . . . . . . . . . . . .
75
11.1.10 operational_mode (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
11.1.11 operational_mode (xsp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
11.1.12 ordered_delivery (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
11.1.13 receiver_callback_service_time_enabled (context) . . . . . . . . . . . . . . . . . . . . . . .
78
11.1.14 resolver_source_notification_function (context) . . . . . . . . . . . . . . . . . . . . . . . . .
78
11.1.15 source_event_function (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
11.1.16 source_includes_topic_index (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
11.1.17 transport (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
11.1.18 transport_demux_tablesz (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
11.1.19 transport_mapping_function (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
11.1.20 transport_session_multiple_sending_threads (context) . . . . . . . . . . . . . . . . . . . . .
82
11.1.21 transport_session_single_receiving_thread (context) . . . . . . . . . . . . . . . . . . . . . .
82
11.1.22 transport_source_side_filtering_behavior (source) . . . . . . . . . . . . . . . . . . . . . . .
83
11.1.23 transport_topic_sequence_number_info_active_threshold (source) . . . . . . . . . . . . . .
84
11.1.24 transport_topic_sequence_number_info_interval (source) . . . . . . . . . . . . . . . . . . .
84
11.1.25 transport_topic_sequence_number_info_request_interval (receiver) . . . . . . . . . . . . . .
85
11.1.26 transport_topic_sequence_number_info_request_maximum (receiver)
. . . . . . . . . . . .
85
11.1.27 use_extended_reclaim_notifications (source) . . . . . . . . . . . . . . . . . . . . . . . . . .
86
11.1.28 zero_transports_function (xsp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
12 UDP-Based Resolver Operation Options
89
12.1
Minimum Values for Advertisement and Query Intervals . . . . . . . . . . . . . . . . . . . . . . . .
89
12.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
12.2.1 disable_extended_topic_resolution_message_options (context) . . . . . . . . . . . . . . . .
90
12.2.2 resolution_no_source_notification_threshold (receiver) . . . . . . . . . . . . . . . . . . . . .
90
12.2.3 resolution_number_of_sources_query_threshold (receiver) . . . . . . . . . . . . . . . . . .
91
12.2.4 resolver_advertisement_maximum_initial_interval (source)
. . . . . . . . . . . . . . . . . .
91
12.2.5 resolver_advertisement_minimum_initial_duration (source) . . . . . . . . . . . . . . . . . .
92
12.2.6 resolver_advertisement_minimum_initial_interval (source) . . . . . . . . . . . . . . . . . . .
92
12.2.7 resolver_advertisement_minimum_sustain_duration (source) . . . . . . . . . . . . . . . . .
93
12.2.8 resolver_advertisement_send_immediate_response (source) . . . . . . . . . . . . . . . . .
93
12.2.9 resolver_advertisement_sustain_interval (source) . . . . . . . . . . . . . . . . . . . . . . .
94
12.2.10 resolver_cache (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
12.2.11 resolver_context_name_activity_timeout (context) . . . . . . . . . . . . . . . . . . . . . . .
95
12.2.12 resolver_context_name_query_duration (context) . . . . . . . . . . . . . . . . . . . . . . .
95
12.2.13 resolver_context_name_query_maximum_interval (context) . . . . . . . . . . . . . . . . . .
96
12.2.14 resolver_context_name_query_minimum_interval (context) . . . . . . . . . . . . . . . . . .
96
12.2.15 resolver_datagram_max_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
12.2.16 resolver_domain_id_active_propagation_timeout (context) . . . . . . . . . . . . . . . . . . .
98
CONTENTS
7
12.2.17 resolver_initial_advertisement_bps (context) . . . . . . . . . . . . . . . . . . . . . . . . . .
99
12.2.18 resolver_initial_advertisements_per_second (context) . . . . . . . . . . . . . . . . . . . . . 100
12.2.19 resolver_initial_queries_per_second (context) . . . . . . . . . . . . . . . . . . . . . . . . . 100
12.2.20 resolver_initial_query_bps (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12.2.21 resolver_query_maximum_initial_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . 101
12.2.22 resolver_query_minimum_initial_duration (receiver) . . . . . . . . . . . . . . . . . . . . . . 102
12.2.23 resolver_query_minimum_initial_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . 102
12.2.24 resolver_query_minimum_sustain_duration (receiver) . . . . . . . . . . . . . . . . . . . . . 103
12.2.25 resolver_query_sustain_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
12.2.26 resolver_receiver_map_tablesz (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
12.2.27 resolver_send_final_advertisements (source)
. . . . . . . . . . . . . . . . . . . . . . . . . 104
12.2.28 resolver_send_initial_advertisement (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.2.29 resolver_service (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.2.30 resolver_source_map_tablesz (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.2.31 resolver_string_hash_function (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
12.2.32 resolver_string_hash_function_ex (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
12.2.33 resolver_sustain_advertisement_bps (context) . . . . . . . . . . . . . . . . . . . . . . . . . 109
12.2.34 resolver_sustain_advertisements_per_second (context) . . . . . . . . . . . . . . . . . . . . 110
12.2.35 resolver_sustain_queries_per_second (context) . . . . . . . . . . . . . . . . . . . . . . . . 110
12.2.36 resolver_sustain_query_bps (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
12.2.37 resolver_unicast_activity_timeout (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
12.2.38 resolver_unicast_change_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
12.2.39 resolver_unicast_check_interval (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . 112
12.2.40 resolver_unicast_force_alive (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
12.2.41 resolver_unicast_ignore_unknown_source (context) . . . . . . . . . . . . . . . . . . . . . . 113
12.2.42 resolver_unicast_keepalive_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 114
13 Multicast Resolver Network Options
13.1
115
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
13.1.1 resolver_multicast_address (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
13.1.2 resolver_multicast_incoming_address (context)
. . . . . . . . . . . . . . . . . . . . . . . . 116
13.1.3 resolver_multicast_incoming_port (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
13.1.4 resolver_multicast_interface (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
13.1.5 resolver_multicast_outgoing_address (context) . . . . . . . . . . . . . . . . . . . . . . . . . 117
13.1.6 resolver_multicast_outgoing_port (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13.1.7 resolver_multicast_port (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13.1.8 resolver_multicast_receiver_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . 119
13.1.9 resolver_multicast_ttl (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
14 Unicast Resolver Network Options
14.1
121
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
8
CONTENTS
14.1.1 resolver_unicast_daemon (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
14.1.2 resolver_unicast_interface (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
14.1.3 resolver_unicast_port_high (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
14.1.4 resolver_unicast_port_low (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
14.1.5 resolver_unicast_receiver_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . 124
15 Transport TCP Network Options
125
15.1
TCP Transport Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
15.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
15.2.1 transport_tcp_interface (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
15.2.2 transport_tcp_interface (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
15.2.3 transport_tcp_maximum_ports (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
15.2.4 transport_tcp_port (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
15.2.5 transport_tcp_port_high (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
15.2.6 transport_tcp_port_low (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
16 Transport TCP Operation Options
16.1
131
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
16.1.1 transport_session_maximum_buffer (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 131
16.1.2 transport_tcp_activity_method (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
16.1.3 transport_tcp_activity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
16.1.4 transport_tcp_activity_timeout (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
16.1.5 transport_tcp_coalesce_threshold (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.1.6 transport_tcp_datagram_max_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.1.7 transport_tcp_dro_loss_recovery_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . 135
16.1.8 transport_tcp_exclusiveaddr (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
16.1.9 transport_tcp_listen_backlog (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
16.1.10 transport_tcp_multiple_receiver_behavior (source) . . . . . . . . . . . . . . . . . . . . . . . 136
16.1.11 transport_tcp_multiple_receiver_send_order (source) . . . . . . . . . . . . . . . . . . . . . 137
16.1.12 transport_tcp_nodelay (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
16.1.13 transport_tcp_receiver_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . . . 139
16.1.14 transport_tcp_reuseaddr (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
16.1.15 transport_tcp_sender_socket_buffer (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 140
16.1.16 transport_tcp_use_session_id (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
17 Transport LBT-RM Network Options
143
17.1
LBT-RM Transport Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
17.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
17.2.1 transport_lbtrm_destination_port (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
17.2.2 transport_lbtrm_multicast_address (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 145
17.2.3 transport_lbtrm_multicast_address_high (context) . . . . . . . . . . . . . . . . . . . . . . . 145
CONTENTS
9
17.2.4 transport_lbtrm_multicast_address_low (context) . . . . . . . . . . . . . . . . . . . . . . . . 146
17.2.5 transport_lbtrm_source_port_high (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 146
17.2.6 transport_lbtrm_source_port_low (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
18 Transport LBT-RM Reliability Options
149
18.1
LBT-RM Datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
18.2
LBT-RM Source Ignoring NAKs for Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
18.3
LBT-RM Receiver Suppressing NAK Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
18.4
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
18.4.1 transport_lbtrm_ignore_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
18.4.2 transport_lbtrm_nak_backoff_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . 152
18.4.3 transport_lbtrm_nak_generation_interval (receiver)
. . . . . . . . . . . . . . . . . . . . . . 152
18.4.4 transport_lbtrm_nak_initial_backoff_interval (receiver) . . . . . . . . . . . . . . . . . . . . . 153
18.4.5 transport_lbtrm_nak_suppress_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . 153
18.4.6 transport_lbtrm_receiver_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . . 154
18.4.7 transport_lbtrm_send_naks (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
18.4.8 transport_lbtrm_source_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . . 155
18.4.9 transport_lbtrm_transmission_window_limit (source) . . . . . . . . . . . . . . . . . . . . . . 155
18.4.10 transport_lbtrm_transmission_window_size (source) . . . . . . . . . . . . . . . . . . . . . . 156
19 Transport LBT-RM Operation Options
19.1
157
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
19.1.1 transport_lbtrm_activity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
19.1.2 transport_lbtrm_coalesce_threshold (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 159
19.1.3 transport_lbtrm_data_rate_limit (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
19.1.4 transport_lbtrm_datagram_max_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . 160
19.1.5 transport_lbtrm_preactivity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . 160
19.1.6 transport_lbtrm_rate_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
19.1.7 transport_lbtrm_receiver_timestamp (context) . . . . . . . . . . . . . . . . . . . . . . . . . 162
19.1.8 transport_lbtrm_recycle_receive_buffers (context) . . . . . . . . . . . . . . . . . . . . . . . 163
19.1.9 transport_lbtrm_retransmit_rate_limit (context) . . . . . . . . . . . . . . . . . . . . . . . . . 163
19.1.10 transport_lbtrm_sm_maximum_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . 164
19.1.11 transport_lbtrm_sm_minimum_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . 164
19.1.12 transport_lbtrm_source_timestamp (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 165
19.1.13 transport_lbtrm_tgsz (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
20 Transport LBT-RU Network Options
167
20.1
LBT-RU Transport Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
20.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
20.2.1 transport_lbtru_interface (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
20.2.2 transport_lbtru_interface (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
10
CONTENTS
20.2.3 transport_lbtru_maximum_ports (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . 169
20.2.4 transport_lbtru_port (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
20.2.5 transport_lbtru_port_high (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
20.2.6 transport_lbtru_port_high (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
20.2.7 transport_lbtru_port_low (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
20.2.8 transport_lbtru_port_low (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
21 Transport LBT-RU Reliability Options
21.1
173
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
21.1.1 transport_lbtru_ignore_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
21.1.2 transport_lbtru_nak_backoff_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . 174
21.1.3 transport_lbtru_nak_generation_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . 174
21.1.4 transport_lbtru_nak_initial_backoff_interval (receiver) . . . . . . . . . . . . . . . . . . . . . 175
21.1.5 transport_lbtru_nak_suppress_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . 175
21.1.6 transport_lbtru_receiver_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . . 176
21.1.7 transport_lbtru_source_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . . . 176
21.1.8 transport_lbtru_transmission_window_limit (source) . . . . . . . . . . . . . . . . . . . . . . 176
21.1.9 transport_lbtru_transmission_window_size (source) . . . . . . . . . . . . . . . . . . . . . . 177
22 Transport LBT-RU Operation Options
22.1
179
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
22.1.1 transport_lbtru_acknowledgement_interval (receiver)
. . . . . . . . . . . . . . . . . . . . . 180
22.1.2 transport_lbtru_activity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
22.1.3 transport_lbtru_client_activity_timeout (source)
. . . . . . . . . . . . . . . . . . . . . . . . 181
22.1.4 transport_lbtru_client_map_size (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
22.1.5 transport_lbtru_coalesce_threshold (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 181
22.1.6 transport_lbtru_connect_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
22.1.7 transport_lbtru_data_rate_limit (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
22.1.8 transport_lbtru_datagram_max_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . 183
22.1.9 transport_lbtru_maximum_connect_attempts (receiver) . . . . . . . . . . . . . . . . . . . . 184
22.1.10 transport_lbtru_rate_interval (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
22.1.11 transport_lbtru_recycle_receive_buffers (context)
. . . . . . . . . . . . . . . . . . . . . . . 185
22.1.12 transport_lbtru_retransmit_rate_limit (context) . . . . . . . . . . . . . . . . . . . . . . . . . 185
22.1.13 transport_lbtru_sm_maximum_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . 186
22.1.14 transport_lbtru_sm_minimum_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . 186
22.1.15 transport_lbtru_use_session_id (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
23 Transport LBT-IPC Operation Options
189
23.1
LBT-IPC Transport Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
23.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
23.2.1 transport_lbtipc_activity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
CONTENTS
11
23.2.2 transport_lbtipc_behavior (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
23.2.3 transport_lbtipc_datagram_max_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . 191
23.2.4 transport_lbtipc_dro_loss_recovery_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . 192
23.2.5 transport_lbtipc_id (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
23.2.6 transport_lbtipc_id_high (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
23.2.7 transport_lbtipc_id_low (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
23.2.8 transport_lbtipc_maximum_receivers_per_transport (source) . . . . . . . . . . . . . . . . . 194
23.2.9 transport_lbtipc_pend_behavior_linger_loop_count (context)
. . . . . . . . . . . . . . . . . 194
23.2.10 transport_lbtipc_receiver_operational_mode (context) . . . . . . . . . . . . . . . . . . . . . 194
23.2.11 transport_lbtipc_receiver_thread_behavior (context) . . . . . . . . . . . . . . . . . . . . . . 195
23.2.12 transport_lbtipc_recycle_receive_buffers (context) . . . . . . . . . . . . . . . . . . . . . . . 196
23.2.13 transport_lbtipc_sm_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
23.2.14 transport_lbtipc_transmission_window_size (source) . . . . . . . . . . . . . . . . . . . . . . 197
24 Transport LBT-SMX Operation Options
199
24.1
LBT-SMX Transport Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
24.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
24.2.1 transport_lbtsmx_activity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . 200
24.2.2 transport_lbtsmx_datagram_max_size (source) . . . . . . . . . . . . . . . . . . . . . . . . 200
24.2.3 transport_lbtsmx_id (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
24.2.4 transport_lbtsmx_id_high (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.2.5 transport_lbtsmx_id_low (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
24.2.6 transport_lbtsmx_maximum_receivers_per_transport (source) . . . . . . . . . . . . . . . . . 203
24.2.7 transport_lbtsmx_message_statistics_enabled (context) . . . . . . . . . . . . . . . . . . . . 203
24.2.8 transport_lbtsmx_sm_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
24.2.9 transport_lbtsmx_transmission_window_size (source) . . . . . . . . . . . . . . . . . . . . . 204
25 Transport Acceleration Options
207
25.1
Myricom® Datagram Bypass Layer (DBL™)
25.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
25.2.1 dbl_lbtrm_acceleration (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
25.2.2 dbl_lbtru_acceleration (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
25.2.3 dbl_mim_acceleration (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
25.2.4 dbl_resolver_acceleration (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
25.3
Solarflare® Onload
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
25.4
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
25.4.1 onload_acceleration_stack_name (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . 211
25.4.2 onload_acceleration_stack_name (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
25.5
UD Acceleration for Mellanox® Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 212
25.6
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
25.6.1 resolver_ud_acceleration (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
12
CONTENTS
25.6.2 ud_acceleration (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
26 Smart Source Options
26.1
215
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
26.1.1 mem_mgt_callbacks (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
26.1.2 smart_src_enable_spectrum_channel (source) . . . . . . . . . . . . . . . . . . . . . . . . . 216
26.1.3 smart_src_max_message_length (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
26.1.4 smart_src_message_property_int_count (source) . . . . . . . . . . . . . . . . . . . . . . . 217
26.1.5 smart_src_retention_buffer_count (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
26.1.6 smart_src_user_buffer_count (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
26.1.7 transport_lbtrm_smart_src_transmission_window_buffer_count (source) . . . . . . . . . . . 219
26.1.8 transport_lbtru_smart_src_transmission_window_buffer_count (source) . . . . . . . . . . . . 220
27 Encrypted TCP Options
27.1
221
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
27.1.1 tls_certificate (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
27.1.2 tls_certificate_key (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
27.1.3 tls_certificate_key_password (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
27.1.4 tls_cipher_suites (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
27.1.5 tls_compression_negotiation_timeout (context) . . . . . . . . . . . . . . . . . . . . . . . . . 223
27.1.6 tls_trusted_certificates (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
27.1.7 use_tls (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
28 Compressed TCP Options
28.1
225
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
28.1.1 compression (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
29 Multicast Immediate Messaging Network Options
29.1
227
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
29.1.1 mim_address (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
29.1.2 mim_destination_port (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
29.1.3 mim_incoming_address (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
29.1.4 mim_incoming_destination_port (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . 229
29.1.5 mim_outgoing_address (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
29.1.6 mim_outgoing_destination_port (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
30 Multicast Immediate Messaging Reliability Options
30.1
231
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
30.1.1 mim_ignore_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
30.1.2 mim_nak_backoff_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
30.1.3 mim_nak_generation_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
30.1.4 mim_nak_initial_backoff_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
CONTENTS
13
30.1.5 mim_nak_suppress_interval (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
30.1.6 mim_send_naks (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
30.1.7 mim_transmission_window_limit (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
30.1.8 mim_transmission_window_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
31 Multicast Immediate Messaging Operation Options
31.1
237
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
31.1.1 immediate_message_receiver_function (context) . . . . . . . . . . . . . . . . . . . . . . . . 237
31.1.2 immediate_message_topic_receiver_function (context)
. . . . . . . . . . . . . . . . . . . . 238
31.1.3 mim_activity_timeout (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
31.1.4 mim_delivery_control_activity_check_interval (context)
. . . . . . . . . . . . . . . . . . . . 239
31.1.5 mim_delivery_control_activity_timeout (context) . . . . . . . . . . . . . . . . . . . . . . . . 239
31.1.6 mim_delivery_control_order_tablesz (context) . . . . . . . . . . . . . . . . . . . . . . . . . 240
31.1.7 mim_implicit_batching_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
31.1.8 mim_implicit_batching_minimum_length (context) . . . . . . . . . . . . . . . . . . . . . . . 241
31.1.9 mim_ordered_delivery (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
31.1.10 mim_sm_maximum_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
31.1.11 mim_sm_minimum_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
31.1.12 mim_sqn_window_increment (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
31.1.13 mim_sqn_window_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
31.1.14 mim_src_deletion_timeout (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
31.1.15 mim_tgsz (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
31.1.16 mim_unrecoverable_loss_function (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 245
32 Late Join Options
247
32.1
Estimating Recovery Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
32.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
32.2.1 late_join (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
32.2.2 late_join_info_request_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
32.2.3 late_join_info_request_maximum (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . 249
32.2.4 retransmit_initial_sequence_number_request (receiver) . . . . . . . . . . . . . . . . . . . . 249
32.2.5 retransmit_message_caching_proximity (receiver) . . . . . . . . . . . . . . . . . . . . . . . 250
32.2.6 retransmit_request_interval (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
32.2.7 retransmit_request_maximum (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
32.2.8 retransmit_request_message_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . 251
32.2.9 retransmit_request_outstanding_maximum (receiver) . . . . . . . . . . . . . . . . . . . . . 252
32.2.10 retransmit_retention_size_limit (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
32.2.11 retransmit_retention_size_threshold (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 253
32.2.12 use_late_join (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
33 Off-Transport Recovery Options
255
14
33.1
CONTENTS
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
33.1.1 otr_message_caching_threshold (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
33.1.2 otr_request_initial_delay (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
33.1.3 otr_request_log_alert_cooldown (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
33.1.4 otr_request_maximum_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
33.1.5 otr_request_message_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
33.1.6 otr_request_minimum_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
33.1.7 otr_request_outstanding_maximum (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . 258
33.1.8 use_otr (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
34 Unicast Immediate Messaging Network Options
34.1
261
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
34.1.1 request_tcp_bind_request_port (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
34.1.2 request_tcp_interface (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
34.1.3 request_tcp_port (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
34.1.4 request_tcp_port_high (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
34.1.5 request_tcp_port_low (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
35 Unicast Immediate Messaging Operation Options
35.1
265
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
35.1.1 request_tcp_exclusiveaddr (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
35.1.2 request_tcp_listen_backlog (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
35.1.3 request_tcp_reuseaddr (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
35.1.4 response_session_maximum_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . . . 267
35.1.5 response_session_sender_socket_buffer (context) . . . . . . . . . . . . . . . . . . . . . . . 268
35.1.6 response_tcp_deletion_timeout (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
35.1.7 response_tcp_interface (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
35.1.8 response_tcp_nodelay (context)
36 Implicit Batching Options
36.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
271
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
36.1.1 implicit_batching_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
36.1.2 implicit_batching_minimum_length (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 271
37 Delivery Control Options
273
37.1
Burst Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
37.2
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
37.2.1 channel_map_tablesz (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
37.2.2 delivery_control_loss_check_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . 275
37.2.3 delivery_control_maximum_burst_loss (receiver) . . . . . . . . . . . . . . . . . . . . . . . . 276
37.2.4 delivery_control_maximum_total_map_entries (context) . . . . . . . . . . . . . . . . . . . . 276
CONTENTS
15
37.2.5 delivery_control_message_batching (context) . . . . . . . . . . . . . . . . . . . . . . . . . 277
37.2.6 mim_delivery_control_loss_check_interval (context) . . . . . . . . . . . . . . . . . . . . . . 277
37.2.7 null_channel_behavior (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
37.2.8 source_notification_function (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
37.2.9 unrecognized_channel_behavior (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
38 Wildcard Receiver Options
38.1
281
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
38.1.1 pattern_type (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
38.1.2 receiver_create_callback (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . 282
38.1.3 receiver_delete_callback (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . 282
38.1.4 resolver_no_source_linger_timeout (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . 283
38.1.5 resolver_query_maximum_interval (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . 283
38.1.6 resolver_query_minimum_duration (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . 284
38.1.7 resolver_query_minimum_interval (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . 284
38.1.8 resolver_wildcard_queries_per_second (context) . . . . . . . . . . . . . . . . . . . . . . . . 285
38.1.9 resolver_wildcard_query_bps (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
38.1.10 resolver_wildcard_receiver_map_tablesz (context) . . . . . . . . . . . . . . . . . . . . . . . 286
39 Event Queue Options
39.1
287
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
39.1.1 event_queue_name (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
39.1.2 queue_age_enabled (event_queue)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
39.1.3 queue_cancellation_callbacks_enabled (event_queue) . . . . . . . . . . . . . . . . . . . . . 288
39.1.4 queue_count_enabled (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
39.1.5 queue_delay_warning (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
39.1.6 queue_enqueue_notification (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . 290
39.1.7 queue_objects_purged_on_close (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . 290
39.1.8 queue_service_time_enabled (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . 291
39.1.9 queue_size_warning (event_queue)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
40 Ultra Messaging Persistence Options
40.1
293
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
40.1.1 ume_ack_batching_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
40.1.2 ume_activity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
40.1.3 ume_activity_timeout (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
40.1.4 ume_allow_confirmed_delivery (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
40.1.5 ume_application_outstanding_maximum (receiver) . . . . . . . . . . . . . . . . . . . . . . . 295
40.1.6 ume_confirmed_delivery_notification (source) . . . . . . . . . . . . . . . . . . . . . . . . . 296
40.1.7 ume_consensus_sequence_number_behavior (receiver)
. . . . . . . . . . . . . . . . . . . 297
40.1.8 ume_consensus_sequence_number_behavior (source) . . . . . . . . . . . . . . . . . . . . 298
16
CONTENTS
40.1.9 ume_explicit_ack_only (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
40.1.10 ume_flight_size (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
40.1.11 ume_flight_size_behavior (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
40.1.12 ume_flight_size_bytes (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
40.1.13 ume_force_reclaim_function (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
40.1.14 ume_late_join (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
40.1.15 ume_message_stability_lifetime (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
40.1.16 ume_message_stability_notification (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 302
40.1.17 ume_message_stability_timeout (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
40.1.18 ume_proactive_keepalive_interval (context)
40.1.19 ume_proxy_source (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . 304
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
40.1.20 ume_receiver_liveness_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
40.1.21 ume_receiver_paced_persistence (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . 305
40.1.22 ume_receiver_paced_persistence (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
40.1.23 ume_recovery_sequence_number_info_function (receiver)
. . . . . . . . . . . . . . . . . . 307
40.1.24 ume_registration_extended_function (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . 307
40.1.25 ume_registration_function (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
40.1.26 ume_registration_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
40.1.27 ume_registration_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
40.1.28 ume_repository_ack_on_reception (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 309
40.1.29 ume_repository_disk_file_size_limit (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 310
40.1.30 ume_repository_size_limit (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
40.1.31 ume_repository_size_threshold (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
40.1.32 ume_retention_intergroup_stability_behavior (source) . . . . . . . . . . . . . . . . . . . . . 312
40.1.33 ume_retention_intragroup_stability_behavior (source) . . . . . . . . . . . . . . . . . . . . . 313
40.1.34 ume_retention_size_limit (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
40.1.35 ume_retention_size_threshold (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
40.1.36 ume_retention_unique_confirmations (source) . . . . . . . . . . . . . . . . . . . . . . . . . 315
40.1.37 ume_session_id (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
40.1.38 ume_session_id (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
40.1.39 ume_session_id (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
40.1.40 ume_source_liveness_timeout (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
40.1.41 ume_sri_flush_sri_request_response (source) . . . . . . . . . . . . . . . . . . . . . . . . . 317
40.1.42 ume_sri_immediate_sri_request_response (source) . . . . . . . . . . . . . . . . . . . . . . 318
40.1.43 ume_sri_inter_sri_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
40.1.44 ume_sri_max_number_of_sri_per_update (source)
. . . . . . . . . . . . . . . . . . . . . . 320
40.1.45 ume_sri_request_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
40.1.46 ume_sri_request_maximum (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
40.1.47 ume_sri_request_response_latency (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 321
40.1.48 ume_state_lifetime (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
CONTENTS
17
40.1.49 ume_state_lifetime (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
40.1.50 ume_store (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
40.1.51 ume_store_activity_timeout (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
40.1.52 ume_store_behavior (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
40.1.53 ume_store_check_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
40.1.54 ume_store_group (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
40.1.55 ume_store_name (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
40.1.56 ume_use_ack_batching (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
40.1.57 ume_use_late_join (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
40.1.58 ume_use_store (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
40.1.59 ume_user_receiver_registration_id (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 328
40.1.60 ume_write_delay (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
41 Ultra Messaging Queuing Options
41.1
331
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
41.1.1 umq_command_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
41.1.2 umq_command_outstanding_maximum (context)
. . . . . . . . . . . . . . . . . . . . . . . 332
41.1.3 umq_delayed_consumption_report_interval (receiver) . . . . . . . . . . . . . . . . . . . . . 332
41.1.4 umq_hold_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
41.1.5 umq_index_assignment_eligibility_default (receiver) . . . . . . . . . . . . . . . . . . . . . . 333
41.1.6 umq_message_stability_notification (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 334
41.1.7 umq_msg_total_lifetime (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
41.1.8 umq_queue_activity_timeout (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
41.1.9 umq_queue_participation (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
41.1.10 umq_queue_registration_id (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
41.1.11 umq_receiver_type_id (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
41.1.12 umq_retransmit_request_interval (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . 337
41.1.13 umq_retransmit_request_outstanding_maximum (receiver) . . . . . . . . . . . . . . . . . . 337
41.1.14 umq_session_id (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
41.1.15 umq_ulb_application_set (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
41.1.16 umq_ulb_application_set_assignment_function (source) . . . . . . . . . . . . . . . . . . . . 339
41.1.17 umq_ulb_application_set_events (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
41.1.18 umq_ulb_application_set_load_factor_behavior (source) . . . . . . . . . . . . . . . . . . . . 340
41.1.19 umq_ulb_application_set_message_lifetime (source)
. . . . . . . . . . . . . . . . . . . . . 341
41.1.20 umq_ulb_application_set_message_max_reassignments (source)
41.1.21 umq_ulb_application_set_message_reassignment_timeout (source)
. . . . . . . . . . . . . . 342
. . . . . . . . . . . . . 342
41.1.22 umq_ulb_application_set_receiver_activity_timeout (source) . . . . . . . . . . . . . . . . . . 343
41.1.23 umq_ulb_application_set_receiver_keepalive_interval (source) . . . . . . . . . . . . . . . . 343
41.1.24 umq_ulb_application_set_round_robin_bias (source)
. . . . . . . . . . . . . . . . . . . . . 344
41.1.25 umq_ulb_check_interval (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
18
CONTENTS
41.1.26 umq_ulb_events (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
41.1.27 umq_ulb_flight_size (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
41.1.28 umq_ulb_flight_size_behavior (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
41.1.29 umq_ulb_receiver_events (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
41.1.30 umq_ulb_receiver_portion (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
41.1.31 umq_ulb_receiver_priority (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
41.1.32 umq_ulb_source_activity_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . 349
41.1.33 umq_ulb_source_check_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
42 Hot Failover Operation Options
42.1
351
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
42.1.1 delivery_control_loss_check_interval (hfx) . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
42.1.2 delivery_control_max_delay (hfx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
42.1.3 delivery_control_maximum_burst_loss (hfx) . . . . . . . . . . . . . . . . . . . . . . . . . . 352
42.1.4 delivery_control_maximum_total_map_entries (hfx) . . . . . . . . . . . . . . . . . . . . . . 353
42.1.5 duplicate_delivery (hfx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
42.1.6 hf_duplicate_delivery (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
42.1.7 hf_optional_messages (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
42.1.8 hf_receiver (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
42.1.9 ordered_delivery (hfx) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
43 Automatic Monitoring Options
43.1
357
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
43.1.1 monitor_appid (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
43.1.2 monitor_appid (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
43.1.3 monitor_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
43.1.4 monitor_interval (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
43.1.5 monitor_interval (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
43.1.6 monitor_interval (wildcard_receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
43.1.7 monitor_transport (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
43.1.8 monitor_transport (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
43.1.9 monitor_transport_opts (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
43.1.10 monitor_transport_opts (event_queue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
44 Deprecated Options
44.1
365
Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
44.1.1 delivery_control_loss_tablesz (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
44.1.2 delivery_control_order_tablesz (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
44.1.3 implicit_batching_type (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
44.1.4 network_compatibility_mode (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
44.1.5 otr_request_duration (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
CONTENTS
19
44.1.6 pattern_callback (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
44.1.7 rcv_sync_cache (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
44.1.8 rcv_sync_cache_timeout (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
44.1.9 receive_thread_pool_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
44.1.10 resolver_active_source_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
44.1.11 resolver_active_threshold (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
44.1.12 resolver_context_advertisement_interval (context) . . . . . . . . . . . . . . . . . . . . . . . 371
44.1.13 resolver_maximum_advertisements (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 371
44.1.14 resolver_maximum_queries (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
44.1.15 resolver_query_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
44.1.16 resolver_query_max_interval (wildcard_receiver) . . . . . . . . . . . . . . . . . . . . . . . . 373
44.1.17 resolver_unicast_address (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
44.1.18 resolver_unicast_destination_port (context)
. . . . . . . . . . . . . . . . . . . . . . . . . . 374
44.1.19 resolver_unicast_port (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
44.1.20 retransmit_message_map_tablesz (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 375
44.1.21 retransmit_request_generation_interval (receiver) . . . . . . . . . . . . . . . . . . . . . . . 375
44.1.22 retransmit_retention_age_threshold (source) . . . . . . . . . . . . . . . . . . . . . . . . . . 376
44.1.23 source_cost_evaluation_function (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
44.1.24 transport_datagram_max_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
44.1.25 transport_lbtipc_acknowledgement_interval (receiver) . . . . . . . . . . . . . . . . . . . . . 378
44.1.26 transport_lbtipc_client_activity_timeout (source) . . . . . . . . . . . . . . . . . . . . . . . . 378
44.1.27 transport_lbtrdma_datagram_max_size (context) . . . . . . . . . . . . . . . . . . . . . . . . 379
44.1.28 transport_lbtrdma_interface (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
44.1.29 transport_lbtrdma_maximum_ports (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 380
44.1.30 transport_lbtrdma_port (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
44.1.31 transport_lbtrdma_port_high (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
44.1.32 transport_lbtrdma_port_low (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
44.1.33 transport_lbtrdma_receiver_thread_behavior (context) . . . . . . . . . . . . . . . . . . . . . 382
44.1.34 transport_lbtrdma_transmission_window_size (source)
. . . . . . . . . . . . . . . . . . . . 382
44.1.35 ume_message_map_tablesz (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
44.1.36 ume_primary_store_address (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
44.1.37 ume_primary_store_port (source)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
44.1.38 ume_registration_id (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
44.1.39 ume_retransmit_request_generation_interval (receiver) . . . . . . . . . . . . . . . . . . . . 385
44.1.40 ume_retransmit_request_interval (receiver)
. . . . . . . . . . . . . . . . . . . . . . . . . . 385
44.1.41 ume_retransmit_request_maximum (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . 386
44.1.42 ume_retransmit_request_outstanding_maximum (receiver) . . . . . . . . . . . . . . . . . . 386
44.1.43 ume_secondary_store_address (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
44.1.44 ume_secondary_store_port (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
44.1.45 ume_tertiary_store_address (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
20
CONTENTS
44.1.46 ume_tertiary_store_port (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
44.1.47 umq_flight_size (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
44.1.48 umq_flight_size (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
44.1.49 umq_flight_size_behavior (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
44.1.50 umq_flight_size_behavior (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
44.1.51 umq_message_retransmission_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . 391
44.1.52 umq_message_stability_notification (context)
. . . . . . . . . . . . . . . . . . . . . . . . . 392
44.1.53 umq_msg_total_lifetime (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
44.1.54 umq_queue_check_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
44.1.55 umq_queue_name (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
44.1.56 umq_queue_participants_only (source) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
44.1.57 umq_queue_query_interval (context) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
44.1.58 umq_require_queue_authentication (context) . . . . . . . . . . . . . . . . . . . . . . . . . . 395
44.1.59 umq_retention_intergroup_stability_behavior (context) . . . . . . . . . . . . . . . . . . . . . 395
44.1.60 umq_retention_intergroup_stability_behavior (source) . . . . . . . . . . . . . . . . . . . . . 396
44.1.61 umq_retention_intragroup_stability_behavior (context) . . . . . . . . . . . . . . . . . . . . . 397
44.1.62 umq_retention_intragroup_stability_behavior (source) . . . . . . . . . . . . . . . . . . . . . 398
44.1.63 use_transport_thread (receiver) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
45 Option Categories
401
45.1
UM UDP Port Values
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
45.2
UM TCP Port Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
45.3
UM Multicast Group Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
45.4
UM Timer Interval Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
45.5
Options That May Be Set During Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
45.6
Options that Cannot Be Set Via Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Chapter 1
Introduction
This document describes how Ultra Messaging-based user applications are configured. The configurations of standard UM daemon components (Dynamic Router, Persistent Store, Resolver Daemon, etc.) are describe in other
documents.
Attention
See the Documentation Introduction for important information on copyright, patents, information resources (including Knowledge Base, and How To articles), Marketplace, Support, and other
information about Informatica and its products.
This document assumes familiarity with the UM Concepts Guide.
See UM Glossary for Ultra Messaging terminology, abbreviations, and acronyms.
1.1
Configuration Overview
For Ultra Messaging applications, you can set a variety of operational options to customize the application's behavior
or performance. You assign values to these options in configuration files or by using function calls. You can assign
option values to objects upon or after object creation. Within an object, the implemented option values are referred
to as attributes.
Ultra Messaging uses intelligent default values for configuration options, enabling applications to run "out of the
box." However, expect to customize Ultra Messaging options to optimize your operating environment. You can use
different ways to configure option default and customized value assignments.
1.1.1
Assignment Methods
You can use the following ways to set attributes with configuration options:
XML configuration files
Customized defaults in an XML-formatted file, used during object creation.
plain text configuration files
Customized defaults in a text file, used during object creation.
22
Introduction
attributes objects
Application-specific option values used during object creation.
function calls with ∗_setopt()
Used after object creation.
The following image shows the different ways Ultra Messaging stores and assigns option values before, during, and
after primitive object creation. Primitive objects are sources, receivers, wildcard receivers, event queues, contexts,
or HFX objects. The ultimate result is a primitive object with the assigned values residing in current attributes.
The initial default attributes is the set of factory defaults in Ultra Messaging. Ultra Messaging modifies selected
options in the plain text configuration file, and then stores these values in current default attributes. The current
default attributes is the starting point for all created primitive objects.
An instantiated primitive object uses values from current default attributes, the XML config table, and the custom
attributes object, and then holds the results in current attributes.
An XML configuration file can pass its setting to an object being created either by directly populating the XML config
table, or by creating a custom attributes object.
1.1.2
Assignment Flow
The above diagram implies, but does not fully explain, the flow of attribute value assignment that UM performs when
an application creates a primitive object. This flow is described below, and is important in understanding how and
when default values are overridden:
1. If applicable, copy plain text configuration file values to current default attributes.
2. Start creating object.
3. Custom attributes object(s) created/populated (if applicable).
1.1 Configuration Overview
23
4. If lbm_∗_create() has a NULL attr, copy current default attributes into current attributes. Otherwise, copy
custom attributes object values into current attributes.
5. Read applicable options from the XML config table into the current attributes. Do not overwrite options set
with lbm_config(), or lbm_∗_attr_setopt(), which were tagged when modified.
6. Finish object creation.
7. current attributes can be changed further (only certain options) via lbm_∗_setopt().
1.1.3
Definitions
Before discussing how UM options can be set, some terminology is in order.
Option
A single configuration item that controls some aspect of UM operation. An option typically resides in a configuration file, but can also be assigned a value via a function call. We use options to assign values to an object's
attributes.
Attribute
An operational characteristic of an object. An attribute's value is set by an option, hence, there is a one-to-one
correspondence between options and attributes. (Note: This use of the term "attribute" is unrelated to, and not
to be confused with, "attribute" in XML syntax. In this document, we refer to the latter as "XML attribute".)
XML attribute
See above. In XML syntax, XML attributes are parameters for XML elements.
Custom attributes object
A UM object that contains custom attribute values (set by options) for a specific UM object. Separate (and
multiple) sets of attributes can exist for each application, though only one can be used when creating a primitive
object.
Initial default attributes
The default attributes values built into UM. UM and your applications use these if you have not set any options
for the attributes.
Primitive object
Specifically, an object that is a source, receiver, wildcard receiver, event queue, context, or HFX object.
Configuration file
This comes in two types: XML and plain text. Configuration files contain assigned values for options, but the
different types are read/copied at different times during the creation of an object.
XML config table
Contains option values that are read from the XML configuration file.
Current default attributes
The attributes values used to create an object in the absence of custom attributes values.
24
Introduction
Current attributes
The attribute values for an instantiated UM object that control the current operation of that object.
Scope
The type of object to which an option can apply. Possible scopes are context, source, receiver, wildcard_←receiver, event_queue, and hfx.
1.1.4
Which Method Should I Use?
For the four basic assignment methods listed above, following are some scenarios where specific methods are
selected.
• To change a default option value and apply it to all objects you create, call lbm_config() for one or more configuration files. For example, to use LBT-RM rather than TCP for all sources, create a plain text configuration
file containing
source transport LBTRM
and pass its file name to lbm_config().
Note
The C API offers functions lbm_∗_attr_create_default() to change a current default value back to the
initial (factory) default value. No such corresponding method exists for the Java or .NET APIs.
• To customize specific options before an object is created for a specific object instance, use a custom attributes
object. Also, you can assign XML data to the XML config table directly from your application via lbm_config←_xml_string().
• To create sets of custom values to be used when creating primitive objects, call lbm_config_xml_file() and
specify an XML configuration file. This is useful for setting specific default options on a per-topic or percontext basis, which cannot be done with a plain text configuration file. For an example where a sending
application uses specific options and values, create an XML configuration file with the application's name
(optional) that specifies those options and values. Then pass the XML file name and application name to
lbm_config_xml_file().
• To change an option after an object is created, modify the current attributes for the object. (Note that many
options cannot be changed after an object has been created.)
These methods can be used in combination. See Assignment Methods to see the relationships between attributes
and the various UM API function calls that affect them.
1.1.5
Host Name Resolution
Many of UM's configuration options specify an IP address. Prior to UM version 6.10 these needed to be specified in
dotted numeric format. For example, 10.23.19.210. Starting in version 6.10, any configuration option that accepts
an IP address can also accept a DNS host name (the few exceptions are noted in the documentation). For example,
myhost.mydomain.com. Note that the DNS name system is not necessarily used when host names are specified;
for example, most Unix systems will first look up the name in /etc/hosts.
When host names are specified, the name is resolved to an IP address when the configuration option is parsed.
If you change the IP address associated with a name, that change will not take effect until the configuration file is
re-read, typically by restarting the application.
1.2 Plain Text Configuration Files
1.1.6
25
Configuration Files
There are two types of UM Configuration files:
• Plain Text Configuration Files
• XML Configuration Files
You can read Configuration files either by function call, or automatically upon application launch by specifying a file
name in an environment variable. See Assignment Methods and Assignment Flow for details on how these options
replace or override default values.
There are some UM configuration options which cannot be set via configuration files. These are options whose
values are function pointers or data structures. These options can only be set via API functions ∗_setopt. For
example, context resolver_source_notification_function has a function pointer as its value. See Options that
Cannot Be Set Via Configuration Files for the full list.
1.2
Plain Text Configuration Files
The plain text configuration file, when invoked, writes option values into UM's current default attributes. These are
then read and used in the creation of all objects.
See Example Configuration Scenarios for example configuration files.
1.2.1
Reading Plain Text Configuration Files
There are two ways to read a plain text configuration file to set values in current default attributes.
API function lbm_config()
You can call the function multiple times with different file names to set configuration options in phases.
When you create UM objects (such as a context or receiver), UM sets attributes for that object using the current
default attributes. Hence, you must call lbm_config() before creating objects (lbm_∗_create()).
Environment variable LBM_DEFAULT_CONFIG_FILE
Reads configuration file when your application is started. You can set this variable to a full pathname or a URL;
for example:
export LBM_DEFAULT_CONFIG_FILE=/home/lbm/lbtrm.cfg
(You can still use the lbm_config() function on a different file to make additional changes.)
26
Introduction
1.3
Plain Text Configuration File Format
A plain text configuration file contains lines that each take the form:
scope_keyword option_name option_value
where:
scope_keyword - the scope to which the option applies,
option_name - the predefined name for the option, and
option_value - the new value to be assigned to that option.
Allowable values for these parameters are given throughout the rest of this document. Any text following a hash
character # (also known as a pound sign, number sign, or octothorp) is interpreted as comment text and is ignored.
For example:
# Set transport_tcp_port_low to 4901
context transport_tcp_port_low 4901
# And set transport_tcp_port_high to 4920
context transport_tcp_port_high 4920
Note
For plain text configuration files, do not enclose any fields in double quotation marks (").
1.4
XML Configuration Files
XML configuration files let you address many different applications and operating requirements, removing the need
to programmatically set and reset options for them. A single XML file can contain options for multiple applications.
Moreover, for a single application, you can configure multiple named contexts, event queues, etc., with different
values for the same options.
See Example Configuration Scenarios for example configuration files.
1.4.1
Reading XML Configuration Files
There are multiple ways to read an XML configuration file to assign values while creating a primitive object.
API function lbm_config_xml_file()
Reads an XML configuration file into XML config table. Call this before the primitive create function. This does
not change the current default attributes. Use a file path, or a URL beginning with http:// or ftp://.
API function lbm_config_xml_string()
Populates the XML config table directly from your application. Call this before the primitive create function. This
does not change the current default attributes.
API function lbm_∗_attr_create_from_XML()
Creates a custom attributes object containing the values from an XML configuration file. The values can then
be applied to a primitive object being created by calling function lbm_∗_create() and specifying this custom
attributes object in the second parameter.
1.4 XML Configuration Files
27
Environment variable LBM_XML_CONFIG_FILENAME
Reads the file into the XML config table. These settings are then available to all applications when they start.
Use a file path, or a URL beginning with http:// or ftp://.
Environment variable LBM_XML_CONFIG_APPNAME
Reads options for a specific application from the LBM_XML_CONFIG_FILENAME variable's filename. This
initiates the specified application's configuration; set this environment variable for every application.
Environment variable LBM_UMM_INFO
Initiates UMM Daemon to read options for an application and user from the LBM_XML_CONFIG_FILENAME
variable's filename. Set this variable for every application/user combination, in the following format:
export LBM_UMM_INFO=application_name:user_name:password@ip:port
Note
Since you can use these API functions and environment variables without the UMM Daemon, you cannot set
a username or password.
1.4.2
Using XML Configuration Files With a UM Application
The following procedure describes a general approach to implementing XML configuration files.
1. Create an XML configuration file using an XML editor or text editor. Just for this example, name the file,
UM_CONFIG.XML.
2. Insert any desired templates in the element to hold configuration option values shared by
multiple applications or primitive UM objects (context, source, receiver, wildcard receiver or event queue).
You can create and apply multiple templates to applications and primitive UM objects, however, if the same
option appears in multiple templates, the option value in the last template overrides the option value in the
previous template. See .
3. Insert an element for your UM application in the element and include any
relevant templates created in the previous step. Just for this example, name the application, SENDAPP. See
.
4. Within the element, configure the application's element and context options. And
since our example application, SENDAPP is a sending application, also configure its Source options. (If this
was a receiving application, you would configure Receiver or Wildcard Receiver options. If your application
creates multiple Contexts, enter multiple elements within the element, inserting the
appropriate source, receiver or wildcard receiver options. See .
5. Configure the applications Event Queue options. See .
6. Save the XML configuration file, UM_CONFIG.XML, and load it onto the machine where the application (S←ENDAPP) runs.
7. Set the following environment variables on the machine where SENDAPP runs.
• Set LBM_XML_CONFIG_FILENAME to UM_CONFIG.XML.
• Set LBM_XML_CONFIG_APPNAME to SENDAPP.
• Optionally, you could also use lbm_config_xml_file(UM_CONFIG.XML,SENDAPP) in the SENDAPP
source.
8. Start SENDAPP.
28
1.4.3
Introduction
XML Configuration File Format
An XML Configuration File follows standard XML conventions. Element declarations or a pointer to a DTD file are
not needed, as these are handled by UM.
An XML configuration file generally comprises two primary elements: templates and applications. Organized and
contained within these are option value assignments. Applications containers let you set options for specific applications. To provide more global control over applications, or to simply reduce repetition, you can create templates
to hold option settings that are to be used in one or more different applications.
XML configuration files use the high-level structure shown in the following example. This example includes only
some container elements, and no options.
1.4.4
Merging Multiple XML Configuration Files
For UM XML configuration files and UMP store daemon XML configuration files, you can use the XInclude mechanism to merge multiple configuration files.
To include an external file, use the following syntax:
Files to be included must be formatted such that all elements are enclosed in a single container element, as shown
in the following examples:
Example 1
1.4 XML Configuration Files
Example 2
29
30
Introduction
Chapter 2
XML Configuration File Elements
Following are descriptions of the XML configuration file elements.
2.1
Description:
The element is a required container for all UM configuration options residing in the XML
configuration file. This is the top-level element.
Parents:
None.
Children:
•
•
•
XML Attributes:
XML Attribute
Description
Default Value
version
The version of the DTD.
none
Example:
...
...
32
XML Configuration File Elements
2.2
Description:
The element identifies the UM product license, either as the license key or as a pointer to a license
file, as an alternative to setting it in an environment variable.
Parents:
•
Children:
None.
XML Attributes:
XML Attribute
Description
Default Value
format
The format for the license element data. filename points to the file containing the license key. string identifies the data as the license key itself.
string
xml:space
How whitespace is handled. default trims leading and trailing whitespace (e.g., tabs, spaces, linefeeds, etc.), and compresses multiple
whitespace characters into a single space character. preserve preserves the whitespace exactly as read.
default
Example:
/
usr/local/licenses/um_license.txt
...
2.3
Description:
The element is a container element for individual options. You specify the primitive object in the
attribute type.
2.4
33
Parents:
•
•
•
•
•
Children:
•
•
XML Attributes:
XML Attribute
Description
Default Value
type
The type of primitive object, which can be event-queue, context,
source, receiver, wildcard-receiver, or hfx).
None
Example:
...
...
2.4
Description:
The element corresponds to any UM configuration option.
Parents:
•
Children:
•
•
34
XML Configuration File Elements
XML Attributes:
XML Attribute
Description
Default Value
name
Name of the UM configuration option. See Reference
for all options.
N/A
default-value
The value you are setting for this option.
The default value for the option.
order
Permit or restrict particular option values. Valid values are deny,allow (deny what you specify, allow everything else) or allow,deny (allow what you specify,
deny everything else). If using this XML attribute, follow this element with or elements
as needed.
deny,allow
Example:
To permit any application to choose any transport method except LBT-RU, configure the following in a template
included in sending applications.
LBTRU
To restrict any application to only the LBT-RM or LBT-RU transport method, configure the following in a template
included in sending applications.
LBTRU
LBTRM
2.5
Description:
Use the element with to set a condition for that option to permit only a certain subset
of possible default value values for the option. See also Using the Order and Rule XML Attributes
Parents:
•
Children:
None
XML Attributes:
2.6
35
XML Attribute
Description
Default Value
xml:space
How whitespace is handled. default trims leading and trailing whitespace (e.g., tabs, spaces, linefeeds, etc.), and compresses multiple
whitespace characters into a single space character. preserve preserves the whitespace exactly as read.
default
Example:
LBTRU
LBTRM
2.6
Description:
Use the element with to set a condition for that option that restricts certain (otherwise)
possible default value values from being used by the option. See also Using the Order and Rule XML Attributes
Parents:
•
Children:
None
XML Attributes:
XML Attribute
Description
Default Value
xml:space
How whitespace is handled. default trims leading and trailing whitespace (e.g., tabs, spaces, linefeeds, etc.), and compresses multiple
whitespace characters into a single space character. preserve preserves the whitespace exactly as read.
default
Example:
LBTRU
36
XML Configuration File Elements
2.7
Description:
The element is a container element for all templates that contain configuration options that can
be used in other templates or applications. A template can be very specific, such as configuring options only
for LBT-RM sources, or more comprehensive, configuring common options for your applications.
Insert any desired templates in the element to hold configuration option values shared by multiple
applications or primitive objects. You can create and apply multiple templates to applications and primitive UM
objects in a comma separated value (CSV) format. However, if the same option appears in multiple templates,
the option value in the last or lower-level template overrides the option value in the previous or higher-level
template.
Parents:
•
Children:
•
XML Attributes:
None
Example:
...
2.8
Description:
The element is a container for one uniquely named set of options.
Parents:
•
Children:
•
2.9
37
XML Attributes:
XML Attribute
Description
Default Value
name
Name of the configuration template, which can be referenced elsewhere in this XML configuration file to
assign to other configuration elements. Multiple templates can be specified in a comma separated value
(CSV) format.
None
default-value
The value you are setting for this option.
The default value for the option.
Example:
...
2.9
Description:
The element is a container element for all applications configured in the XML configuration file.
UM lets you configure one or more applications.
Parents:
•
Children:
•
XML Attributes:
None.
Example:
...
38
XML Configuration File Elements
2.10
Description:
The element contains option values for all object elements within a single, uniquely named,
application.
Parents:
•
Children:
•
•
•
•
XML Attributes:
XML Attribute
Description
Default Value
name
Name of the application. Used as an optional parameter for lbm_←config_from_xml(). If a name is not supplied, this must be the only
occurrence of this element in the XML configuration file.
None
template
Name of the configuration template to use for the application.
None
Example:
...
...
...
...
2.12
39
2.11
Description:
The element is a container element for all UM contexts configured for an application. UM lets you
create one or more contexts for an application.
Parents:
•
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
template
Name of the configuration template to apply to each individual context
object configured within this element. Multiple templates can be applied by specifying them in a comma-separated-value manner, i.e., "←Sending1,Sending2". Can be overridden by a different template configured for an individual context.
None
order
Establishes the permission semantic for each individual context configured within this element. Valid values are deny,allow (deny what you
specify, allow everything else) or allow,deny (allow what you specify,
deny everything else). Works in conjunction with the X←ML attribute, rule.
deny,allow
Example:
...
2.12
Description:
The element contains option values for a single context, organized into its child elements.
Important:
Setting the name attribute in this element does not actually name a context. A context name must be estab-
40
XML Configuration File Elements
lished when you create the context. See the name description in the table below.
Parents:
•
Children:
•
•
•
•
XML Attributes:
XML Attribute
Description
Default Value
name
Name of the context. UM only applies an XML configuration using this
name to contexts that match this context name. Setting this XML name
attribute does not name the context, but provides the ability to map previously created context attributes to this XML element. You can configure
an automatic monitoring context by setting name="infa_statistics_←context".
Name of the configuration template to use for the context object's options.
Permits or restricts the creation of the context object. If rule="deny",
the context object errors upon creation.
None
template
rule
None
allow
Example:
...
...
...
2.13
41
2.13
Description:
The element is a container for all UM sources configured for an application. UM lets you create
one or more sources for an application.
Parents:
•
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
template
Name of the configuration template to apply to each individual context
object configured within this element. Multiple templates can be applied by specifying them in a comma-separated-value manner, i.e., "←Sending1,Sending2". Can be overridden by a different template configured for an individual context.
None
order
Establishes the permission semantic for each individual context configured within this element. Valid values are deny,allow (deny what you
specify, allow everything else) or allow,deny (allow what you specify,
deny everything else). Works in conjunction with the XML
attribute, rule.
deny,allow
Example:
...
...
...
42
XML Configuration File Elements
2.14
Description:
The element contains option values for a single source or receiver.
Parents:
•
•
•
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
topicname
The topic string for the topic that the source sends or the receiver accepts. Used as a parameter for lbm_src_topic_alloc(), lbm_rcv←_topic_lookup(), lbm_src_attr_create_from_xml(), lbm_src_attr_←set_from_xml(), lbm_rcv_attr_create_from_xml(), and lbm_rcv_←attr_set_from_xml(). Do not use with the pattern attribute.
None
template
Name of the configuration template to use for this topic's source or receiver options.
None
rule
Permits or restricts the creation of the source or receiver object. If
rule="deny", the object errors upon creation.
allow
pattern
Identify the set of options for this topic with a topic string regular expression pattern. Any source created with a topic string that matches
this pattern receives the configured option values. Do not use with the
topicname attribute.
None
Example:
...
...
2.15
43
2.15
Description:
The element is a container element for all UM receivers configured for an application. You can
create one or more receivers for an application.
Parents:
•
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
template
Name of the configuration template to apply to each individual receiver
object configured within this element. You can apply multiple templates by specifying them in a comma-separated-value manner, e.g.,
"Receiving1,Receiving2".
N/A
order
Establishes the permission semantic for each individual context configured within this element. Valid values are deny,allow (deny what you
specify, allow everything else) or allow,deny (allow what you specify,
deny everything else). Works in conjunction with the XML
attribute, rule.
deny,allow
Example:
...
...
44
XML Configuration File Elements
2.16
Description:
The element is a container element for all UM wildcard receivers configured for an
application. UM lets you create one or more wildcard receivers for an application.
Parents:
•
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
template
Name of the configuration template to apply to each individual wildcard
receiver object configured within this element. Multiple templates can
by applied by specifying them in a comma-separated-value manner, i.e.,
"Receiving1,Receiving2". Can be overridden by a different template
configured for an individual wildcard receiver.
N/A
order
Establishes the permission semantic for each individual context configured within this element.
Valid values are deny,allow (deny
what you specify, allow everything else) or allow,deny (allow what
you specify, deny everything else). Works in conjunction with the
XML attribute, rule.
deny,allow
Example:
...
...
2.17
45
2.17
Description:
The element contains option values for a single wildcard receiver.
Parents:
•
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
template
Name of the configuration template to use for the wildcard receiver object's options.
None
rule
Permits or restricts the creation of the wildcard receiver object.
rule="deny", the object errors upon creation.
If
allow
pattern
The wildcard receiver topic string regular expression pattern for this wildcard receiver object.
None
pattern-type
The type of pattern matching to use for the wildcard receiver object. Valid
values are pcre, regex or application-callback.
pcre
Example:
...
...
46
XML Configuration File Elements
2.18
Description:
The Element is a container element for all UM event queues configured for an application.
UM lets you create one or more event queues for an application.
Parents:
•
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
template
Name of the configuration template to apply to each individual event
queue object configured within this element. You can apply multiple
templates specifying them in a comma-separated-value manner, e.g.,
"EVQ-1,EVQ-2". Can be overridden by a different template configured
for an individual event queue.
N/A
order
Establishes the permission semantic for each individual context configured within this element.
Valid values are deny,allow (deny
what you specify, allow everything else) or allow,deny (allow what
you specify, deny everything else). Works in conjunction with the
XML attribute, rule.
deny,allow
Example:
...
2.19
Description:
The element contains option values for a single event queue.
Parents:
•
2.20
47
Children:
•
XML Attributes:
XML Attribute
Description
Default Value
name
Name of the event queue. Used as a parameter for lbm_event←_queue_attr_create_from_xml() and lbm_event_queue_attr_set_←from_xml().
None
template
Name of the configuration template to use for the event queue object's
options.
None
rule
Permits or restricts the creation of the event queue object. If rule="deny",
the object errors upon creation.
allow
Example:
...
2.20
Description:
The element is a container for all UM HFX objects configured for an application. Within the
element, options are organized by topic.
Parents:
•
Children:
•
XML Attributes:
48
XML Configuration File Elements
XML Attribute
Description
Default Value
template
Name of the configuration template to apply to each individual HFX object configured within this element. Multiple templates can by applied by
specifying them in a comma-separated-value manner, i.e., "Sending1,←Sending2". Can be overridden by a different template configured for an
individual HFX object.
N/A
order
Establishes the permission semantic for each individual context configured within this element. Valid values are deny,allow (deny what you
specify, allow everything else) or allow,deny (allow what you specify,
deny everything else). Works in conjunction with the XML
attribute, rule.
deny,allow
Example:
...
2.21
Description:
The element is a free-form text comment field that you can use to store applicationspecific or options-group-specific metadata. When defined at the options level, this content overrides
elements defined at the application level.
Your application can retrieve this data via the lbm_∗_attr_getopt() and lbm_∗_attr_str_getopt() API functions
under the option name application_data. You can also programmatically set it using the equivalent ∗_setopt()
APIs. The application_data option is defined for all option scopes.
Also, you can set or retrieve this value at runtime via the ∗_getopt() and ∗_setopt() functions defined for the
types lbm_context_t, lbm_src_t, lbm_rcv_t, lbm_wildcard_rcv_t, lbm_event_queue_t, and lbm_hfx_t.
Parents:
•
•
Children:
None.
2.21
49
XML Attributes:
XML Attribute
Description
Default Value
xml:space
How whitespace is handled. default trims leading and trailing whitespace (e.g., tabs, spaces, linefeeds, etc.), and compresses multiple
whitespace characters into a single space character. preserve preserves the whitespace exactly as read.
default
Example:
Comment about this section.
Comment about this section.
...
...
50
XML Configuration File Elements
Chapter 3
Sample XML Configuration File
A sample XML configuration file appears below and has the following notable aspects.
• Contains object attributes for a UM context and source.
• Application name is Sending.
• Uses a template of attributes also called Sending-LBTRM.
• The template, Sending-LBTRM, uses the order attribute for the fd_management_type to allow all file descriptor types except DEVPOLL. However the Sending-LBTRM application further restricts the file descriptor
types to exclude EPOLL in addition to DEVPOLL.
wincompport
52
Sample XML Configuration File
wincompport
3.1
Using the Order and Rule XML Attributes
The order and rule XML attributes combine to enable you to permit or restrict the creation of primitive UM objects.
The container elements such as the , , , etc. have the order
attribute. The single object elements, such as , , etc., have the rule attribute. The
default for both attributes allows creation of all objects. You can however, exert some administrative control over
your applications by allowing the creation of only certain objects.
You can vary the order attribute values to suit whether permission or restriction is more prevalent. In the example
below, only a single topic needs to be restricted, so we use the default values for the order attribute with only a
single topic restricted with a rule="deny" attribute.
3.1 Using the Order and Rule XML Attributes
53
In contrast, the following example requires the creation of only a single receiver topic object, so you can change the
order attribute to "allow,deny", which restricts the creation of all receiver topic objects except the one allowed.
You can also combine topic names with topic patterns. In the example below, we set the order attribute to the
default. Topic ISM is denied with its order attribute. Topics IRM and SRM satisfy both their own allow rules and the
pattern ∗R∗ deny rule. So when you allocate a source topic with lbm_src_topic_alloc(), UM accepts the rule that
matches the order attribute default, which is allow.
As a result of the above configuration, UM allows the creation of source topic objects IRM and SRM, and all other
topics, except those that match the regular expression pattern ∗R∗.
54
Sample XML Configuration File
Chapter 4
XML Configuration File DTD
The XML configuration file DTD is integrated into UM and appears below.
56
XML Configuration File DTD
Chapter 5
Attributes Objects
Many UM primitive objects have a corresponding attributes object, which contains the configuration information
specific to that UM object type. You can set configuration options in an attributes object, and supply the attributes
when creating the UM object. This allows assignment of different options for different instances of UM objects. The
following table lists the UM primitive objects and corresponding attributes objects.
UM object
Corresponding Attributes Object(s)
lbm_context_t
lbm_topic_t
lbm_context_attr_t
lbm_src_topic_attr_t, lbm_rcv_topic_attr←_t
lbm_wildcard_rcv_attr_t
lbm_wildcard_rcv←_t
lbm_event_queue←_t
lbm_hfx_t
lbm_event_queue_attr_t
lbm_hfx_attr_t
You call API functions to create attributes objects and set, retrieve, or delete their values. These function names are
based on the attributes object name and are shown in the following table, using the context object as an example.
See the C API for all attributes functions.
Action
Create Attributes Object
UM API function
lbm_context_attr_create()
Set Option from Binary Value
lbm_context_attr_setopt()
Set Option from String Value
lbm_context_attr_str_setopt()
Get Option as Binary Value
lbm_context_attr_getopt()
Get Option as String Value
lbm_context_attr_str_getopt()
Delete Attributes Object
lbm_context_attr_delete()
For other object types, replace context with src_topic, rcv_topic, wildcard_rcv, event_queue, or hfx.
The following sections describe in detail the use of these UM API functions. The functions related to lbm_context←_attr_t objects are used for the purpose of illustration, but the instructions (if not the specifics) apply to all UM
attributes objects.
58
5.1
Attributes Objects
Creating An Attributes Object
In the following example, the call to lbm_context_attr_create() creates the custom attributes object, and initializes
each option from the current default values. Subsequent calls to lbm_context_attr_setopt() or lbm_context_←attr_str_setopt() modify only the option values in the attributes object.
lbm_context_attr_t * attrib;
int rc;
rc = lbm_context_attr_create(&attrib);
if (rc != 0)
{/
* Immediately after UM returns error, capture error details. */
int errnum = lbm_errnum();
const char * errmsg = lbm_errmsg();
fprintf(stderr, "Error %d returned from lbm_context_attr_create(), %s\n",
errnum, errmsg);
}
This example also illustrates the proper way to determine the success or failure of an UM API call. Most UM API
calls return 0 to indicate success, and -1 to indicate failure. To retrieve the specific UM error code for the failure, call
lbm_errnum(). To retrieve a text string describing the error code, call lbm_errmsg().
5.2
Setting an Option from a Binary Value
For an option of type other than "string", call lbm_context_attr_setopt() to set its value. (See the C API reference
for details on this function.) The final two parameters in the function are a pointer to a variable containing the option
value, and a variable of type size_t that contains the correct length of the option value variable.
The example code below sets three options. First, we set operational_mode (context) to sequential. Then we set
the transport_tcp_port_low (context) and transport_tcp_port_high (context) values to 4901 and 4920, respectively.
lbm_context_attr_t * attrib; /* Must have already been created */
int rc;
unsigned short int optval;
size_t optlen;/
* Set the operational_mode */
optlen = sizeof(optval);
optval = LBM_CTX_ATTR_OP_SEQUENTIAL;
rc = lbm_context_attr_setopt(attrib, "operational_mode", &optval, optlen);
if (rc != 0) {/
* Handle error */
}/
* Set transport_tcp_port_low */
optlen = sizeof(optval);
optval = 4901;
rc = lbm_context_attr_setopt(attrib, "transport_tcp_port_low", &optval, optlen);
if (rc != 0) {/
* Handle error */
}/
* Set transport_tcp_port_high */
optlen = sizeof(optval);
5.3 Setting an Option from a String Value
59
optval = 4920;
rc = lbm_context_attr_setopt(attrib, "transport_tcp_port_high", &optval, optlen);
if (rc != 0) {/
* Handle error */
}
5.2.1
Setting an Option from Arrays of Binary Values
There are some configuration options which expect an array of a particular type. The ∗_setopt() function uses its
"optlen" parameter to determine the number of valid elements in the array.
For example, when using umq_ulb_application_set (source) to configure a ULB source's application sets, the lbm←_umq_ulb_receiver_type_entry_t structure is used to define one mapping between receiver type ID and application set index. It is common to have more than one receiver type and/or more than one application set, so the
application code must pass an array of lbm_umq_ulb_receiver_type_entry_t structures. Note how lbm_src_topic←_attr_setopt()'s "optlen" is calculated in the following code:
lbm_umq_ulb_receiver_type_entry_t appsets[32]; / * This application’s worst case
need. */
int optlen, num_valid_elements;
.../
* We need three entries, the equiv of "source umq_ulb_application_set
0:10,20;1:100". */
appsets[0].application_set_index = 0;
appsets[0].id = 10; / * Receiver type ID. */
appsets[1].application_set_index = 0;
appsets[1].id = 20; / * Receiver type ID. */
appsets[2].application_set_index = 1;
appsets[2].id = 100; / * Receiver type ID. */
num_valid_elements = 3;
optlen = num_valid_elements * sizeof(lbm_umq_ulb_receiver_type_entry_t);
rc = lbm_src_topic_attr_setopt(tattr, "umq_ulb_application_set", appsets, optlen);
if (rc != 0) {/
* Handle error */
}
5.3
Setting an Option from a String Value
Setting an option from a string value effectively does the same thing that setting an option from a binary value does.
However, the option value is passed as a null-terminated string, rather than as value and length pointers. UM uses
this mechanism to process options in a configuration file. Thus, the format used for option values must match the
format you would use in a configuration file.
In the following example, as before, we set the operational mode to sequential. Then we set the transport TCP port
low and high values to 4901 and 4920, respectively.
lbm_context_attr_t * attrib; /* Must have already been created */
int rc;/
* Set the operational_mode */
rc = lbm_context_attr_str_setopt(attrib, "operational_mode", "sequential");
if (rc != 0) {/
* Handle error */
}/
60
Attributes Objects
* Set transport_tcp_port_low */
rc = lbm_context_attr_str_setopt(attrib, "transport_tcp_port_low", "4901");
if (rc != 0) {/
* Handle error */
}/
* Set transport_tcp_port_high */
rc = lbm_context_attr_str_setopt(attrib, "transport_tcp_port_high", "4920");
if (rc != 0) {/
* Handle error */
}
5.4
Getting an Option as a Binary Value
Getting an option as a binary value is very similar to setting an option from a binary value: it requires knowledge of
not only the option name, but its type as well. The final two parameters in the call to lbm_context_attr_getopt() are
a pointer to a variable to receive the current option value, and a pointer to a variable of type size_t which contains
the length of the option value variable. This length must be correct for the specified option.
In the example code below, we get the option values for operational mode and the transport TCP port low and high
values.
lbm_context_attr_t * attrib; /* Must have already been created */
int rc;
unsigned short int optval;
size_t optlen;/
* Get the operational_mode */
optlen = sizeof(optval);
rc = lbm_context_attr_getopt(attrib, "operational_mode", &optval, &optlen);
if (rc != 0) {/
* Handle error */
}/
* optval now contains LBM_CTX_ATTR_OP_EMBEDDED or LBM_CTX_ATTR_OP_SEQUENTIAL *//
* Get transport_tcp_port_low */ optlen = sizeof(optval);
rc = lbm_context_attr_getopt(attrib, "transport_tcp_port_low", &optval, &optlen);
if (rc != 0) {/
* Handle error */
}/
* optval now contains the value of transport_tcp_port_low, which should be 4901 *//
* Get transport_tcp_port_high */ optlen = sizeof(optval);
rc = lbm_context_attr_getopt(attrib, "transport_tcp_port_high", &optval, &optlen);
if (rc != 0) {/
* Handle error */
}/
* optval now contains the value of transport_tcp_port_high, which should be 4920 */
5.5
Getting an Option as a String Value
Getting an option as a string value effectively does the same thing that getting an option as a binary value does.
However, the option value is returned as a null-terminated string, just as you would specify the option value in a
5.6 Deleting an Attributes Object
61
configuration file. The final two parameters in the call to lbm_context_attr_str_getopt() are a pointer to a string
variable to receive the current option value, and a pointer to a variable of type size_t which contains the maximum
size of the option value string variable.
In the example code below, we get the option values for operational mode and the transport TCP port low and high
values.
lbm_context_attr_t * attrib; /* Must have already been created */
int rc;
char optval_string[256];/
* Get the operational_mode */
optlen = sizeof(optval_string);
rc = lbm_context_attr_str_getopt(attrib, "operational_mode", optval_string,
&optlen);
if (rc != 0) {/
* Handle error */
}/
* optval_string now contains either "embedded" or "sequential" *//
* Get transport_tcp_port_low */
optlen = sizeof(optval_string);
rc = lbm_context_attr_str_getopt(attrib, "transport_tcp_port_low",
optval_string, &optlen);
if (rc != 0) {/
* Handle error */
}/
* optval_string now contains the string value of transport_tcp_port_low,
which should be "4901" *//
* Get transport_tcp_port_high */ optlen = sizeof(optval_string);
rc = lbm_context_attr_str_getopt(attrib, "transport_tcp_port_high",
optval_string, &optlen);
if (rc != 0) {/
* Handle error */
}/
* optval_string now contains the string value of transport_tcp_port_high,
which should be "4920" */
5.6
Deleting an Attributes Object
Once the attributes object is no longer needed, it should be deleted.
lbm_context_attr_t * attrib; /* Must have already been created */
int rc;
rc = lbm_context_attr_delete(attrib);
if (rc != 0) {/
* Handle error */
}
62
Attributes Objects
Chapter 6
Access to Current Operating Options
After a UM object is created, the current operating option values can be retrieved, and a small subset of its current
operating options can be modified. UM API functions supporting such actions operate on the object itself, rather
than on an attributes object.
6.1
Retrieving Current Option Values
Almost all UM objects allow their current attributes' option values to be retrieved during operation. UM API functions
supporting such actions operate on the object itself.
The UM objects which support these actions are lbm_src_t, lbm_rcv_t, lbm_context_t, and lbm_event_queue_t.
For each such object, there are corresponding API functions to get an option as a binary value, and get an option
as a string value. These function names are based on the object name, suffixed with _getopt(), and _str_getopt().
As an illustration of this convention, the API functions for working with lbm_event_queue_t objects are shown in
the following table.
Action
Get Option from Binary Value
UM API function
lbm_event_queue_getopt()
Get Option from String Value
lbm_event_queue_str_getopt()
For other object types, replace event_queue with context, src_topic, rcv_topic, wildcard_rcv, or hfx.
6.1.1
Getting Current Option as a Binary Value
Getting an option as a binary value is very similar to setting an option from a binary value: it requires knowledge of
not only the option name, but its type as well. The final two parameters in the call to lbm_event_queue_getopt()
are a pointer to a variable to receive the current option value, and a pointer to a variable of type size_t which
contains the length of the option value variable. This length must be correct for the specified option.
In the example code below, the option value for the queue size warning is retrieved.
unsigned long int optval;
size_t optlen;
64
Access to Current Operating Options
lbm_event_queue_t evq; /* must be previously created */
int rc;/
* Get the queue size warning value */
optlen = sizeof(optval);
rc = lbm_event_queue_getopt(&evq, "queue_size_warning", &optval, &optlen);
if (rc != 0) {/
* Handle error */
}/
* optval now contains the value of queue_size_warning, which should be 5000 */
6.1.2
Getting Current Option as a String Value
Getting an option as a string value effectively does the same thing that getting an option as a binary value does.
However, the option value is returned as a null-terminated string, just as you would specify the option value in a
configuration file. The final two parameters in the call to lbm_event_queue_str_getopt() are a pointer to a string
variable to receive the current option value, and a pointer to a variable of type size_t which contains the maximum
size of the option value string variable.
In the example code below, the option value for the queue size warning is retrieved.
char optval_string[256];
size_t optlen;
lbm_event_queue_t evq; /* must be previously created */
int rc;/
* Get the queue size warning value */
optlen = sizeof(optval_string);
rc = lbm_event_queue_str_getopt(&evq, "queue_size_warning", optval_string, &optlen);
if (rc != 0) {/
* Handle error */
}/
* optval now contains the value of queue_size_warning, which should be "5000" */
6.2
Modifying Current Option Values
A small subset of UM object options may be modified after the object is created. See the individual option descriptions to determine if an options value may be changed after the UM object is created.
The UM objects which support these actions are lbm_src_t, lbm_rcv_t, lbm_context_t, and lbm_event_queue_t.
For each such object, there are corresponding API functions to set an option from a binary value and set an option
from a string value. These function names are based on the object name, suffixed with _setopt() and _str_setopt().
As an illustration of this convention, the API functions for working with lbm_event_queue_t objects are shown in
the following table.
Action
Set Option from Binary Value
UM API function
lbm_event_queue_setopt()
Set Option from String Value
lbm_event_queue_str_setopt()
6.2 Modifying Current Option Values
65
For other object types, replace event_queue with context, src_topic, rcv_topic, wildcard_rcv, or hfx.
The following sections describe in detail the use of these UM API functions. The functions related to lbm_event←_queue_t objects are used for the purpose of illustration, but the instructions (if not the specifics) apply to all such
UM objects.
6.2.1
Setting Current Option from a Binary Value
Setting an option from a binary value requires knowledge of not only the option name, but its type and allowable
values as well. The final two parameters in the call to lbm_event_queue_setopt() are a pointer to a variable which
contains the option value to be set, and a pointer to a variable of type size_t which contains the length of the option
value variable. This length must be correct for the specified option.
In the example code below, we set the queue size warning to 5000 events.
unsigned long int optval;
size_t optlen;
lbm_event_queue_t evq; /* must be previously created */
int rc;/
* Set the queue size warning */
optlen = sizeof(optval);
optval = 5000;
rc = lbm_event_queue_setopt(&evq, "queue_size_warning", &optval, &optlen);
if (rc != 0) {/
* Handle error */
}
6.2.2
Setting Current Option from a String Value
Setting an option from a string value effectively does the same thing that setting an option from a binary value does.
However, the option value is passed as a null-terminated string, rather than as value and length pointers. This is
similar to the mechanism used by UM to process options in a configuration file. Thus, the format used for option
values must match the format you would use in a configuration file.
As before, we set the queue size warning to 5000 events.
lbm_event_queue_t evq; /* must be previously created */
int rc;/
* Set the queue size warning */
rc = lbm_event_queue_setopt(&evq, "queue_size_warning", "5000");
if (rc != 0) {/
* Handle error */
}
66
Access to Current Operating Options
Chapter 7
Example Configuration Scenarios
7.1
Highest Throughput
The following configuration option tunes UM for the highest possible throughput.
#
# LBM can be configured to make efficient use of CPU time, leading
# to the highest-possible throughput (bytes per second or messages
# per second). This may come at the expense of latency at low
# message rates. The following line configures LBM to accumulate
# 8KB of messages (or for wait implicit_batching_interval) before sending.
#
source implicit_batching_minimum_length 8192
7.2
Lowest Latency
This is an example configuration that favors low latency at the expense of higher CPU utilization and potentially
lower throughput.
#
# Latency can be reduced at the expense of network efficiency and
# system CPU time by adjusting implicit batching parameters. The
# default parameters hold messages for up to 200 milliseconds or until
# 2048 bytes are waiting to go. The lowest possible latency is
# obtained by setting the minimum batching length to 1 byte, which
# effectively disables the implicit batching feature. For example:
#
context mim_implicit_batching_minimum_length 1
source implicit_batching_minimum_length 1
#
# Latency can be kept to a minimum with UM by writing receiving
# applications that can accept messages in the order they arrive.
# See https://communities.informatica.com/infakb/faq/5/Pages/80043.aspx
# for more information. Here’s how to use arrival-order delivery:
#
receiver ordered_delivery 0
#
68
Example Configuration Scenarios
# Disable Nagel’s algorithm (batching) for TCP responses to eliminate
# queuing latency when sending only single responses.
#
context response_tcp_nodelay 1
#
# If you are running a LAN environment with under 100 machines, you can
# drastically improve your recovery related latencies without significant
# additional network overhead by using the following UM loss recovery parameter.
# See https://communities.informatica.com/infakb/faq/5/Pages/80070.aspx
# for additional information about this and other recovery parameters.
#
receiver transport_lbtrm_nak_backoff_interval 10
7.3
Creating Multicast Sources
This is an example configuration file that changes the default transport to reliable multicast so all sources created
send messages over LBT-RM.
#
# UM can be configured to create sources using the LBT-RM reliable
# multicast protocol instead of the default TCP.
#
source transport LBT-RM
#
# Stable and reliable operation with multicast requires careful
# setting of rate control limits.
#
# It’s generally best to start with small limits and gradually
# increase them after testing indicates that they can be safely
# sustained on your network.
#
# The following example limits (new) data to 10 Mbps and retransmissions
# to 1 Mbps (10%).
#
context transport_lbtrm_data_rate_limit 10000000
context transport_lbtrm_retransmit_rate_limit 1000000
7.4
Disabling Aspects of Topic Resolution
If you need to reduce the amount of Topic Resolution traffic on your network, use the following Configuration options
and values in a Ultra Messaging Configuration file.
Note
Ultra Messaging does not recommend disabling both advertisements and queries because topics may not
resolve at all.
7.4 Disabling Aspects of Topic Resolution
7.4.1
69
Disabling Topic Advertisements
You can disable topic advertisements in the Initial Phase, Sustaining Phase or both phases of topic resolution.
Disabling Initial Phase Advertisements
Use the following options to disable topic advertisements in only the Initial Phase.
source resolver_advertisement_minimum_initial_interval 0
source resolver_advertisement_maximum_initial_interval 0
Disabling Sustaining Phase Advertisements
Use the following option to disable topic advertisements in only the Sustaining Phase.
source resolver_advertisement_sustain_interval 0
7.4.2
Disabling Receiver Topic Queries
You can disable the querying of topics by receivers in the Initial Phase, Sustaining Phase or both phases of topic
resolution.
Disabling Initial Phase Queries
Use the following options to disable topic queries in only the Initial Phase.
receiver resolver_query_minimum_initial_interval 0
receiver resolver_query_maximum_initial_interval 0
Disabling Sustaining Phase Queries
Use the following options to disable topic queries in only the Sustaining Phase.
receiver resolver_query_sustain_interval 0
receiver resolution_number_of_sources_query_threshold 0
7.4.3
Disabling Wildcard Topic Queries
Use the following options to disable topic queries by wildcard receivers.
wildcard_receiver resolver_query_minimum_interval 0
wildcard_receiver resolver_query_maximum_interval 0
7.4.4
Disabling Store (Context) Name Queries
When using Persistence, use the following options to disable context name queries by sources.
resolver_context_name_query_maximum_interval 0
resolver_context_name_query_minimum_interval 0
70
7.4.5
Example Configuration Scenarios
All But the Minimum Topic Resolution Traffic
A minimalist approach to topic resolution can take different forms based on you requirements. One approach is
to disable all traffic except for queries in the sustaining phase. Add the following settings to your Ultra Messaging
configuration file to implement this approach.
source resolver_advertisement_minimum_initial_interval 0
source resolver_advertisement_sustain_interval 0
receiver resolver_query_minimum_initial_interval 0
receiver resolution_number_of_sources_query_threshold 1
wildcard_receiver resolver_query_minimum_interval 0
7.5
Unicast Resolver
To use the unicast resolver, use a configuration file like the following example:
#
# Topic resolution can be configured to use unicast traffic with an
# LBM resolver daemon (lbmrd) instead of the default which uses multicast.
# Be sure to insert the IP address of your lbmrd below.
#
context resolver_unicast_daemon 127.0.0.1:15380
7.6
Re-establish Pre-4.0 Topic Resolution
Ultra Messaging topic resolution prior to LBM Version 4.0 did not have resolution phases. To implement pre-4.0
topic resolution, include the following configuration option changes in your Ultra Messaging configuration file.
# ----- Disable Advertisements in 4.0 Initial Phase
source resolver_advertisement_minimum_initial_interval 0
# ----- Re-establish pre-4.0 Advertisement Behavior
source resolver_advertisement_minimum_sustain_duration 0
context resolver_sustain_advertisement_bps 0
# ----- Disable Queries in 4.0 Initial Phase
receiver resolver_query_minimum_initial_interval 0
# ----- Re-establish pre-4.0 Query Behavior
receiver resolver_query_sustain_interval 100
receiver resolver_query_minimum_sustain_duration 0
context resolver_sustain_query_bps 0
receiver resolution_number_of_sources_query_threshold 1
# ----- Re-establish pre-4.0 Wildcard Query Behavior
wildcard_receiver resolver_query_minimum_interval 0
7.7 Re-establish Pre-LBM 3.3 (Pre-UME 2.0) Port Defaults
7.7
71
Re-establish Pre-LBM 3.3 (Pre-UME 2.0) Port Defaults
To use the early default ports (prior to LBM 3.3 and UME 2.0), the following configuration file may be used.
context mim_destination_port 4401
context mim_incoming_destination_port 4401
context mim_outgoing_destination_port 4401
context resolver_multicast_port 2965
context resolver_multicast_incoming_port 2965
context resolver_multicast_outgoing_port 2965
context resolver_unicast_destination_port 5380
context resolver_unicast_port_high 4406
context resolver_unicast_port_low 4402
source transport_lbtrm_destination_port 4400
context transport_lbtrm_source_port_high 4399
context transport_lbtrm_source_port_low 4390
context transport_lbtru_port_high 4389
context transport_lbtru_port_high 4380
receiver transport_lbtru_port_high 4379
receiver transport_lbtru_port_low 4360
context request_tcp_port_high 4395
context request_tcp_port_low 4391
context transport_tcp_port_high 4390
context transport_tcp_port_low 4371
source ume_primary_store_port 4567
source ume_secondary_store_port 4567
source ume_tertiary_store_port 4567
Note
Alternatively, UM will use the early port settings when the environment variable LBM_USE_ORIG_DEFAU←LT_PORTS is set to 1.
7.8
Configure New Port Defaults
In the unusual case that you must run older versions of Ultra Messaging (less than LBM 3.3 / UME 2.0) on certain
machine(s) and need these older version to work with the machines running the current versions of UMS and UMP,
you can use the following configuration file for the older versions to synchronize port usage between old and current
versions.
context mim_destination_port 14401
context mim_incoming_destination_port 14401
context mim_outgoing_destination_port 14401
context resolver_multicast_port 12965
context resolver_multicast_incoming_port 12965
context resolver_multicast_outgoing_port 12965
context resolver_unicast_destination_port 15380
context resolver_unicast_port_high 14406
context resolver_unicast_port_low 14402
source transport_lbtrm_destination_port 14400
context transport_lbtrm_source_port_high 14399
context transport_lbtrm_source_port_low 14390
context transport_lbtru_port_high 14389
context transport_lbtru_port_high 14380
receiver transport_lbtru_port_high 14379
receiver transport_lbtru_port_low 14360
context request_tcp_port_high 14395
72
context
context
context
source
source
source
Example Configuration Scenarios
request_tcp_port_low 14391
transport_tcp_port_high 14390
transport_tcp_port_low 14371
ume_primary_store_port 14567
ume_secondary_store_port 14567
ume_tertiary_store_port 14567
Chapter 8
Interrelated Configuration Options
Some Ultra Messaging configuration options are related in ways that might not be immediately apparent. Changing
the value for one option without adjusting its related option can cause problems such as NAK storms, tail loss, etc.
This section identifies these relationships and recommends a best practice for setting the interrelated options.
The following sections discuss configuration option relationships.
8.1
Preventing NAK Storms with NAK Intervals
The NAK generation interval should be sufficiently longer than the NAK backoff interval so that the source, after
receiving the first NAK from a receiver, has time to retransmit the missing datagram and prevent a NAK storm from
all receivers. LBTRM, LBTRU, and MIM all use NAK generation and backoff intervals. The NAK behavior for all
transports is the same.
Interrelated Options:
• transport_lbtrm_nak_backoff_interval (receiver)
• transport_lbtrm_nak_generation_interval (receiver)
• transport_lbtru_nak_backoff_interval (receiver)
• transport_lbtru_nak_generation_interval (receiver)
• mim_nak_backoff_interval (context)
• mim_nak_generation_interval (context)
Recommendation:
Set the NAK generation interval to at least 2x the NAK backoff interval.
Example:
#
# To avoid NAK storms, set NAK generation interval to at least 2x the
# NAK backoff interval.
#
receiver transport_lbtrm_nak_backoff_interval 200
# .2 seconds
receiver transport_lbtrm_nak_generation_interval 10000 # 10 seconds
See also:
Transport LBT-RM Reliability Options
Transport LBT-RU Reliability Options
Multicast Immediate Messaging Reliability Options
74
Interrelated Configuration Options
8.2
Preventing Tail Loss With TSNI and NAK Interval Options
Tail loss refers to the situation where a receiver (subscriber) does not receive the last few (tail) messages sent
by a source (publisher). When unrecoverable loss occurs on a transport, due to the possibility of multiple topiclevel messages being contained in a single transport-level sequence number (due to implicit batching), a receiver
does not know which particular messages were unrecoverable until the arrival of later messages (revealing earlier
gaps in topic-level sequence number) or until the arrival of Topic Sequence Number Information (TSNI) records
sent periodically by a publisher. Specific topic-level knowledge of sequence gaps is a prerequisite for the receiver
to deliver event callbacks to the application indicating that unrecoverable loss has occurred, because those event
callbacks are per-receiver (topic-level). A TSNI active threshold that is too small relative to the TSNI and/or NAK
generation interval may prevent the reporting of tail loss to the application, especially with ordered delivery.
Interrelated Options:
• transport_topic_sequence_number_info_active_threshold (source)
• transport_topic_sequence_number_info_interval (source)
• transport_lbtrm_nak_generation_interval (receiver)
• transport_lbtru_nak_generation_interval (receiver)
Recommendation:
Set the TSNI active threshold to at least 4x the topic sequence number info interval (TSNI) plus the NAK
generation interval.
Example:
#
# NOTE: transport_topic_sequence_number_info_active_threshold is in seconds.
#
source
transport_topic_sequence_number_info_interval 2000
receiver transport_lbtrm_nak_generation_interval
10000
source
transport_topic_sequence_number_info_active_threshold 60
See also:
Transport LBT-RM Reliability Options
Transport LBT-RU Reliability Options
8.3
Preventing IPC Receiver Deafness With Keepalive Options
With an LBT-IPC transport, an activity timeout that is too small relative to the session message interval may cause
receiver deafness. If a timeout is too short, the keepalive messages might not be received in time to prevent the
receiver from being deleted or disconnecting because the source appears to be gone.
Interrelated Options:
• transport_lbtipc_activity_timeout (receiver)
• transport_lbtipc_sm_interval (source)
8.4 Preventing Erroneous LBT-RM/LBT-RU Session Timeouts
75
Recommendations:
Set the activity timeout to at least 2x the session message interval
Example:
#
# To avoid receiver deafness:
# - set client activity timeout to at least 2x the acknowledgement interval.
# - set activity timeout to at least 2x the session message interval.
#
receiver transport_lbtipc_activity_timeout 60000
source
transport_lbtipc_sm_interval
10000
See also:
Transport LBT-IPC Operation Options
8.4
Preventing Erroneous LBT-RM/LBT-RU Session Timeouts
An LBT-RM or LBT-RU receiver-side quiescent timeout may delete a transport session that a source is still active
on. This can happen if the timeout is too short relative to the source's interval between session messages (which
serve as a session keepalive).
Interrelated Options:
• transport_lbtrm_activity_timeout (receiver)
• transport_lbtrm_sm_maximum_interval (source)
• transport_lbtru_activity_timeout (receiver)
• transport_lbtru_sm_maximum_interval (source)
Recommendations:
Set the receiver LBT-RM or LBT-RU activity timeout to at least 3x the source session message maximum
interval.
Example:
#
# To avoid erroneous session timeouts, set receiver transport activity
# timeout to at least 3x the source session message maximum interval.
#
receiver transport_lbtrm_activity_timeout
60000
source
transport_lbtrm_sm_maximum_interval 10000
receiver transport_lbtru_activity_timeout
60000
source
transport_lbtru_sm_maximum_interval 10000
See also:
Transport LBT-RM Operation Options
Transport LBT-RU Operation Options
76
Interrelated Configuration Options
8.5
Preventing Errors Due to Bad Multicast Address Ranges
Sometimes it is easy to accidentally reverse the low and high values for LBT-RM multicast addresses, which actually
creates a very large range. Aside from excluding intended addresses, this can cause error conditions.
Interrelated Options:
• transport_lbtrm_multicast_address_low (context)
• transport_lbtrm_multicast_address_high (context)
Recommendations:
Ensure that the intended low and high values for LBT-RM multicast addresses are not reversed
Example:
#
# To avoid incorrect LBT-RM multicast address ranges, ensure that you have not
# reversed the low and high values.
#
context transport_lbtrm_multicast_address_low 224.10.10.10
context transport_lbtrm_multicast_address_high 224.10.10.14
See also:
Transport LBT-RM Network Options
8.6
Preventing Store Timeouts
When using Persistence, a store may be erroneously declared unresponsive if its activity timeout expires before it
has had adequate opportunity to verify it is still active via activity check intervals.
Interrelated Options:
• ume_store_activity_timeout (source)
• ume_store_check_interval (source)
Recommendations:
Set the store activity timeout to at least 5x the activity check interval
Example:
#
# To avoid erroneous store activity timeouts, set the activity
# timeout to at least 5x the activity check interval.
#
source ume_store_activity_timeout 3000
source ume_store_check_interval 500
8.7 Preventing ULB Timeouts
8.7
77
Preventing ULB Timeouts
When using ULB queuing, ULB source or receiver may be erroneously declared unresponsive if its activity timeout
expires before it has had adequate opportunities to attempt to re-register via activity check intervals if the source
appears to be inactive. It is also possible for sources to attempt to reassign messages that have already been
processed.
Interrelated Options:
• umq_ulb_source_activity_timeout (receiver)
• umq_ulb_source_check_interval (receiver)
• umq_ulb_application_set_message_reassignment_timeout (source)
• umq_ulb_application_set_receiver_activity_timeout (source)
• umq_ulb_check_interval (source)
Recommendations:
Set the ULB source activity timeout to at least 5x the ULB source activity check interval.
Set the ULB application set message reassignment timeout to at least 5x the ULB check interval.
Set the ULB receiver activity timeout to at least 5x the ULB check interval.
Example:
#
# To avoid erroneous ULB source, receiver or application set message activity
# timeouts, set the activity timeout to at least 5x the activity check interval.
#
receiver umq_ulb_source_activity_timeout 10000
receiver umq_ulb_source_check_interval
1000
source
umq_ulb_application_set_message_reassignment_timeout 50000
source
umq_ulb_application_set_receiver_activity_timeout
10000
source
umq_ulb_check_interval 1000
See also:
Ultra Messaging Queuing Options ]]])
8.8
Preventing Unicast Resolver Daemon Timeouts
A unicast resolver daemon may be erroneously declared inactive if its activity timeout expires before it has had
adequate opportunity to verify that it is still alive.
Interrelated Options:
• resolver_unicast_activity_timeout (context)
• resolver_unicast_check_interval (context)
Recommendations:
Set the unicast resolver daemon activity timeout to at least 5x the activity check interval. Or, if activity notification
is not desired, set both options to 0.
78
Interrelated Configuration Options
Example:
#
# To avoid erroneous unicast resolver daemon timeouts, set the activity
# timeout to at least 5x the activity check interval.
#
context resolver_unicast_activity_timeout 1000
context resolver_unicast_check_interval 200
See also:
UDP-Based Resolver Operation Options
8.9
Preventing Undetected Late Join Loss
If during a Late Join operation, a transport times out while a receiver is requesting retransmission of missing messages, this can cause lost messages to go undetected and likely become unrecoverable.
Interrelated Options:
• retransmit_request_generation_interval (receiver)
• transport_tcp_activity_timeout (receiver)
• transport_lbtrm_activity_timeout (receiver)
• transport_lbtru_activity_timeout (receiver)
• transport_lbtipc_activity_timeout (receiver)
Recommendations:
Set the Late Join retransmit request interval to a value less than its transport's activity timeout value
Example:
#
# To avoid a transport inactivity timeout while requesting Late Join
# retransmissions, set the Late Join retransmit request interval to a value
# less than its transport’s activity timeout.
#
receiver retransmit_request_generation_interval 10000
receiver transport_lbtrm_activity_timeout 60000
See also:
Late Join Options
8.10
Preventing Undetected Loss
It is possible that an unrecoverable loss due to unsatisfied NAKs or a transport activity timeout may go unreported
if the delivery controller loss check is disabled or has too long an interval. For UMP stores, the loss check interval
must be enabled. Two options (three, if using LBT-RM) are interrelated and must be set according to the guidelines
below.
8.11 Preventing Store Registration Hangs
79
Interrelated Options:
• delivery_control_loss_check_interval (receiver)
• transport_lbtrm_activity_timeout (receiver)
• transport_lbtrm_nak_generation_interval (receiver)
• transport_lbtru_activity_timeout (receiver)
Recommendations:
For LBT-RM, set the transport activity timeout to value greater than the sum of the delivery control loss check
interval and the NAK generation interval. Also, set the NAK generation interval to at least 4x the delivery control
loss check interval.
For LBT-RU, set the transport activity timeout to value greater than the delivery control loss check interval
For UMP, always enable and set accordingly the delivery control loss check interval when configuring a store
Example:
#
# To avoid undetected or unreported loss, set NAK generation to 4x the delivery
# control check interval, and ensure that these two combined are less than the
# transport activity timeout
#
receiver delivery_control_loss_check_interval 2500
receiver transport_lbtrm_activity_timeout 60000
receiver transport_lbtrm_nak_generation_interval 10000
See also:
Delivery Control Options
8.11
Preventing Store Registration Hangs
The following configuration options come into play when sources register with stores in a lossy environment:
Interrelated Options:
• ume_sri_request_interval (receiver)
• ume_sri_request_maximum (receiver)
• transport_topic_sequence_number_info_request_interval (receiver)
• transport_topic_sequence_number_info_request_maximum (receiver)
• transport_tcp_activity_timeout (receiver)
• transport_lbtrm_activity_timeout (receiver)
• transport_lbtru_activity_timeout (receiver)
• transport_lbtipc_activity_timeout (receiver)
The sri_request "interval" and "maximum" options multiply to define a duration over which the receiver requests
Store Information Records (SRI) messages from the source. Similarly, the transport_topic_sequence_number_←info_request "interval" and "maximum" options multiply to define a duration over which the receiver requests Transport Topic Sequence Number Info (TSNI) messages from the source.
Recommendations:
80
Interrelated Configuration Options
The two request durations should be twice the value of the appropriate transport activity timer.
Example:
#
# To avoid hung store registration, set the durations of the SRI and TSNI
# requests to 2x the transport activity timeout.
#
receiver transport_lbtrm_activity_timeout 60000
receiver ume_sri_request_maximum 120
receiver ume_sri_request_interval 1000
receiver transport_topic_sequence_number_info_request_maximum 120
receiver transport_topic_sequence_number_info_request_interval 1000
Warning
As of this version of UM, the default values for these options do not satisfy this recommendation. Users are
advised to double the values for umesrirequestmaximumreceiver and transport_topic_sequence_number_←info_request_maximum (receiver).
Chapter 9
General Configuration Guidelines
9.1
Case Sensitivity
All Ultra Messaging scope, option, and value strings are case-insensitive. Thus, the following are identical:
context fd_management_type wincompport
Context Fd_Management_Type WinCompPort
CONTEXT FD_MANAGEMENT_TYPE WINCOMPPORT
9.2
Specifying Interfaces
The ∗_interface options require a network interface, usually supplied as a string (from a configuration file or in
source code via ∗_attr_str_setopt()), the syntax used for network interface specifications is CIDR notation:
a.b.c.d/num
where 'num' is the optional number of leading 1 bits in the netmask. If the '/num' is omitted, it defaults to 32
(netmask 255.255.255.255), which means that it must be an exact match for the interface's IP address. However, if
'/num' is supplied, it tells Ultra Messaging to find an interface within that network. This makes it easier to share a
configuration file between many (possibly multi-homed) machines on the same network.
For example:
context resolver_unicast_interface 192.168.0.0/24
specifies a netmask of 255.255.255.0 and would match the interface 192.168.0.3 on one host, and 192.168.0.251
on another host.
You can also set network interfaces by device name. When setting a configuration option's interface by device name,
you must use double quotes, as illustrated below.
context resolver_unicast_interface "en0"
Finally, you can also set network interfaces by DNS host name. When setting a configuration option's interface by
DNS name, simply replace the dotted IP address with the host name, as illustrated below.
context resolver_unicast_interface myhost.mydomain.com/24
82
General Configuration Guidelines
Notice the use of the optional netmask even though the host name will typically resolve to a specific host IP address.
In this case, UM will zero out the host bits of myhost's address and find any interface within that network. If the
netmask is omitted, an exact match to myhost's address is needed.
9.2.1
Interface Device Names and XML
As mentioned above, when a device name is supplied as an interface specification, the device name must be
enclosed in double quotes. This presents a problem when the configuration option is specified within an XML file.
In XML files, the values for all options must be enclosed in double quotes, but those quotes are only used by the
XML parser to delimit the value. The quote characters themselves are not passed to the UM configuration parser.
But the UM configuration parser needs the double quotes to indicate that the device name is being used.
The solution is to use the """ escape when specifying device names for interfaces within an XML file. The XML
parser will convert those to actual double quote characters as part of the value passed to UM.
For example:
Another example:
(The repeated semicolon looks strange; the first one closes the """, and the second one separates the resolver_←multicast_interface option from the transport option.)
9.3
Socket Buffer Sizes
When specifying send or receive socket buffer sizes, keep the following platform-specific information in mind.
Linux
The kernel value net.core.rmem_max dictates the highest value allowed for a receive socket. The kernel value
net.core.wmem_max dictates the highest value allowed for a sending socket. Increase these values to increase
the amount of buffering allowed.
Windows
Windows should allow socket buffer sizes to be set very high if needed without requiring registry changes.
See our whitepaper Topics in High Performance Messaging for background and guidelines on UDP
buffer sizing.
9.5 Reference Entry Format
9.4
83
Port Assignments
There are a large number of configuration options which are network port numbers. In many cases, ranges of
ports are specified so that multiple instances of UM-based programs can be run on the same machine without
interference. Each instance will find a free port in the configured range. However, if the range is not large enough,
an instance of UM can fail to initialize due to ports not being available.
Port range exhaustion can also happen if other software packages assign to ports in the range configured for UM.
Users should be careful to configure all their networking packages to use non-overlapping port numbers.
9.4.1
Ephemeral Ports
The operating system allocates a range of ports for ephemeral ports. These ports are allocated dynamically asneeded by networking packages, including UM, for sockets that don't need a well-known, predictable port number.
See Wikipedia's article Ephemeral port for ephemeral port ranges used by popular operating systems.
UM port configurations should avoid the host's ephemeral port range. Since these ports are allocated dynamically
by the operating system, these allocations can interfere with UM by exhausting UM port ranges.
9.4.2
Network VS Host Order
When the UM C API is used to set configuration options programmatically, port numbers can be specified as a string
or as a binary value. For example, here is an option being set by binary value:
unsigned short int optval = 4901; / * host byte order required */
size_t optlen = sizeof(optval);
rc = lbm_context_attr_setopt(attrib, "transport_tcp_port_low", &optval, optlen);
See Setting an Option from a Binary Value.
There are some port options whose binary values must be supplied in network order. For example:
unsigned short int optval = htons(4901); / * network byte order required */
size_t optlen = sizeof(optval);
rc = lbm_source_attr_setopt(attrib, "transport_tcp_port", &optval, optlen);
It is generally the case where setting a port to a specific value (i.e. not setting up a range) requires network order.
Whereas setting the high and low port values of a range are done in host order.
The reference documentation for each port option specifies the byte order required when binary values are being
specified. For example, transport_tcp_port (source) has a table row that says:
Byte
order:
9.5
Network
Reference Entry Format
This section describes the format of each option reference entry.
Each entry begins with a brief description of the option. Following the description is a series of items that defines
84
General Configuration Guidelines
permissible usage and describes the values for the option.
Scope
Defines the scope to which the option applies.
Type
Defines the data type of the option. The type is required for calls to the ∗_setopt() and ∗_getopt() API functions.
Units
Defines the units in which the option value is expressed. This item is optional.
Default value
For range-valued options, indicates the base default value for the option.
Byte order
For options whose value is an IP address or port, defines the byte ordering (Host or Network) expected by the
API for ∗_setopt() calls, and returned by the API for ∗_getopt() calls.
May be set during operation
If an option may be set after the UM object is created, it is so indicated here.
Next, for enumerated-valued options with limited specific choices, a table details the permissible String Value (configuration file), Integer Value (programmatic attribute setting), and a Description of each choice that includes default
value designations.
Alternately, for switch-valued options (0 or 1), a table describes the meaning of each of the two possible values. The
default value is noted within the description.
Chapter 10
Special Notes
10.1
Configuring Multi-Homed Hosts
By default, UM will select the first multicast-capable, non-loopback interface for multicast topic resolution. If you are
fortunate, on a multi-homed host, the correct interface will be selected. However, this fortuitous selection should not
be relied upon. Moving the interface card to a different slot, a change in the operating system kernel, and numerous
other factors can lead to a different ordering of interfaces as reported by the operating system. This in turn can lead
UM to a select a different interface after the change.
It is strongly recommended that the actual interface be specified. The resolver_multicast_interface (context) option
allows you to explicitly specify the multicast interface. Note that this also changes the interface for LBT-RM and
multicast immediate messaging.
Other interface options:
resolver_unicast_interface (context) when using the unicast resolver
request_tcp_interface (context) when using the request/response messaging
transport_lbtru_interface (receiver)
transport_lbtru_interface (source)
transport_tcp_interface (receiver)
transport_tcp_interface (source)
TCP transport:
transport_tcp_port_low (context)
transport_tcp_port_high (context)
transport_tcp_port (source)
LBT-RM transport:
transport_lbtrm_source_port_low (context)
transport_lbtrm_source_port_high (context)
transport_lbtrm_destination_port (source)
LBT-RU transport:
transport_lbtru_port_low (context)
transport_lbtru_port_high (context)
transport_lbtru_port (source)
transport_lbtru_port_low (receiver)
transport_lbtru_port_high (receiver)
86
Special Notes
Multicast immediate messaging:
mim_destination_port (context)
mim_incoming_destination_port (context)
mim_outgoing_destination_port (context)
Requests:
request_tcp_port (context)
request_tcp_port_low (context)
request_tcp_port_high (context)
In addition, since machines acting as a firewall are often multi-homed as well, see Configuring Multi-Homed Hosts
for additional considerations.
10.2
Traversing a Firewall
To use UM across a firewall, several port options may need to be changed. The options of interest include:
Multicast resolver:
resolver_multicast_port (context)
Unicast resolver:
resolver_unicast_port (context)
resolver_unicast_port_low (context)
resolver_unicast_port_high (context)
resolver_unicast_destination_port (context)
Chapter 11
Major Options
Options in this group have a major impact on the operation of Ultra Messaging. Most UM application developers will
need to be aware of the default values of these options or perhaps override them.
11.1
Reference
11.1.1
broker (context)
Add a broker specification to the list of brokers. Unlike most other UM settings, every time this setting is called,
it adds one or more service specifications to the list, and does NOT overwrite previous specifications.
For the configuration file as well as string API method of setting this option, you can specify multiple brokers with
a comma or semicolon-separated list on a single line. Each entry contains the broker IP address (or domain
name of the IP address) and destination port in the format IP:Dest_Port[,IP:Dest_Port].
An entry or string with the IP address of 0.0.0.0 and port 0 removes all previous broker specifications.
When the binary form of option setting is used, UM does NOT expect an array of structures. Instead, only one
broker specification can be supplied for each call to lbm_context_attr_setopt(). However, when the binary
form of option retrieval lbm_context_attr_getopt() is used, the list of brokers is returned as an array, and the
optlen parameter should be set as:
optlen = (max_num_brokers * sizeof(lbm_transport_broker_entry_t));
Scope:
context
Type:
lbm_transport_broker_entry_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UMQ 6.8
88
Major Options
11.1.2
compatibility_include_pre_um_6_0_behavior (context)
Enable Ultra Messaging 6.x applications to inter-operate with pre-6.0 applications.
Enabling this option increases overhead data on the wire and slightly changes some operational behaviors of
UMP sources.
Scope:
context
int
Type:
When
Set:
Version:
11.1.3
to
Can only be set during object initialization.
This option was implemented in UM 6.7
String value
Integer value
Description
"1"
1
Inter-operate with pre-6.0 applications.
"0"
0
Disable Inter-operation with pre-6.0 applications. Default for all.
context_event_function (context)
Callback function (and associated client data pointer) that is called when a context event occurs. This callback
may be called inline or from an event queue, if one is given.
If called inline, the callback function used should not block or it will block the context thread processing. See
lbm_context_event_cb_proc.
Scope:
context
Type:
lbm_context_event_func_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UMQ 1.0.
11.1 Reference
11.1.4
89
context_name (context)
The name of the context, limited to 128 alphanumeric characters, hyphens or underscores.
This is only used for XML Configuration Files.
Scope:
context
Type:
string
When
Set:
Version:
11.1.5
to
Can only be set during object initialization.
This option was implemented in LBM 4.3/UME 3.3/UMQ 2.3.
datagram_acceleration_functions (context)
Specifies the callback functions that implement Datagram Acceleration.
Refer to the description of lbm_datagram_acceleration_func_t for the callback definitions.
11.1.6
Scope:
context
Type:
lbm_datagram_acceleration_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
default_interface (context)
Specifies the network interface to be used as the default setting for all other interface configuration options.
90
Major Options
You can specify the full IP address of an interface, or just the network part (see Specifying Interfaces for details).
Default is set to INADDR_ANY, meaning that it will not bind to a specific interface.
11.1.7
Scope:
context
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
fd_management_type (context)
Define the mechanism UM uses for socket file descriptor (FD) management.
For more information, search on "file descriptors" in the Informatica Knowledge Base.
Scope:
context
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"poll"
LBM_CTX_ATTR_FDTYPE_POLL
FD management uses poll(). Unix only.
"select"
LBM_CTX_ATTR_FDTYPE_SELECT
"epoll"
LBM_CTX_ATTR_FDTYPE_EPOLL
FD management uses select(). Unix only.
Default for Unix.
FD management uses epoll(). Linux kernel 2.6 or later only.
"devpoll"
LBM_CTX_ATTR_FDTYPE_DEVPOLL
FD management uses the /dev/poll driver.
Solaris 8 or later only.
"kqueue"
LBM_CTX_ATTR_FDTYPE_KQUEUE
FD management uses the BSD kqueue
notification system. Mac OS X only.
"wsaeventselect"
LBM_CTX_ATTR_FDTYPE_WSAEV
FD management uses WSAEventSelect()
and WaitForMultipleObjects(), which imposes a limit of 64 file descriptors. Windows only.
"wincompport"
LBM_CTX_ATTR_FDTYPE_WINCPORT
FD management uses Windows completion ports and completion routines. Avoids
the 64 file descriptor limit set by WSA←EventSelect(). Windows XP or later only.
Default for Windows.
11.1 Reference
11.1.8
91
message_selector (receiver)
Enables UM to pass a message selector string to any receiver.
The value must be an expression that conforms to JMS message selector syntax as defined in the Oracle JMS
specification.
11.1.9
Scope:
receiver
Type:
string
Default
value:
When
Set:
Version:
NULL
to
Can only be set during object initialization.
This option was implemented in UMQ 5.3.
multiple_receive_maximum_datagrams (context)
The number of datagrams requested to be read per call to recvmmsg().
Values greater than 1 improve efficiency and reduce latency. Value of 0 means do NOT use recvmmsg(). Only
supported for UDP reception: LBT-RM, LBT-RU, MIM, and multicast topic resolution. Only available for Linux
2.6.32 and later. Requires glibc 2.12 or later. This option is ignored for non-Linux platforms.
Scope:
context
Type:
lbm_uint32_t
Units:
datagrams
Default
value:
When
Set:
Version:
0
to
Can only be set during object initialization.
This option was implemented in UM 6.8
92
Major Options
11.1.10
operational_mode (context)
The mode in which UM's context thread operates to process events.
See Embedded Mode and Sequential Mode for more information.
Scope:
context
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"embedded"
LBM_CTX_ATTR_OP_EMBEDDED
"sequential"
LBM_CTX_ATTR_OP_SEQUENTIAL
A thread is spawned within UM to handle processing of events (timers and socket events). Default
for all.
The application is responsible for calling lbm←_context_process_events() to process events.
Sequential mode does not support Multi-Transport
Threads.
11.1.11
operational_mode (xsp)
The mode in which UM operates to process events.
Refer to Embedded Mode for additional information.
Scope:
xsp
Type:
int
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"embedded"
LBM_CTX_ATTR_OP_EMBEDDED
A thread is spawned within UM to handle processing of events (timers and socket events). Default
for all.
11.1 Reference
93
String value
Integer value
Description
"sequential"
LBM_CTX_ATTR_OP_SEQUENTIAL
The application is responsible for calling lbm_←xsp_process_events() to process events.
11.1.12
ordered_delivery (receiver)
Indicates whether or not the topic should have its data delivered in order and reassembled.
For LBT-RM, LBT-RU, TCP-LB or LBT-IPC transport sessions only. (This option also applies to TCP when using
Late Join because the Late Join messages are not part of the TCP message stream.)
Changing this option from the default value to a value of 0 (zero) results in messages being delivered as soon
as they fully arrive. Value -1 allows arrival order delivery after the reassembly of large messages.
Note that ordering only applies to a specific topic from a single publisher. UM does not ensure ordering across
topics, or on a single topic across different publishers.
See Message Ordering and Message Fragmentation and Reassembly for more information.
Scope:
receiver
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"1"
1
UM delivers topic messages to a receiver in-order and reassembles large
messages. Default for all.
"0"
0
UM delivers topic messages to a receiver as they arrive and may be out of
order. Duplicate delivery is possible. UM delivers large messages as individual fragments of less than the maximum datagram size for the transport
in use.
"-1"
-1
UM delivers topic messages to a receiver as they arrive and may be out
of order. Duplicate delivery is possible. However, UM reassembles large
messages. Your application can use the sequence_number field of
lbm_msg_t objects to order or discard messages.
94
Major Options
11.1.13
receiver_callback_service_time_enabled (context)
Indicates if UM collects receiver callback statistics, which provide the maximum, mean and minimum time in
microseconds required to complete wildcard, hot-failover, and regular receiver callbacks.
Enabling this function slightly decreases the efficiency of the receive code path, but provides operators with
greater visibility of application behavior.
11.1.14
Scope:
context
Type:
int
Default
value:
When
Set:
Version:
0
to
Can only be set during object initialization.
This option was implemented in UM 6.5
Value
Description
1
UM collects receiver callback statistics.
0
UM does NOT collects receiver callback statistics. Default for all.
resolver_source_notification_function (context)
Application callback function (and associated client data pointer) that is called when a new source is discovered
for any topic, even if the application does not have a matching receiver.
Contrast this with source_notification_function (receiver).
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.
11.1 Reference
11.1.15
95
Scope:
context
Type:
lbm_src_notify_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
source_event_function (context)
Callback function (and associated client data pointer) that is called when a context source event (such as a
multicast immediate mode source wakeup event) occurs.
This callback may be called inline or from an event queue, if one is given. If called inline, the callback function
used should not block or it will block the context thread processing.
11.1.16
Scope:
context
Type:
lbm_context_src_event_func_t
Default
value:
When
to
Set:
Config File:
NULL
Version:
This option was implemented in LBM 3.4/UME 2.1.
Can only be set during object initialization.
Cannot be set from an UM configuration file.
source_includes_topic_index (context)
Determines whether the topic index is included in the source string generated for messages and new source
notifications.
Users should not disable this.
Scope:
context
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0.
96
Major Options
11.1.17
Value
Description
1
Indicates the topic index should be included in the source string. Default for all.
0
Indicates the topic index should not be included.
transport (source)
The transport type to be used for created sources.
Note
With Smart Sources, only LBT-RM and LBT-RU are supported.
Note
With Transport Services Provider (XSP), only LBT-RM, LBT-RU, and TCP are supported.
Scope:
source
Type:
int
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"tcp"
LBM_SRC_TOPIC_ATTR_TRANSP←ORT_TCP
LBM_SRC_TOPIC_ATTR_TRANSP←ORT_LBTRM
LBM_SRC_TOPIC_ATTR_TRANSP←ORT_LBTRU
LBM_SRC_TOPIC_ATTR_TRANSP←ORT_LBTIPC
TCP over IPv4. Default for all.
"lbtrm", "lbt-rm"
"lbtru", "lbt-ru"
"lbtipc", "lbt-ipc"
UDP-based reliable multicast with unicast NAKs.
UDP-based reliable unicast with unicast
NAKs.
Inter-Process Communication between
processes on the same host using a
shared memory area.
11.1 Reference
97
String value
Integer value
Description
"lbtsmx", "lbt-smx"
LBM_SRC_TOPIC_ATTR_TRANSP←ORT_LBTSMX
Shared Memory Acceleration. Ultralow-latency Inter-Process Communication transport between processes on the
same host using a shared memory area.
Restrictions apply.
"broker"
LBM_SRC_TOPIC_ATTR_TRANSP←ORT_BROKER
Sources send messages to a broker,
which manages the messages for consumption.
"lbtrdma", "lbt-rdma"
LBM_SRC_TOPIC_ATTR_TRANSP←ORT_LBTRDMA
InfiniBand Remote Direct Memory Access transport. Deprecated in UM 6.9.
11.1.18
transport_demux_tablesz (receiver)
Specifies the size of the table used for storing receiver delivery controllers used by UM for message delivery.
Must be a power of two (1, 2, 4, 8, 16, etc.). If not a power of two, UM generates a log warning and uses the
next highest power of two. For most use cases with low to moderate numbers of topics per transport session,
the default suffices. For large numbers of topics and in cases where the lowest latency is desired, set the option
to the next highest power of two for the number of topics expected on the transport session.
11.1.19
Scope:
receiver
Type:
size_t
Default
value:
When
Set:
Version:
1
to
Can only be set during object initialization.
This option was implemented in LBM 4.2/UME 3.2.
transport_mapping_function (context)
Application callback function (and associated client data pointer) that is called when a context is about to join a
new transport session.
This callback provides an opportunity for the user to map the transport session in question to an XSP.
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.
98
Major Options
11.1.20
Scope:
context
Type:
lbm_transport_mapping_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
transport_session_multiple_sending_threads (context)
Flag that indicates the application intends to use multiple sending threads per transport session.
Disabling this flag can improve send efficiency but renders the send functions thread-unsafe.
For the most-efficient sending method, see Smart Sources.
Scope:
context
Type:
int
When
Set:
to
Can only be set during object initialization.
Value
Description
1
Indicates the application does intend to use multiple sending threads per transport session and
that UM should make that assumption. Default for all.
0
Indicates the application does not intend to use multiple sending threads per transport session and
that UM should make that assumption.
11.1.21
transport_session_single_receiving_thread (context)
Flag that indicates the application intends to use only a single thread for receiving.
11.1 Reference
99
This improves message reception latency and outliers by converting certain thread-safe operations to moreefficient thread-unsafe operations. For example, certain bus-locked operations (e.g. atomic increment) are
replaced by non-bus-locked equivalents (e.g. non-atomic increment).
See Single Receiving Thread for more information and restrictions.
Scope:
context
Type:
int
When
Set:
to
Can only be set during object initialization.
Value
Description
1
The user intends to ensure that only one thread is used to process LBM transport messages.
0
No assumptions will be made by LBM regarding threading. Default for all.
11.1.22
transport_source_side_filtering_behavior (source)
Enable and set the behavior for UM sources to filter out topics prior to sending to clients.
This option is not applicable for multicast-based sources (LBT-RM). These control messages are sent to the
TCP UIM port (also known as the "request port") of the senders context and processed internally.
This option affects the transport session underlying the source rather than the source itself. See Source Object
for additional information.
Scope:
source
int
Type:
When
Set:
to
Can only be set during object initialization.
100
Major Options
String value
Integer value
Description
"none"
LBM_SRC_TOPIC_ATTR_SSF_NONE
"inclusion"
LBM_SRC_TOPIC_ATTR_SSF_INCLUSI←ON
The source sends all data to all clients regardless of the topics they are listening to.
Default for all.
The source sends only that data to a client
that the client specifically requests.
"ulb"
LBM_SRC_TOPIC_ATTR_SSF_ULB
11.1.23
The ULB source sends control and data only
to the ULB client that the source has specifically assigned for a given message. See
ULB Performance for more information.
transport_topic_sequence_number_info_active_threshold (source)
Duration in seconds that an inactive source sends contiguous Topic Sequence Number Info (TSNI) messages.
A value of 0 indicates that sources continue sending TSNIs until data messages resume, with no timeout.
TSNIs are sent at an interval defined by transport_topic_sequence_number_info_interval (source).
See also Interrelated Configuration Options.
11.1.24
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
60
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
transport_topic_sequence_number_info_interval (source)
The interval between Topic Sequence Number Info (TSNI) messages that a source sends.
TSNI messages are enabled on all transports except LBT-SMX, and they carry the topic sequence number of
the latest message sent by the source. The interval is also a source inactivity threshold. In other words, a
11.1 Reference
101
source does not send TSNIs during normal data transmission, but once the source is inactive for as long as
this interval, it starts sending TSNI messages. A value of 0 turns off TSNI messages for the source.
See also Interrelated Configuration Options.
11.1.25
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
5000 (5 second)
to
Can only be set during object initialization.
This option was implemented in LBM 3.3
transport_topic_sequence_number_info_request_interval (receiver)
The interval at which the receiver requests a Topic Sequence Number Information Record (TSNI) from the
source.
Controlling these requests helps reduce receiver start-up traffic on your network.
11.1.26
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
transport_topic_sequence_number_info_request_maximum (receiver)
The maximum number of requests the receiver issues for a Topic Sequence Number Information Record (TSNI)
from the source.
If the receiver has not received an TSNI after this number of requests, it stops requesting.
102
Major Options
11.1.27
Scope:
receiver
Type:
lbm_ulong_t
Default
value:
When
Set:
Version:
60
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
use_extended_reclaim_notifications (source)
Specifies which reclaim notification your application receives.
The expanded notification, LBM_SRC_EVENT_UME_MESSAGE_RECLAIMED_EX, contains a flag, LBM_S←RC_EVENT_UME_MESSAGE_RECLAIMED_EX_FLAG_FORCED that UME sets if the reclamation is a forced
reclaim.
Scope:
source
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.2.
Value
Description
1
Indicates your application receives the expanded reclaim notification. Default for all.
0
Indicates your application receives the standard reclaim notification that is identical to the expanded
notification but without the "Forced" flag.
11.1.28
zero_transports_function (xsp)
Application callback function (and associated client data pointer) that is called when the number of transports
associated with a given XSP falls to zero.
11.1 Reference
103
This callback provides an opportunity to delete the given XSP.
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:
xsp
Type:
lbm_xsp_zero_transports_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
104
Major Options
Chapter 12
UDP-Based Resolver Operation Options
This section describes configuration options for UDP-based TR. The options generally apply equally to both Multicast UDP and Unicast UDP Topic Resolution. See Topic Resolution Overview for more information.
The following topic resolution options have been deprecated in LBM Version 4.0.
• resolver_active_source_interval (context)
• resolver_active_threshold (context)
• resolver_maximum_advertisements (context)
• resolver_maximum_queries (context)
• resolver_query_interval (context)
See Re-establish Pre-4.0 Topic Resolution for option values that configure the topic resolution used in LBM Version
3.6 and prior versions. You should also comment out or remove from your Ultra Messaging Configuration file the
deprecated configuration options shown above.
12.1
Minimum Values for Advertisement and Query Intervals
These intervals have the following effective minimal values.
• 10 ms for Initial Phase Advertisements
• 20 ms for Initial Phase Queries
• 30 ms Wildcard Queries
• 100 ms for Sustaining Phase Advertisements and Queries
• 100 ms for Context Name Queries (mostly for persistence)
These effective minimums exist because the internal timer that schedules advertisements and queries fires at the
stated interval, i.e., every 10 ms for Initial Phase Advertisements, every 20 ms for Initial Phase Queries, etc. If you
set the option's value below the minimum, after the initial advertisement or query at 0 ms, the resolver schedules
the second advertisement or query at the first timer "tick", which is the minimum.
Subsequent advertisements or queries can only be issued at the next timer "tick". If you increase this option from
the default to a value that is not a multiple of the minimum, the resolver maintains the rate you establish as an
average over subsequent "ticks".
106
UDP-Based Resolver Operation Options
As an example, if you set resolver_advertisement_sustain_interval (source) or resolver_query_sustain_interval (receiver) to 10 ms, the resolver schedules the second advertisement or query after the initial (0 ms) at the first timer
"tick", which is 100 ms. Subsequent advertisements or queries can only be issued at the next timer "tick" (every 100
ms). If you increase either option from the default to 1.25 seconds, for example and not a multiple of 100 ms, the
resolver maintains the rate you establish as an average over subsequent "ticks". That is, the second advertisement
or query goes out at the 1300 ms "tick". The resolver tracks the tardiness of this advertisement (50 ms) and adjusts
the next advertisement or query, which goes out at 2500 ms, giving an average of 1250 ms or 1.25 seconds.
12.2
Reference
12.2.1
disable_extended_topic_resolution_message_options (context)
This is a topic resolution compatibility option that, when set to 1, lets LBM 4.0 (or later) installations work with
LBM 3.5.3 / UME 2.2.4 (or earlier) installations.
If you do not have early-version installations in the network, leave this option at 0.
Scope:
context
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.0.
Value
Description
1
Enable compatibility with earlier-version installations (and disable some message structure features).
0
Normal current-version compatibility. Strongly recommended. Default for all.
12.2.2
resolution_no_source_notification_threshold (receiver)
The threshold for the number of unanswered topic resolution queries before UM delivers a LBM_MSG_NO_←SOURCE_NOTIFICATION for the topic.
12.2 Reference
107
The receiver does not stop querying after the delivery of this notification. A value of 0 indicates no notifications
will be sent.
12.2.3
Scope:
receiver
Type:
lbm_ulong_t
Units:
Number of queries
Default
value:
When
Set:
0 (do not notify)
to
May be set during operation.
resolution_number_of_sources_query_threshold (receiver)
The threshold for the number of sources a topic must have before topic resolution queries are not sent.
A value of zero results in no topic resolution queries being generated. See also Disabling Aspects of Topic
Resolution.
12.2.4
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Number of sources
10000000 (10 million)
to
May be set during operation.
resolver_advertisement_maximum_initial_interval (source)
The longest - and last - interval in the initial phase of topic advertisement.
A value of 0 disables the initial phase of advertisement. See also Disabling Aspects of Topic Resolution.
Scope:
source
Type:
lbm_ulong_t
Units:
milliseconds
108
UDP-Based Resolver Operation Options
Default
value:
When
Set:
Version:
12.2.5
500 (0.5 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_advertisement_minimum_initial_duration (source)
The duration of the initial phase of topic advertisement.
A value of 0 guarantees that the initial phase of advertisement never completes.
12.2.6
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
5000 (5 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_advertisement_minimum_initial_interval (source)
Interval between the first topic advertisement sent upon creation of the source and the second advertisement
sent by the source.
A value of 0 disables the initial phase of advertisement. This option has an effective minimum of 10 ms. See
UDP-Based Resolver Operation Options.
See also Disabling Aspects of Topic Resolution.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
milliseconds
10 (0.01 seconds)
12.2 Reference
109
When
Set:
Version:
12.2.7
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_advertisement_minimum_sustain_duration (source)
The duration of the sustaining phase of topic advertisement.
A value of 0 guarantees that the sustaining phase of advertising never completes.
12.2.8
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
60 (1 minute)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_advertisement_send_immediate_response (source)
Allows you to disable the normal immediate response to queries and wildcard queries.
Sources normally send topic advertisements (TIR) immediately in response to topic queries (TQR) for a local
topic or wildcard queries (WC-TQR) with a pattern that matches a local topic. This helps to resolve topics
quickly. However, these immediate TIRs are also inefficient; each TIR is sent in a UDP datagram of its own.
In contrast, TIRs sent using the normal, rate-limited phases of advertisement are batched, with multiple TI←Rs collected into a single UDP datagram. For systems with large numbers of sources and receivers, allowing
immediate response to queries can lead to high short-term network loading and packet loss. In these cases,
it can be beneficial to disable immediate responses, at the expense of longer times required to resolve new
receivers.
Scope:
source
Type:
lbm_uint_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.2/UME 3.2/UMQ 2.1
110
UDP-Based Resolver Operation Options
Value
Description
1
Sources immediately send advertisements (TIR) in response to topic queries (TQR) or wildcard
queries (WC-TQR). Default for all.
0
Sources delay sending advertisements (TIR) in response to topic queries (TQR) or wildcard queries
(WC-TQR).
12.2.9
resolver_advertisement_sustain_interval (source)
Interval between sending topic advertisements in the sustaining phase of topic advertisement.
A value of 0 disables the sustaining phase of advertisement. This option has an effective minimum of 100 ms.
See UDP-Based Resolver Operation Options.
See also Disabling Aspects of Topic Resolution.
12.2.10
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_cache (context)
Whether or not to enable the resolver cache to hold topic resolution information. Disabling the resolver cache
uses less memory, but can increase network load. Informatica recommends against disabling the resolver
cache.
12.2 Reference
111
Warning
The resolver cache must be enabled if wildcard receivers and/or if resolver_service (context) is used.
Scope:
context
Type:
int
When
Set:
12.2.11
to
Can only be set during object initialization.
Value
Description
1
Topic resolution information will be cached. Default for all.
0
Do not cache topic resolution information.
resolver_context_name_activity_timeout (context)
Period of inactivity before a context name is declared unresolved.
The minimum amount of time without any context name resolution traffic that must pass before UM declares a
resolved context name unresolved. Context name resolution traffic is defined as the reception of context name
advertisements and/or unicast control traffic from the resolved context.
12.2.12
Scope:
context
Type:
lbm_uint64_t
Units:
Default
value:
When
Set:
Version:
milliseconds
60000 (60 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 6.0
resolver_context_name_query_duration (context)
Maximum period of time UM sends context name queries.
112
UDP-Based Resolver Operation Options
The maximum duration for which UM sends context name queries for a given context name. UM sends queries
until the context name resolves. A value of 0 means queries have no time limit and UM continues to query until
the context name resolves.
12.2.13
Scope:
context
Type:
lbm_uint64_t
Units:
Default
value:
When
Set:
Version:
milliseconds
0 (query for as long as unresolved)
to
Can only be set during object initialization.
This option was implemented in UM 6.0
resolver_context_name_query_maximum_interval (context)
The longest interval between sending context name queries.
A value of 0 disables context name queries.
This option has an effective minimum of 100 ms. See UDP-Based Resolver Operation Options.
See also Disabling Aspects of Topic Resolution.
12.2.14
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in UM 6.0
resolver_context_name_query_minimum_interval (context)
Interval between the first context name query sent upon creation of the UMP source using named stores and
the second query sent.
12.2 Reference
113
A value of 0 disables context name queries. This option has an effective minimum of 100 ms. See UDP-Based
Resolver Operation Options.
See also Disabling Aspects of Topic Resolution.
12.2.15
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
100 (0.1 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 6.0
resolver_datagram_max_size (context)
The maximum UDP datagram payload size that can be generated for topic resolution advertisements and
queries. Note that this does not include UDP, IP, or packet overhead added by the network stack. The default
value is 8192, the minimum is 500 bytes, and the maximum is 65535.
See Message Fragmentation and Reassembly for more information.
Informatica does not recommend setting datagram max size options to the network MTU. See Datagram Max
Size and Network MTU.
Warning
When the DRO is in use, it is recommended that all UM applications and components (including the DRO and
Persistent Store) share the same maximum datagram size setting. See Protocol Conversion.
Scope:
context
Type:
lbm_uint_t
Units:
bytes
Default
value:
When
Set:
Version:
8192
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0.
114
UDP-Based Resolver Operation Options
12.2.16
resolver_domain_id_active_propagation_timeout (context)
Indicates how a context learns the ID of its own Topic Resolution Domain (TRD).
See Topic Resolution Domain.
Scope:
context
Type:
int
Default
value:
When
Set:
Version:
0
to
Can only be set during object initialization.
This option was implemented in UM 6.7.1
String value
Integer value
Description
"-1"
-1
Learn TRD ID from other contexts in the same TRD, without
restriction. This is the method Ultra Messaging has traditionally used.
This method assigns TRD IDs quickly to avoid partial connectivity. However, note that to change a TRD ID, you must reconfigure and restart all UM Routers, if present. Then you must
delete all application contexts, and then re-create all application contexts.
Note: With this option value, newly-created contexts can learn
from earlier versions of Ultra Messaging software.
"0"
0
Learn TRD ID only from a UM Router directly. Do not learn the
TRD ID from other contexts in the same TRD. Consider using
this option with a TRD that has many contexts and a possible
need to change a TRD ID. Default for all.
12.2 Reference
115
String value
Integer value
Description
"1" to "2147483647"
1 to 2,147,483,647
Learn TRD ID from other contexts in the same TRD that have
heard the domain ID advertised by a UM Router within this
timeout value in seconds. Use the following formula:
3 ∗ {propagation-interval}/1000 + {maximum expected duration of UM Router outage}
where propagation-interval is an attribute value of the UM
Router configuration option "" element, which defaults to 1000. With a timeout value set, a restarted context
does not learn obsolete TRD IDs from un-restarted contexts,
but instead, learns from UM Routers or restarted contexts. You
do not need to bring all contexts to a deleted state simultaneously before you re-create the first context.
Note: During this timeout period, there is a risk for temporary
incomplete connectivity in networks with no UM Routers.
12.2.17
resolver_initial_advertisement_bps (context)
Maximum advertisement rate during the initial phase of topic advertisement.
A value of 0 means that initial phase advertisements for the topic are not limited to a maximum number of bits
per second. Note that the topic's advertisements are still subject to being rate limited by resolver_initial_←advertisements_per_second (context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
Version:
1000000
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
116
UDP-Based Resolver Operation Options
12.2.18
resolver_initial_advertisements_per_second (context)
Maximum number of advertisements sent within a one second period during the initial phase of topic advertisement.
A value of 0 means that initial phase advertisements for the topic are not limited to a maximum number of advertisements per second. Note that the topic's advertisements are still subject to being rate limited by resolver←_initial_advertisement_bps (context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
12.2.19
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
advertisements
1000
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_initial_queries_per_second (context)
Maximum number of queries sent within a one second period during the initial phase of topic querying.
A value of 0 means that initial phase queries for the topic are not limited to a maximum number of queries
per second. Note that the topic's queries are still subject to being rate limited by resolver_initial_query_bps
(context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
advertisements
1000
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
12.2 Reference
12.2.20
117
resolver_initial_query_bps (context)
Maximum query rate during the initial phase of topic querying.
A value of 0 means that initial phase queries for the topic are not limited to a maximum number of bits per
second. Note that the topic's queries are still subject to being rate limited by resolver_initial_queries_per_←second (context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
12.2.21
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
Version:
1000000
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_query_maximum_initial_interval (receiver)
The longest - and last - interval in the initial phase of topic querying.
A value of 0 disables the initial phase of querying.
See also Disabling Aspects of Topic Resolution.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
118
UDP-Based Resolver Operation Options
12.2.22
resolver_query_minimum_initial_duration (receiver)
The duration of the initial phase of topic querying.
A value of 0 guarantees that the initial phase of querying never completes.
12.2.23
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
5000 (5 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_query_minimum_initial_interval (receiver)
Interval between the first topic query sent upon creation of the receiver and the second query sent by the
receiver.
A value of 0 disables the initial phase of querying. This option has an effective minimum of 20 ms. See
UDP-Based Resolver Operation Options.
See also Disabling Aspects of Topic Resolution.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
20 (0.02 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
12.2 Reference
12.2.24
119
resolver_query_minimum_sustain_duration (receiver)
The duration of the sustaining phase of topic querying.
A value of 0 guarantees that the sustaining phase of querying never completes.
12.2.25
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
60 (1 minute)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_query_sustain_interval (receiver)
Interval between sending topic queries in the sustaining phase of topic querying.
A value of 0 disables the sustaining phase of querying. This option has an effective minimum of 100 ms. See
UDP-Based Resolver Operation Options.
See also Disabling Aspects of Topic Resolution.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
120
UDP-Based Resolver Operation Options
12.2.26
resolver_receiver_map_tablesz (context)
The size of the hash table used for storing receiver topic information used for topic resolution. This value should
be a prime number.
For UM deployments with very large numbers of topics (more than 100,000), increasing this number can improve efficiency.
12.2.27
Scope:
context
Type:
size_t
Units:
map entries
Default
value:
When
Set:
131111
to
Can only be set during object initialization.
resolver_send_final_advertisements (source)
Controls whether or not a source sends "final advertisements" before deletion.
A final advertisement is an announcement that the source object is being deleted. Without final advertisements,
receivers are not informed that a source has been deleted until all sources on a transport session are deleted
and the transport session is disposed. At that point, any receivers to sources on that transport session will
simultaneously be delivered an EOS event.
However, if the source has final advertisements enabled, the source will send the final advertisement and trigger
the delivery of the EOS event in a more-timely way. They also give other contexts an opportunity to purge the
source from their local topic resolution cache.
Note: the final advertisements are not necessarily sent immediately upon deletion of the source. They are
scheduled with other topic resolution traffic and obey the rate limits. As a result, if an application is in the
process of cleaning up prior to exit and it deletes the context object too soon after the deletion of its sources,
the final advertisements may not be sent at all. Typically this will simply result in a less-timely notification of
EOS as transport sessions time out, but there are some circumstances where the time required to deliver EOS
is not technically bounded. If timely delivery of EOS is important, it is recommended to add a few seconds of
delay after the sources are deleted before deleting the context.
This setting does not affect the topic resolution phases you have configured, which execute as expected. See
Disabling Aspects of Topic Resolution.
12.2 Reference
121
Scope:
source
lbm_uint_t
Type:
When
Set:
Version:
12.2.28
to
Can only be set during object initialization.
This option was implemented in LBM 6.10
Value
Description
1
Source sends final advertisements before deletion.
0
Source does not send any final advertisements before deletion. Default for all.
resolver_send_initial_advertisement (source)
Controls whether or not a source sends an advertisement upon creation.
Turning off this advertisement speeds source creation and reduces the number of messages on your network
through application initialization.
See Disabling Aspects of Topic Resolution.
Scope:
source
Type:
lbm_uint_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
Value
Description
1
Source sends a topic advertisement immediately upon creation. Default for all.
0
Source does not send an advertisement upon creation. This setting does not affect the topic
resolution phases you have configured, which execute as expected.
122
UDP-Based Resolver Operation Options
12.2.29
resolver_service (context)
Enable TCP-based TR and add one or more Stateful Resolver Service (SRS) specifications to the current SRS
list. Unlike most other UM settings, every time this setting is called, it adds one or more service specifications
to the list, and does NOT overwrite previous specifications.
Setting this option does not affect whether UDP-based TR is enabled or disabled. See TCP-Based Topic
Resolution Details.
Warning
For UM version 6.12, only the last SRS specified is used; previous SRS specifications are silently ignored.
Users should supply a single SRS specification.
Warning
Do not turn off the resolver cache when TCP-based TR is used. See resolver_cache (context).
For the configuration file as well as string API method of setting this option, the string value consists of one or
more SRS specifications separated by commas or semicolons, formatted as follows:
[Iface[:Src_Port]->]IP:Dest_Port[,...]
• Iface is the interface to use.
• Src_Port is the source port to use. Normally only specified if firewalls require specific source ports be
used.
• IP is the SRS's IP address.
• Dest_Port is the SRS's TCP listening port.
You can omit either the Src_Port or both the Iface and Src_Port, in which case the interface defaults
to default_interface (context), if specified, and the port defaults to 0, which allocates an ephemeral port.
Because each entry adds a new SRS specification and does not overwrite previous values, a special construct
must be used to clear a previously-specified list. An entry with the IP address of 0.0.0.0 and port of 0 removes
all previous SRS specifications. This can be useful if multiple configuration files are used, and a later file should
override the SRS list from an earlier file.
Possible formats of each entry are as follows:
12.2 Reference
123
Interface:LocalPort->SrsIP:RemotePort
Interface->SrsIP:RemotePort
SrsIP:RemotePort
You can specify Interface in any of the ways described in Specifying Interfaces.
When the binary form of option setting is used, UM does NOT expect an array of structures. Instead, only
one SRS specification can be supplied for each call to lbm_context_attr_setopt(). However, when the binary
form of option retrieval lbm_context_attr_getopt() is used, the list of SRSes is returned as an array, and the
optlen parameter should be set as:
optlen = (max_num_srs * sizeof(lbm_resolver_service_entry_t));
Scope:
context
lbm_resolver_service_entry_t
Type:
When
Set:
Version:
12.2.30
to
Can only be set during object initialization.
This option was implemented in UMQ 6.12
resolver_source_map_tablesz (context)
The size of the hash table used for storing source topic information used by topic resolution. This value should
be a prime number.
For UM deployments with very large numbers of topics (more than 100,000), increasing this number can improve efficiency.
Scope:
context
Type:
size_t
Units:
map entries
Default
value:
When
Set:
131111
to
Can only be set during object initialization.
124
UDP-Based Resolver Operation Options
12.2.31
resolver_string_hash_function (context)
The hash function to use for hashing topic name strings for source and receiver topics.
The application may choose from a list of defined hash functions or it may define its own hash function, as
identified by the string value of this option. When setting a hash function, note that:
• If set through a configuration file or a call to lbm_context_attr_str_setopt(), only the string values classic,
djb2, sdbm, or murmur2 are valid. (If retrieved by a call to lbm_context_attr_str_getopt(), one of these
string values is returned.)
• If set through a call to lbm_context_attr_setopt(), you must pass a pointer to a hash function. Use this
method for hash functions other than the four pre-defined functions.
Informatica's own testing has indicated that the default (murmur2) outperforms all the others, but there may be
topic string formats for which a different function is better. Informatica suggests careful testing before changing
the hash function.
Scope:
context
Type:
lbm_str_hash_func_t
Default
value:
When
Set:
NULL
to
Can only be set during object initialization.
String value
Integer value
Description
"classic"
n.a.
A "classic" good string hash function. Works best when topic names have
a constant prefix with a changing suffix.
"djb2"
n.a.
The Dan Bernstein algorithm from comp.lang.c. Works best when topic
names have a changing prefix with a constant suffix.
"sdbm"
n.a.
sdbm database library (used in Berkeley DB). A useful alternative to djb2.
"murmur2"
n.a.
Good all-around hash function by Austin Appleby. Best for medium to long
topic strings. Default for all.
12.2.32
resolver_string_hash_function_ex (context)
The hash function to use for hashing topic name strings for source and receiver topics.
12.2 Reference
125
This option is similar to the resolver_string_hash_function (context) except for the following differences: This
option can be set via only lbm_context_attr_setopt() (not from a configuration file or lbm_context_attr_str←_setopt()). Hence, this also means you cannot use the string options (classic, etc.). You can pass a string
length to the hash function, allowing it to then possibly run faster by operating on multiple-character strings at
a time. Note that if -1 is passed in, you must use a strlen to calculate the length. The hash function accepts a
clientd pointer, which you can set as needed, and which is passed back in each time the function is called.
This option is the better choice when setting your own custom hash function. Note that both the resolver_←string_hash_function and resolver_string_hash_function_ex options set the same attributes, hence, if you use
both (not recommended) one will override the other.
12.2.33
Scope:
context
Type:
lbm_str_hash_func_ex_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
resolver_sustain_advertisement_bps (context)
Maximum advertisement rate during the sustaining phase of topic advertisement.
A value of 0 means that sustaining phase advertisements for the topic are not limited to a maximum number of
bits per second. Note that the topic's advertisements are still subject to being rate limited by resolver_sustain←_advertisements_per_second (context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
Version:
1000000
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
126
UDP-Based Resolver Operation Options
12.2.34
resolver_sustain_advertisements_per_second (context)
Maximum number of advertisements sent within a one second period during the sustaining phase of topic
advertisement.
A value of 0 means that sustaining phase advertisements for the topic are not limited to a maximum number
of advertisements per second. Note that the topic's advertisements are still subject to being rate limited by
resolver_sustain_advertisement_bps (context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
12.2.35
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
advertisements
0
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_sustain_queries_per_second (context)
Maximum number of queries sent within a one second period during the sustaining phase of topic querying.
A value of 0 means that sustaining phase queries for the topic are not limited to a maximum number of queries
per second. Note that the topic's queries are still subject to being rate limited by resolver_sustain_query_bps
(context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
advertisements
0
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
12.2 Reference
12.2.36
127
resolver_sustain_query_bps (context)
Maximum query rate during the sustaining phase of topic querying.
A value of 0 means that sustaining phase queries for the topic are not limited to a maximum number of bits per
second. Note that the topic's queries are still subject to being rate limited by resolver_sustain_queries_per_←second (context).
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
12.2.37
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
Version:
1000000
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_unicast_activity_timeout (context)
Indicates the maximum time between messages from a unicast resolver daemon before UM declares it inactive
and stops sending normal topic resolution traffic via that daemon.
UM will still send keepalives to the daemon. A value of 0 will force all resolver daemons to be treated as
permanently active.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000
to
Can only be set during object initialization.
This option was implemented in UMS 5.0
128
UDP-Based Resolver Operation Options
12.2.38
resolver_unicast_change_interval (context)
Indicates how often UM will change to the next available unicast resolver daemon.
The actual value used is random, and is selected from the range (1/2∗change_interval, 3/2∗change_interval). If
all resolver daemons have been marked inactive, UM enters a quick-change mode where it uses a random value
from the range (1/4∗change_interval, 3/4∗change_interval) in order to more quickly locate an active daemon.
See resolver_unicast_daemon (context) option.
12.2.39
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
200
to
Can only be set during object initialization.
This option was implemented in UMS 5.0
resolver_unicast_check_interval (context)
Indicates how often a UM checks for resolver activity in order to determine liveness.
A value of 0 will disable activity checks. This setting only applies to the unicast resolver.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
200
to
Can only be set during object initialization.
This option was implemented in UMS 5.0
12.2 Reference
12.2.40
129
resolver_unicast_force_alive (context)
Controls whether a context with no sources or receivers should register with and send keepalive messages to
a configured Unicast Topic Resolver.
By default, at least one source or receiver must exist in a context before it registers with a configured Unicast
Topic Resolver.
However, some receiving application designs use resolver_source_notification_function (context) to notify them
of discovered sources, and do not create a receiver until sources are discovered. If these designs use unicast
topic resolution, they should set this option to "1".
Scope:
context
lbm_uint16_t
Type:
When
Set:
to
Can only be set during object initialization.
Value
Description
1
Contexts send keepalive messages to the Unicast Resolver at the resolver_unicast_keepalive_←interval (context) regardless of whether the context has any sources or receivers that require topic
resolution.
0
Contexts do not send keepalive messages to the Unicast Resolver until sources or receivers have
been created. Then Contexts send keepalives at the resolver_unicast_keepalive_interval (context).
Default for all.
12.2.41
resolver_unicast_ignore_unknown_source (context)
Indicates whether contexts using unicast topic resolution accept topic resolution udp datagrams that originate
from any lbmrd or only the specific lbmrd configured for use.
Note: Do not modify this setting without guidance from Informatica.
Scope:
context
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UM 6.7.1
130
UDP-Based Resolver Operation Options
String value
Integer value
Description
"0"
0
A context using unicast topic resolution accepts traffic from lbmrd resolver
daemons not configured for use by the context.
"1"
1
Contexts using unicast topic resolution accept topic resolution udp datagrams that originate from only the specific lbmrd configured for use. The
context discards topic resolution datagrams from unrecognized origins and
logs a message. This prevents applications at the same IP address, but
in different topic resolution domains that might share resolver unicast port
ranges, from processing unintended topic resolution traffic while lbmrd resolver daemons time out stale client entries. Default for all.
12.2.42
resolver_unicast_keepalive_interval (context)
Indicates how often keepalive messages should be sent to a resolver daemon.
Keepalives are only sent if no other traffic has been sent since the last keepalive interval expired.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
500
to
Can only be set during object initialization.
This option was implemented in UMS 5.0
Chapter 13
Multicast Resolver Network Options
The image below shows a simplified relationship between the primary multicast resolver network options.
See Topic Resolution Overview for general information on Topic Resolution.
13.1
Reference
13.1.1
resolver_multicast_address (context)
Multicast address (or domain name of the multicast address) used for Topic Resolution.
This option automatically sets the values for resolver_multicast_incoming_address (context) and resolver_←multicast_outgoing_address (context) as evidenced by the default values for all three options, which are the
same.
132
Multicast Resolver Network Options
See also UDP-Based Topic Resolution Details.
13.1.2
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
224.9.10.11
to
Can only be set during object initialization.
resolver_multicast_incoming_address (context)
Incoming multicast address (or domain name of the multicast address) used for finer control of Topic Resolution.
This value may be set to 0.0.0.0 (INADDR_ANY), to switch off listening to topic resolution messages. This
means that queries from receivers or advertisements from sources will not be handled.
See also resolver_multicast_outgoing_address (context).
13.1.3
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
224.9.10.11
to
Can only be set during object initialization.
resolver_multicast_incoming_port (context)
Incoming multicast port used for finer control of Topic Resolution.
See also resolver_multicast_outgoing_port (context).
See Port Assignments for more information about configuring ports.
13.1 Reference
133
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
12965
When
Set:
13.1.4
Network
to
Can only be set during object initialization.
resolver_multicast_interface (context)
Specifies which network interface UM sends/receives all multicast traffic (Topic Resolution, LBT-RM, Multicast
Immediate Messaging).
Can specify full IP address of interface, or just network part (see Specifying Interfaces for details). Default is set
to default_interface (context), if specified. Otherwise, it is set to the default multicast interface as determined by
UM (the first multicast-capable, non-loopback interface).
13.1.5
Scope:
context
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0
to
Can only be set during object initialization.
resolver_multicast_outgoing_address (context)
Outgoing multicast address (or domain name of the multicast address) used for finer control of Topic Resolution.
See also resolver_multicast_incoming_address (context).
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
224.9.10.11
to
Can only be set during object initialization.
134
Multicast Resolver Network Options
13.1.6
resolver_multicast_outgoing_port (context)
Outgoing multicast port used for finer control of Topic Resolution.
See also resolver_multicast_incoming_port (context).
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
12965
When
Set:
13.1.7
Network
to
Can only be set during object initialization.
resolver_multicast_port (context)
Multicast port used for Topic Resolution.
This option automatically sets the values for resolver_multicast_incoming_port (context) and resolver_←multicast_outgoing_port (context) as evidenced by the default values for all three options, which are the same.
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
12965
When
Set:
Network
to
Can only be set during object initialization.
13.1 Reference
13.1.8
135
resolver_multicast_receiver_socket_buffer (context)
Value used to set SO_RCVBUF value of the resolver receivers.
In some cases the OS will not allow all of this value to be used. A value of 0 instructs UM to use the default OS
values. See Socket Buffer Sizes for platform-dependent information. See also our white paper Topics in High
Performance Messaging for background and guidelines on UDP buffer sizing.
13.1.9
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
8388608 (8MB)
to
Can only be set during object initialization.
resolver_multicast_ttl (context)
The IP TTL (hop count) to use for a Topic Resolution packet.
A value of 1 confines the packet to the local network (but may also cause high CPU usage on some routers).
Also controls TTL on LBT-RM packets.
Scope:
context
Type:
lbm_uint8_t
Default
value:
When
Set:
16
to
Can only be set during object initialization.
136
Multicast Resolver Network Options
Chapter 14
Unicast Resolver Network Options
The image below shows a simplified relationship between the primary unicast resolver network options.
If using multiple lbmrd instances with a single context, you can configure resolver_unicast_interface and
resolver_unicast_port_low/high and omit the Interface:LocalPort section of resolver_unicast_daemon.
See also Unicast Topic Resolution for general information on Unicast Topic Resolution.
138
Unicast Resolver Network Options
14.1
Reference
14.1.1
resolver_unicast_daemon (context)
Enable Unicast UDP-based TR and add one or more unicast resolver daemon (lbmrd) specifications to the
current lbmrd list. Unlike most other UM settings, every time this setting is called, it adds one or more daemon
specifications to the list, and does NOT overwrite previous specifications.
Setting this option Disables Multicast UDP-based TR, but does not affect whether TCP-based TR is enabled or
disabled. See UDP-Based Topic Resolution Details.
For the configuration file as well as string API method of setting this option, the string value consists of one or
more lbmrd specifications separated by commas or semicolons, formatted as follows:
[Iface[:Src_Port]->]IP:Dest_Port[,...]
• Iface is the interface to use (previously set via resolver_unicast_interface (context)).
• Src_Port is the source port to use (previously resolver_unicast_port (context)). Normally only specified
if firewalls require specific source ports be used.
• IP is the resolver daemon's IP address (previously resolver_unicast_address (context)).
• Dest_Port is the resolver daemon's UDP port (previously resolver_unicast_destination_port (context)).
You can omit either the Src_Port or both the Iface and Src_Port, in which case the default settings
resolver_unicast_interface (context) and resolver_unicast_port (context) are used.
Because each entry adds a new daemon specification and does not overwrite previous values, a special construct must be used to clear a previously-specified list. An entry with the IP address of 0.0.0.0 and port of 0
removes all previous daemon specifications. This can be useful if multiple configuration files are used, and a
later file should override the daemon list from an earlier file.
Possible formats of each entry are as follows:
Interface:LocalPort->DaemonIP:RemotePort
Interface->DaemonIP:RemotePort
DaemonIP:RemotePort
You can specify Interface in any of the ways described in Specifying Interfaces.
When the binary form of option setting is used, UM does NOT expect an array of structures. Instead, only
one lbmrd specification can be supplied for each call to lbm_context_attr_setopt(). However, when the binary
form of option retrieval lbm_context_attr_getopt() is used, the list of lbmrds is returned as an array, and the
optlen parameter should be set as:
optlen = (max_num_lbmrds * sizeof(lbm_ucast_resolver_entry_t));
14.1 Reference
139
Scope:
context
lbm_ucast_resolver_entry_t
Type:
When
Set:
Version:
14.1.2
to
Can only be set during object initialization.
This option was implemented in UMS 5.0
resolver_unicast_interface (context)
Specifies the network interface over which UM receives unicast Topic Resolution messages.
Can specify full IP address of interface, or just network part (see Specifying Interfaces for details). Default is
set to default_interface (context)>, if specified. Otherwise, it is set to INADDR_ANY, meaning that it will accept
unicast Topic Resolution messages on any interface.
14.1.3
Scope:
context
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
resolver_unicast_port_high (context)
The highest local UDP port in a range of ports used for unicast topic resolution messages.
The UM resolution daemon (lbmrd) sends unicast topic resolution messages to the UDP port range defined by
this option and resolver_unicast_port_low (context).
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14406
When
Set:
Host
to
Can only be set during object initialization.
140
Unicast Resolver Network Options
14.1.4
resolver_unicast_port_low (context)
The lowest local UDP port in a range of ports used for unicast topic resolution messages.
The UM resolution daemon (lbmrd) sends unicast topic resolution messages to the UDP port range defined by
this option and resolver_unicast_port_high (context).
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14402
When
Set:
14.1.5
Host
to
Can only be set during object initialization.
resolver_unicast_receiver_socket_buffer (context)
Value used to set SO_RCVBUF value of the UDP receivers for unicast topic resolution messages.
In some cases the OS will not allow all of this value to be used. A value of 0 instructs UM to use the default OS
values. See ref socketbuffersizes for platform-dependent information.
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
8388608 (8MB)
to
Can only be set during object initialization.
Chapter 15
Transport TCP Network Options
15.1
TCP Transport Session Management
The image below shows a simplified relationship between the primary TCP transport network options.
When a source is created, the application can explicitly map it to a transport session by setting the transport_tcp←_port (source) option. If a previous source was created on the same context with the same port number, this new
source will be mapped to the same transport session. However, two different contexts on the same host may not
share the same port number. If a source is created with a port number that is already in use, UM will return an error.
Alternatively, if the application does not explicitly specify a source port, UM will implicitly assign the new source to
a pool of transport sessions defined when the context was created. The pool is defined as a range of port numbers
specified by the options transport_tcp_port_low (context) and transport_tcp_port_high (context). In addition, the
option transport_tcp_maximum_ports (context) defines the number of transport sessions in the pool.
When a new source is created and the source port is not explicitly defined, UM will check to see how many transport
sessions are currently active from the pool within the context. If it is less than transport_tcp_maximum_ports
(context) then UM will attempt to use the next port in the range transport_tcp_port_low (context) to transport_←tcp_port_high (context). If that port is already in use, UM continues along the range until it finds an unused port,
142
Transport TCP Network Options
then it uses that port to create the transport session. However, if the context already has activated all transport
sessions in the pool, then the new topic is mapped to one of the existing transport sessions, in round-robin fashion.
Notice that the default range of ports, 14371 to 14390, is 30 ports. But the default number of transport sessions
in the pool is 10. This allows three contexts to be created on the same host and use the same configuration. If
more than 3 contexts are intended to co-exist on the same host, the port range and number of transport session per
context must be managed to give a unique port number to every transport session.
The option transport_tcp_interface (source) may be used on TCP sources to choose particular interface, overriding
the default INADDR_ANY which accepts connections on all interfaces. Similarly, transport_tcp_interface (receiver)
may be used on receivers to choose a particular interface.
15.2
Reference
15.2.1
transport_tcp_interface (receiver)
Specifies the network interface to which UM receivers bind before connecting to sources.
You can specify the full IP address of interface, or just the network part (see Specifying Interfaces for details).
Default is set to default_interface (context), if specified.
15.2.2
Scope:
receiver
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
transport_tcp_interface (source)
Specifies the network interface over which UM accepts connection requests (from topic receivers).
You can specify the full IP address of interface, or just the network part (see Specifying Interfaces for details).
Be aware that this option is applied to the transport session when the first topic is created on that session.
Thus, setting a different interface for a subsequent topic that maps onto the same transport session will have
no effect. Default is set to default_interface (context), if specified. Otherwise, it is set to INADDR_ANY, meaning
that it will not bind to a specific interface. You can also modify the default by setting the option to 0.0.0.0/0 which
produces the same result.
15.2 Reference
15.2.3
143
Scope:
source
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
transport_tcp_maximum_ports (context)
Maximum size of TCP source transport session pool.
See TCP Transport Session Management for how TCP source transport sessions are managed.
15.2.4
Scope:
context
Type:
lbm_uint16_t
Units:
number of ports
Default
value:
When
Set:
10
to
Can only be set during object initialization.
transport_tcp_port (source)
The TCP port to be used for the source transport session.
Setting this option to non-zero overrides the use of the pool of TCP source transport sessions.
The UM source listens on this port. Receivers that join the source's transport session connect to this port, and
the source sends message data across that connection.
See TCP Transport Session Management for how TCP source transport sessions are managed.
See Port Assignments for more information about configuring ports.
144
Transport TCP Network Options
Note that this port is only used by TCP sources. Receiver port numbers are taken from the host's Ephemeral
Ports and are not configurable.
Scope:
source
Type:
lbm_uint16_t
Default
value:
Byte order:
0 (pick open port)
When
Set:
15.2.5
Network
to
Can only be set during object initialization.
transport_tcp_port_high (context)
High TCP port number of range for pool of TCP source transport sessions.
When transport_tcp_port (source) is not specified, a newly-created transport session will use an unused port
from this range. The UM source listens on this port. Receivers that join the source's transport session connect
to this port, and the source sends message data across that connection.
See also transport_tcp_port_high (context).
See TCP Transport Session Management for how TCP source transport sessions are managed.
See Port Assignments for more information about configuring ports.
Note that this range of ports is only used by TCP sources. Receiver port numbers are taken from the host's
Ephemeral Ports and are not configurable.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14390
When
Set:
Host
to
Can only be set during object initialization.
15.2 Reference
15.2.6
145
transport_tcp_port_low (context)
Low TCP port number of range for pool of TCP source transport sessions.
When transport_tcp_port (source) is not specified, a newly-created transport session will use an unused port
from this range. The UM source listens on this port. Receivers that join the source's transport session connect
to this port, and the source sends message data across that connection.
See also transport_tcp_port_high (context).
See TCP Transport Session Management for how TCP source transport sessions are managed.
See Port Assignments for more information about configuring ports.
Note that this range of ports is only used by TCP sources. Receiver port numbers are taken from the host's
Ephemeral Ports and are not configurable.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14371
When
Set:
Host
to
Can only be set during object initialization.
146
Transport TCP Network Options
Chapter 16
Transport TCP Operation Options
16.1
Reference
16.1.1
transport_session_maximum_buffer (source)
Value used to control the maximum amount of data buffered in UM for the transport session used for the topic.
For the normal multiple receiver behavior, this value represents the total buffered by all TCP receivers. For the
bounded_latency and source_paced multiple receiver behavior, this value represents the individual receiver
buffered amount. This option affects the transport session underlying the source rather than the source itself.
The transport session uses the value from the first source created on the session and ignores subsequent
sources.
Refer to Source Object for additional information.
Scope:
source
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
65536
to
Can only be set during object initialization.
148
Transport TCP Operation Options
16.1.2
transport_tcp_activity_method (receiver)
The type of timeout method to use for TCP receivers to detect "half-open" TCP connections.
For TCP sessions only.
This defines how transport_tcp_activity_timeout (receiver) is interpreted. Note that transport_tcp_activity_←timeout (receiver) defaults to 0 (disabled), meaning that half-open TCP connections may not be detected in a
timely way.
Scope:
receiver
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.3.8/UME 2.0.6.
String value
Integer value
Description
"timer"
LBM_RCV_TOPIC_ATTR_TCP_ACTI←VITY_TIMEOUT_TIMER
"SO_KEEPALIVE"
LBM_RCV_TOPIC_ATTR_TCP_ACTI←VITY_TIMEOUT_SO_KEEPALIVE
Timer method that requires new TCP
session data to be sent to determine if the
connection is alive. Default for all.
Set SO_KEEPALIVE on the TCP connection which uses the TCP keepalive
support in the operating system to determine if the connection is alive. When you
use the SO_KEEPALIVE method, UM
uses transport_tcp_activity_timeout (receiver) value to set the idle and probe
times for SO_KEEPALIVE. The idle time
is 90% of the timeout value at most. The
probe time is 10% with 10 seconds as the
minimum.
16.1.3
transport_tcp_activity_timeout (receiver)
A timeout used by a receiver to close a TCP transport session that has no activity.
For TCP sessions only.
Normally, when a source transport session is deleted by the sending application, the TCP connection is closed,
which the receiver detects within a few milliseconds. However, there are unusual situations where a temporary
16.1 Reference
149
network outage prevents the receiver from detecting the closing of the connection, resulting in a "half-open"
connection. This situation can prevent the receiver from detecting the closed connection for an unbounded
time.
This timeout can be used to detect and close half-open connections.
This option has two different meanings, depending on the setting of transport_tcp_activity_method (receiver).
See that option for details.
A value greater than zero turns the timer on.
16.1.4
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0
to
Can only be set during object initialization.
transport_tcp_activity_timeout (source)
This timeout option enables a source to use SO_KEEPALIVE to detect when a receiver does not cleanly
disconnect or is no longer reachable from the source.
For TCP sessions only.
When the timeout expires, a DISCONNECT source event is delivered. This option affects only Linux or Windows
platforms. Outstanding TCP retransmit timers must expire before this timer starts. With a default Linux or
Windows system configuration, TCP retransmit timers may take minutes or even hours to expire. Therefore the
total time taken to detect an unreachable receiver may be significantly higher than the value configured for this
timeout. A value of zero (0) defers TCP timeout to OS settings.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0
to
Can only be set during object initialization.
150
Transport TCP Operation Options
16.1.5
transport_tcp_coalesce_threshold (source)
UM passes implicitly batched messages to the Operating System sendmsg() as a set unless the size of the set
exceeds the coalescing threshold at which point the messages are coalesced and passed to the O/S as one
copy.
This option accommodates the different number of iovecs supported by different O/Ss. Tuning this option
balances the efficiency of less iovecs handled by the OS vs. the expense of an additional copy operation of the
messages before sending. The default values are also the maximum allowable values.
16.1.6
Scope:
source
Type:
int
Units:
number of individual messages
Default
value:
When
Set:
Version:
1024 for Linux, Microsoft Windows, Darwin; 16 for Solaris, AIX, HPUX
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 2.3.
transport_tcp_datagram_max_size (context)
The maximum datagram size that can be generated for a TCP transport session. While TCP does not use
UDP datagrams, this option limits the size of the UM message which is given to the underlying transport type,
including all UM headers and overhead. It does not include TCP, IP, or packet overhead added by the network
stack. The default value is 65535, the minimum is 500 bytes, and the maximum is 65535.
See Message Fragmentation and Reassembly for more information.
Informatica does not recommend setting datagram max size options to the network MTU. See Datagram Max
Size and Network MTU.
Warning
When the DRO is in use, it is recommended that all UM applications and components (including the DRO and
Persistent Store) share the same maximum datagram size setting. See Protocol Conversion.
16.1 Reference
16.1.7
151
Scope:
context
Type:
lbm_uint_t
Units:
bytes
Default
value:
When
Set:
Version:
65535
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
transport_tcp_dro_loss_recovery_timeout (receiver)
For TCP transport sessions originating from a UM Router endpoint portal, delay declaring as unrecoverable a
lost message.
Message streams traversing a UM router can have the message order changed. If the final leg of the message
stream uses the TCP protocol, these out-of-order messages will normally trigger immediate unrecoverable loss.
This timeout allows an opportunity for the messages to be re-ordered properly.
The value 0 disables this delay (i.e. receivers immediately declare unrecoverable loss).
See UM Router Reliable Loss for more information.
16.1.8
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
0
to
Can only be set during object initialization.
This option was implemented in LBM 6.12
transport_tcp_exclusiveaddr (source)
Indicate whether the TCP session should set SO_EXCLUSIVEADDRUSE or not before it binds.
Applicable only to Windows. The default setting in Windows allows multiple binds to the same port. By de-
152
Transport TCP Operation Options
fault, UM will set SO_EXCLUSIVEADDRUSE to minimize port sharing. Refer to Microsoft's web site for more
information on SO_EXCLUSIVEADDRUSE.
Scope:
source
int
Type:
When
Set:
16.1.9
to
Can only be set during object initialization.
Value
Description
1
0
Set SO_EXCLUSIVEADDRUSE. Default for Windows.
Do not set SO_EXCLUSIVEADDRUSE.
transport_tcp_listen_backlog (source)
The backlog used in the TCP listen() call to set the queue length for incoming connections.
If 20 or more receivers will be joining this source, it may be beneficial to increase this number.
16.1.10
Scope:
source
Type:
int
Units:
number of queued connections
Default
value:
When
Set:
5
to
Can only be set during object initialization.
transport_tcp_multiple_receiver_behavior (source)
This option determines the flow control behavior of a TCP source that is sending to multiple receivers.
In particular, it addresses the scenario where some receivers are consuming messages slower than other
receivers (or not at all). In this scenario, pending messages will be buffered by the source up to the configured
16.1 Reference
153
limit specified by the transport_session_maximum_buffer (source) option. Once that limit is reached, the source
can either wait for slow receivers (resulting in a blocked source) or discard messages from the buffer (resulting
in gaps and potentially unrecoverable loss of messages for slow receivers).
This option affects the transport session underlying the source rather than the source itself. The transport
session uses the value from the first source created on the session and ignores the value set for subsequent
sources.
Refer to Source Object for additional information.
Scope:
source
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"normal"
LBM_SRC_TOPIC_ATTR_TCP_MUL←TI_RECV_NORMAL
"source_paced"
LBM_SRC_TOPIC_ATTR_TCP_MUL←TI_RECV_SOURCE_PACED
The application will wait for the slowest receiver rather than discarding recent
messages. This slows down all sources
on the TCP session. Default for all.
The application sends as fast as it can
even if recent messages headed for any
or all receivers must be discarded. Note
that for applications requiring sourcepaced behavior, LBT-RU and LBT-RM are
more efficient than source-paced TCP,
so this setting is primarily for scenarios
where UDP-based protocols are not viable.
"bounded_latency"
LBM_SRC_TOPIC_ATTR_TCP_MUL←TI_RECV_BOUNDED_LATENCY
16.1.11
The application sends as fast as the
fastest receiver can consume data even
if recent data headed for slower receivers
must be discarded. Deprecated since
UM 6.9.
transport_tcp_multiple_receiver_send_order (source)
In the case of multiple receivers, this option determines whether datagrams are sent to each receiver in the
established order of receivers, or if receivers are selected in random order for each datagram transmission.
154
Transport TCP Operation Options
Using random ordering can avoid giving one receiver a consistent latency advantage, at the expense of slightly
higher per-message processing (calculating the random number).
Scope:
source
Type:
lbm_src_topic_attr_t
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"serial"
LBM_SRC_TOPIC_ATTR_TCP_MULTI_←RECV_SEND_ORDER_SERIAL
"random"
LBM_SRC_TOPIC_ATTR_TCP_MULTI_←RECV_SEND_ORDER_RANDOM
Select receivers to receive a datagram
based on current established order. Default
for all.
For each datagram sent, select receivers
in random order, for the sake of "fairness".
Note that this option adds a small amount of
CPU overhead.
16.1.12
transport_tcp_nodelay (source)
Controls whether the context sets TCP_NODELAY before it binds to the source port.
Setting TCP_NODELAY disables Nagle's algorithm, which somewhat decreases the efficiency and throughput
of TCP, but decreases the latency of individual messages.
Scope:
source
Type:
int
When
Set:
to
Can only be set during object initialization.
Value
Description
1
TCP transport sockets should set TCP_NODELAY (disable Nagle). Default for all.
0
TCP transport sockets should not set TCP_NODELAY (leave Nagle enabled).
16.1 Reference
16.1.13
155
transport_tcp_receiver_socket_buffer (context)
Value used to set SO_RCVBUF value of the TCP receivers for topics. In some cases the OS will not allow all
of this value to be used.
A value of 0 instructs UM to use the default OS values. See Socket Buffer Sizes for platform-dependent
information.
16.1.14
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
0 (use TCP autotuning)
to
Can only be set during object initialization.
transport_tcp_reuseaddr (source)
Whether the TCP session should set SO_REUSEADDR or not before it binds.
Warning
This option is not recommended for Microsoft Windows users because the SO_REUSEADDR socket option in
Windows allows a socket to forcibly bind to a port in use by another socket. Multiple sockets using the same
port results in indeterminate behavior.
Scope:
source
Type:
int
When
Set:
to
Can only be set during object initialization.
156
Transport TCP Operation Options
16.1.15
Value
Description
1
Set SO_REUSEADDR.
0
Do not set SO_REUSEADDR. Default for all.
transport_tcp_sender_socket_buffer (source)
Value used to set the SO_SNDBUF value of the TCP session.
In some cases the OS will not allow all of this value to be used. A value of 0 instructs UM to use the OS defaults.
See Socket Buffer Sizes for platform-dependent information.
16.1.16
Scope:
source
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
0 (use TCP autotuning)
to
Can only be set during object initialization.
transport_tcp_use_session_id (source)
Control whether a session ID is used for TCP Transport sessions.
This option should be set to 0 if a version 6.0 (and beyond) TCP source must interoperate with a version pre-6.0
receiver.
Scope:
source
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UM 6.0
16.1 Reference
Value
Description
1
Indicates the application desires TCP to use a session ID. Default for all.
0
Indicates the application does not desire TCP to use a session ID. For use when version pre-6.0
receivers must be used with TCP sources that are version 6.0 and beyond.
157
158
Transport TCP Operation Options
Chapter 17
Transport LBT-RM Network Options
17.1
LBT-RM Transport Session Management
The image below shows a simplified relationship between the primary LBT-RM transport network options.
Note
for a multi-homed LBT-RM source, the interface LBT-RM multicast resolver interface specified with resolver←_multicast_interface (context) will be used as the source for LBT-RM.
160
Transport LBT-RM Network Options
When a source is created, the application can explicitly map it to a transport session by setting the transport_←lbtrm_multicast_address (source) and transport_lbtrm_destination_port (source) options. If a previous source was
created on the same context with the same group/port pair, this new source will be mapped to the same transport
session. Note that two different contexts on the same host may share the same group/port pair, and the resulting
transport sessions will be separate and independent.
Alternatively, if the application does not explicitly specify a multicast group and destination port, UM will implicitly
assign the new source to a pool of transport sessions defined when the context was created. The pool is defined as a
range of multicast groups specified by the options transport_lbtrm_multicast_address_low (context) and transport←_lbtrm_multicast_address_high (context). The number of transport sessions in the pool is the range of the two
multicast group IP addresses, as represented by a 32-bit number. For example, the default settings 224.10.10.←10 and 224.10.10.14 are represented by the numbers 0xE00A0A0A and 0xE00A0A0E. This represents 5 different
groups, so the pool contains 5 transport sessions (all with the same destination port).
When a new source is created and the multicast group is not explicitly defined, UM will check to see how many
transport sessions are currently active from the pool within the context. If it is less than the number in the pool, then
UM will activate the next transport session in the range. However, if the context already has activated all transport
sessions in the pool, then the new topic is mapped to one of the existing transport sessions, in round-robin fashion.
17.2
Reference
17.2.1
transport_lbtrm_destination_port (source)
The UDP destination port used for this Topic when the transport is LBT-RM.
See LBT-RM Transport Session Management for how LBT-RM source transport sessions are managed.
See Port Assignments for more information about configuring ports.
Scope:
source
Type:
lbm_uint16_t
Default
value:
Byte order:
14400
When
Set:
Network
to
Can only be set during object initialization.
17.2 Reference
17.2.2
161
transport_lbtrm_multicast_address (source)
The preferred multicast address (or domain name of the multicast address) for this Topic when the transport is
LBT-RM.
If 0.0.0.0 (INADDR_ANY), the default, the context will use a round-robin method to select an address in the
configured multicast multicast address range: transport_lbtrm_multicast_address_high (context) - transport_←lbtrm_multicast_address_low (context).
See LBT-RM Transport Session Management for how LBT-RM source transport sessions are managed.
See Port Assignments for more information about configuring ports.
17.2.3
Scope:
source
Type:
struct in_addr
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
transport_lbtrm_multicast_address_high (context)
Multicast address (or domain name of the multicast address) used as the highest value to assign to LBT-RM
sessions.
See LBT-RM Transport Session Management for how LBT-RM source transport sessions are managed.
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
224.10.10.14
to
Can only be set during object initialization.
162
Transport LBT-RM Network Options
17.2.4
transport_lbtrm_multicast_address_low (context)
Multicast address (or domain name of the multicast address) used as the lowest value to assign to LBT-RM
sessions.
See LBT-RM Transport Session Management for how LBT-RM source transport sessions are managed.
17.2.5
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
224.10.10.10
to
Can only be set during object initialization.
transport_lbtrm_source_port_high (context)
Highest port number value used for LBT-RM source session's unicast NAK processing. Receivers send NAKs
to this port for to request retransmission. Each LBT-RM session must use a unique port value. Note that this
does not control the UDP source port on the outbound LBT-RM stream.
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14399
When
Set:
17.2.6
Host
to
Can only be set during object initialization.
transport_lbtrm_source_port_low (context)
Lowest port number value used for LBT-RM source session's unicast NAK processing. Receivers send NAKs
to this port for to request retransmission. Each LBT-RM session must use a unique port value. Note that this
does not control the UDP source port on the outbound LBT-RM stream.
17.2 Reference
163
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14390
When
Set:
Host
to
Can only be set during object initialization.
164
Transport LBT-RM Network Options
Chapter 18
Transport LBT-RM Reliability Options
18.1
LBT-RM Datagram
Loss Resulting in Unrecovered Message Loss
An LBT-RM receiver will attempt to recover lost datagrams. The options transport_lbtrm_nak_backoff_interval (receiver) and transport_lbtrm_nak_generation_interval (receiver) control the timing of the recovery effort. Timers for
both start when loss is detected. The following timeline illustrates a case where a receiver is notified of unrecoverable message loss following repeated datagram loss.
166
Transport LBT-RM Reliability Options
Note
the actual length of the interval randomization periods are between 1/2 and 3/2 of the configured interval value.
In the diagram above, time periods are not drawn to scale to simplify the diagram.
Set transport_lbtrm_nak_backoff_interval (receiver) to the NAK service time that could be reasonably expected
from the receiver's location in the network plus some cushion for network congestion. Set transport_lbtrm_nak_←generation_interval (receiver) to the latency budget established for the transport layer. See our whitepaper Topics
in High Performance Messaging for background on latency budgets. See also the KB article Reducing
Loss Recovery Latencies for more advice on tuning.
Note
these parameters relate to loss at the transport session (datagram) level, not the topic level. See Delivery
Control Options for information on how applications are informed of topic-level unrecoverable loss.
18.2
LBT-RM Source Ignoring NAKs for Efficiency
Bandwidth efficiency of an LBT-RM source may be improved by avoiding useless retransmissions. Consider the
case of an LBT-RM source that has received a NAK for a datagram that it has just retransmitted. If the NAK
and the retransmission crossed on the network, it is likely that the receiver generating the NAK will receive the
retransmission just sent. If so, there's no need for the source to send another retransmission, so the NAK can be
safely ignored.
The image below illustrates the timing relationships.
This shows NAKs for a given datagram being ignored for transport_lbtrm_ignore_interval (source) following the
retransmission of that datagram. (The successive NAKs received by the source indicate that more than one receiver
is subscribed to the source's topic.) A NAK will be serviced as normal following the passage of the interval.
When ignoring a NAK, the source sends a NCF (NAK ConFirmation) instead of a retransmission, which starts a
NAK suppression interval at the receiver.
18.3 LBT-RM Receiver Suppressing NAK Generation
18.3
167
LBT-RM Receiver Suppressing NAK Generation
LBT-RM sources want receivers to be notified that their NAKs have been heard. Prompt notification via a retransmission or NCF can suppress useless NAK generation. There are a variety of circumstances where the source
does not send a retransmission in response to a receiver's NAK. For example, NAKs received during the ignore
interval do not generate retransmissions. Another example would be if previous retransmissions have used up all
the retransmission bandwidth for the current rate limiter interval.
The image below illustrates a receiver's reaction to an NCF.
Following the receipt of an NCF, a receiver suppresses all NAK generation until transport_lbtrm_nak_suppress_←interval (receiver) passes. NAK generation resumes with the usual transport_lbtrm_nak_backoff_interval (receiver)
if repair was not received during the suppression interval.
Note
the actual length of the interval randomization period is between 1/2 and 3/2 of the configured interval value.
In the diagram above, time periods are not drawn to scale to simplify the diagram.
18.4
Reference
18.4.1
transport_lbtrm_ignore_interval (source)
The interval to ignore NAKs after a retransmission is sent.
This option affects the transport session underlying the source rather than the source itself. The transport
session uses the value from the first source created on the session and ignores subsequent sources. Refer to
Source Object for additional information.
168
Transport LBT-RM Reliability Options
18.4.2
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
transport_lbtrm_nak_backoff_interval (receiver)
For LBT-RM transport sessions only. The maximum interval between transmissions of a single NAK.
The actual time the receiver will wait to NAK again is random. The algorithm used to determine the time range is
(1/2 ∗ backoff_interval - 3/2 ∗ backoff_interval). This can result in a wait interval longer than the specified value.
This option affects the transport session underlying the receiver rather than the receiver itself. The transport
session uses the value from the first receiver created on the session and ignores subsequent receivers.
See also transport_lbtrm_nak_backoff_interval (receiver).
18.4.3
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
transport_lbtrm_nak_generation_interval (receiver)
The maximum time that a piece of data may be outstanding before the data is unrecoverably lost.
For LBT-RM transport sessions only. Although the minimum valid value is 5 milliseconds, larger values are
advisable. This option affects the transport session underlying the receiver rather than the receiver itself.
The transport session uses the value from the first receiver created on the session and ignores subsequent
receivers.
Refer to Receiver Object and Interrelated Configuration Options for additional information.
18.4 Reference
18.4.4
169
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
transport_lbtrm_nak_initial_backoff_interval (receiver)
For LBT-RM transport sessions only. The interval between loss detection and transmission of the first NAK.
The actual time the receiver will wait to NAK is random. The algorithm used to determine the time range is
(1/2 ∗ initial_backoff_interval - 3/2 ∗ initial_backoff_interval). This can result in a wait interval longer than the
specified value. A value of 0 indicates that the receiver should immediately send a NAK. Note that this is rarely
a good idea; see UM Recovery of Lost Packets.
See also transport_lbtrm_nak_backoff_interval (receiver).
18.4.5
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
50 (0.05 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
transport_lbtrm_nak_suppress_interval (receiver)
The maximum interval to suppress sending NAKs after an NCF or a NAK from another receiver.
For LBT-RM transport sessions only. This option affects the transport session underlying the receiver rather
than the receiver itself. The transport session uses the value from the first receiver created on the session and
ignores subsequent receivers. Refer to Receiver Object for additional information.
170
Transport LBT-RM Reliability Options
18.4.6
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
transport_lbtrm_receiver_socket_buffer (context)
Value used to set SO_RCVBUF value of the LBT-RM receiver multicast socket.
In some cases the OS will not allow all of this value to be used. See Socket Buffer Sizes for platform-dependent
information. See also our white paper Topics in High Performance Messaging for background and guidelines
on UDP buffer sizing.
18.4.7
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
8388608 (8MB)
to
Can only be set during object initialization.
transport_lbtrm_send_naks (receiver)
This flag indicates whether LBT-RM should send negative acknowledgements (NAKs) for missing packets or
not.
For LBT-RM transport sessions only. This option affects the transport session underlying the receiver rather
than the receiver itself. The transport session uses the value from the first receiver created on the session and
ignores subsequent receivers.
Refer to Receiver Object for additional information.
18.4 Reference
171
Scope:
receiver
int
Type:
When
Set:
18.4.8
to
Can only be set during object initialization.
Value
Description
1
NAKs are sent for missing packets to request retransmission. Default for all.
0
Do not send NAKs for missing packets.
transport_lbtrm_source_socket_buffer (context)
Value used to set SO_SNDBUF value of the LBT-RM send multicast socket.
In some cases the OS will not allow all of this value to be used. See Socket Buffer Sizes for platform-dependent
information. A value of 0 instructs UM to use the OS default.
18.4.9
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
1048576 (1MB)
to
Can only be set during object initialization.
transport_lbtrm_transmission_window_limit (source)
Caps the total amount of memory that a transmission window uses, which includes data and overhead.
For example, if the transport_lbtrm_transmission_window_size (source) is 24 MB (default) and the source
sends (with flush flag set) 1.2 million messages with a 20-byte payload and 230-byte header, the actual amount
of memory used can approximate 300 MB. The default value of 0 (zero) disables the transmission window size
limit.
172
Transport LBT-RM Reliability Options
18.4.10
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
0 (zero)
to
Can only be set during object initialization.
transport_lbtrm_transmission_window_size (source)
The maximum amount of buffered payload data, excluding UM headers, that the LBT-RM source is allowed to
retain for retransmissions.
The minimum valid value is 65,536 bytes. This option affects the transport session underlying the source rather
than the source itself. The transport session uses the value from the first source created on the session and
ignores subsequent sources.
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
25165824 (24 MB)
to
Can only be set during object initialization.
Chapter 19
Transport LBT-RM Operation Options
Reliable multicast protocols like LBT-RM rely on sequence numbers and the arrival of data after a loss as evidence
that the loss happened. What would happen if the last packet sent by a source was lost? How would receivers learn
of the loss if no further messages were sent?
LBT-RM generates session messages when the sources on a transport session stop sending. These messages
contain the expected last sequence number for the session so that receivers can detect loss even when sources
aren't sending. Session messages also help to maintain state in multicast routers and switches that require regular
traffic to prevent the reclamation of unused forwarding entries.
The image below illustrates the sending of session messages.
No session messages are generated as long as the interval between lbm_src_send() calls that generate writes
to LBT-RM is less than transport_lbtrm_sm_minimum_interval (source) option. The interval between session messages starts at transport_lbtrm_sm_minimum_interval (source) and doubles till it reaches transport_lbtrm_sm_←maximum_interval (source) at which point the interval continues at that level.
The absence of activity on a transport session is the only indication receivers get that a source is gone or no longer
available through any network path. LBT-RM receivers reset a session activity timer for each data message or
session message that arrives. If the activity timer ever expires, all receivers on the transport session receive an
LBM_MSG_EOS event. This is illustrated in the following timeline:
174
Transport LBT-RM Operation Options
The activity timer is controlled with the transport_lbtrm_activity_timeout (receiver) option.
19.1
Reference
19.1.1
transport_lbtrm_activity_timeout (receiver)
The maximum time that an LBT-RM session may be quiescent before it is deleted and an EOS event is delivered
for all topics using this transport session.
For LBT-RM transport sessions only. This option affects the transport session underlying the receiver rather
than the receiver itself. The transport session uses the value from the first receiver created on the session and
ignores subsequent receivers. Refer to Receiver Object for additional information.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
60000 (60 seconds)
to
Can only be set during object initialization.
19.1 Reference
19.1.2
175
transport_lbtrm_coalesce_threshold (source)
UM passes implicitly batched messages to the Operating System sendmsg() as a set unless the size of the set
exceeds the coalescing threshold at which point the messages are coalesced and passed to the O/S as one
copy.
This option accommodates the different number of iovecs supported by different O/Ss. Tuning this option
balances the efficiency of less iovecs handled by the OS vs. the expense of an additional copy operation of
the messages before sending. The default value is also the maximum allowable value for Solaris, AIX and
HPUX. For Linux and Microsoft Windows and Darwin, the maximum allowable value is 1023. These maximum
allowable values are one less than what the O/S provides. This option affects the transport session underlying
the source rather than the source itself. The transport session uses the value from the first source created on
the session and ignores subsequent sources. Refer to Source Object for additional information.
19.1.3
Scope:
source
Type:
int
Units:
number of individual messages
Default
value:
When
Set:
15
to
Can only be set during object initialization.
transport_lbtrm_data_rate_limit (context)
Maximum aggregate transmission rate of all LBT-RM sessions' original data plus retransmissions for this particular context.
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Note: For backwards compatibility with earlier versions, the lbm_context_attr_setopt() function will accept
both 32 and 64 bit values for this option. Note however that a 32-bit value can only specify a rate limit a little
larger than 4 Gbps.
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
10000000 (10 Mbps)
to
Can only be set during object initialization.
176
Transport LBT-RM Operation Options
19.1.4
transport_lbtrm_datagram_max_size (context)
The maximum UDP datagram payload size that can be generated for a LBT-RM transport session. Note that
this does not include UDP, IP, or packet overhead added by the network stack. The default value is 8192, the
minimum is 500 bytes, and the maximum is 65535.
See Message Fragmentation and Reassembly for more information.
Informatica does not recommend setting datagram max size options to the network MTU. See Datagram Max
Size and Network MTU.
Warning
When the DRO is in use, it is recommended that all UM applications and components (including the DRO and
Persistent Store) share the same maximum datagram size setting. See Protocol Conversion.
19.1.5
Scope:
context
Type:
lbm_uint_t
Units:
bytes
Default
value:
When
Set:
Version:
8192
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
transport_lbtrm_preactivity_timeout (receiver)
The time that a newly-joined LBT-RM transport session can have no activity before the receiver decides the
transport session is dead.
This option typically does not need to be set for deployments using UM version 3.3 and beyond. If this option is
set to 0 (the default), then the activity timeout for a newly-joined transport session is the same as transport_←lbtrm_activity_timeout (receiver).
The purpose of this option is for a receiver to allow an extended timeout for a newly-created source transport
session to have no activity prior to the first application message (or TSNI) being sent.
19.1 Reference
177
This option is most useful when sending applications use UM versions prior to 3.3, which did not use Topic Sequence Number Information messages (TSNIs; see transport_topic_sequence_number_info_interval (source)).
In these cases, the source does not start the transport session until the first application message is sent. If the
sending application might delay sending its first message for more than transport_lbtrm_activity_timeout (receiver) (60 seconds by default), the receiver will decide that the transport session is dead and will disconnect.
Assuming that the source is still actually alive, the receiver will subsequently re-join the session, which can lead
to "flapping".
This flapping can be prevented by setting transport_lbtrm_preactivity_timeout to a value greater than the worstcase delay before the sending application sends its first message.
In UM version 3.3 and beyond, LBT-RM sources enable TSNIs by default, which ensures that some transport
session activity will happen within 5 seconds, by default. Thus, there is no longer any need to set a different
timeout for a newly-joined transport session. But note that it also extends the time required for a receiver to
detect that a newly-joined source transport session is actually dead.
This option may still have some utility in UM version 3.3 and beyond if TSNIs need to be disabled.
19.1.6
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
0 (zero)
to
Can only be set during object initialization.
This option was implemented in LBM 3.4.1/UME 2.1.1.
transport_lbtrm_rate_interval (context)
Period that LBT-RM rate limiter runs.
Reducing period reduces burst intensity, but also increases CPU load. Refer to Rate Controls for additional
information about the UM rate limiting algorithm.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10
to
Can only be set during object initialization.
178
Transport LBT-RM Operation Options
19.1.7
String value
Integer value
Description
"10"
10
LBT-RM rate limiter runs every 10 milliseconds. Default for all.
"20"
20
LBT-RM rate limiter runs every 20 milliseconds.
"50"
50
LBT-RM rate limiter runs every 50 milliseconds.
"100"
100
LBT-RM rate limiter runs every 100 milliseconds.
transport_lbtrm_receiver_timestamp (context)
Controls whether high-resolution timestamps for received packets are delivered to the receiver callback.
For LBT-RM transport sessions only.
Refer to High-resolution Timestamps for additional information.
Scope:
context
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UM 6.9
Value
Description
1
Receive timestamps delivered to receive callback.
0
Receive timestamps not delivered. Default for all.
19.1 Reference
19.1.8
179
transport_lbtrm_recycle_receive_buffers (context)
Enables the use of buffer recycling for socket operations.
See Receive Buffer Recycling for more information, including restrictions on the use of this feature.
Scope:
context
int
Type:
When
Set:
Version:
19.1.9
to
Can only be set during object initialization.
This option was implemented in UM 6.12
Value
Description
1
Use buffer recycling.
0
Buffer recycling is not used. Default for all.
transport_lbtrm_retransmit_rate_limit (context)
Maximum aggregate transmission rate of all LBT-RM sessions' retransmissions for this particular context.
This should always be less than the value used for original data. Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Note: For backwards compatibility with earlier versions, the lbm_context_attr_setopt() function will accept
both 32 and 64 bit values for this option. Note however that a 32-bit value can only specify a rate limit a little
larger than 4 Gbps.
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
5000000 (5 Mbps)
to
Can only be set during object initialization.
180
Transport LBT-RM Operation Options
19.1.10
transport_lbtrm_sm_maximum_interval (source)
The maximum interval between LBT-RM session messages.
In lieu of data being sent, LBT-RM sends session messages to inform receivers of sequence numbers and to
let receivers know that the sender is still transmitting. This option affects the transport session underlying the
source rather than the source itself. The transport session uses the value from the first source created on the
session and ignores subsequent sources.
Refer to Source Object for additional information.
19.1.11
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
transport_lbtrm_sm_minimum_interval (source)
The minimum interval between LBT-RM session messages.
In lieu of data being sent, LBT-RM sends session messages to inform receivers of sequence numbers and to
let receivers know that the sender is still transmitting. This option affects the transport session underlying the
source rather than the source itself. The transport session uses the value from the first source created on the
session and ignores subsequent sources.
Refer to Source Object for additional information.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
19.1 Reference
19.1.12
181
transport_lbtrm_source_timestamp (context)
Controls whether high-resolution timestamps for transmitted packets are delivered to the source event callback.
For LBT-RM transport sessions only. Refer to High-resolution Timestamps for additional information.
Scope:
context
Type:
int
When
Set:
Version:
19.1.13
to
Can only be set during object initialization.
This option was implemented in UM 6.9
Value
Description
1
Transmit timestamps delivered to receive callback.
0
Transmit timestamps not delivered. Default for all.
transport_lbtrm_tgsz (source)
The transmission group size used for this Topic when LBT-RM is used.
This value must be greater than 0 and must be a power of 2 no greater than 32K. This option affects the
transport session underlying the source rather than the source itself. The transport session uses the value from
the first source created on the session and ignores subsequent sources. Refer to Source Object for additional
information.
Scope:
source
Type:
lbm_uint16_t
Units:
packets
Default
value:
When
Set:
8
to
Can only be set during object initialization.
182
Transport LBT-RM Operation Options
Chapter 20
Transport LBT-RU Network Options
20.1
LBT-RU Transport Session Management
The image below illustrates the relationship between the primary LBT-RU network options.
When a source is created, the application can explicitly map it to a transport session by setting the transport_lbtru←_port (source) option. If a previous source was created on the same context with the same port, this new source
will be mapped to the same transport session. However, two different contexts on the same host may not share the
same port number. If a source is created with a port number that is already in use, UM will return an error.
Alternatively, if the application does not explicitly specify a source port, UM will implicitly assign the new source to
a pool of transport sessions defined when the context was created. The pool is defined as a range of port numbers
specified by the options transport_lbtru_port_low (context) and transport_lbtru_port_high (context). In addition, the
option transport_lbtru_maximum_ports (context) defines the number of transport sessions in the pool.
When a new source is created and the source port is not explicitly defined, UM will check to see how many transport
184
Transport LBT-RU Network Options
sessions are currently active from the pool within the context. If it is less than the number in the pool, then UM will
activate the next transport session in the range. However, if the context already has activated all transport sessions
in the pool, then the new topic is mapped to one of the existing transport sessions, in round-robin fashion.
Notice that the default range of ports, 14380 to 14389, is 10 ports. But the default number of transport sessions in
the pool is 5. This allows two contexts to be created on the same host and use the same configuration. If more than
2 contexts are intended to co-exist on the same host, the port range and number of transport session per context
must be managed to give a unique port number to every transport session.
The option transport_lbtru_interface (source) may be used on LBT-RU sources to choose particular interface, overriding the default INADDR_ANY which accepts connections on all interfaces. Similarly, transport_lbtru_interface
(receiver) may be used on receivers to choose a particular interface for outgoing connections.
20.2
Reference
20.2.1
transport_lbtru_interface (receiver)
Specifies the network interface over which UM LBT-RU receivers read application data messages.
Can specify full IP address of interface, or just network part (see Specifying Interfaces for details).
Default is set to default_interface (context), if specified. Otherwise, it is set to INADDR_ANY, meaning that it
will accept incoming connection requests from any interface.
20.2.2
Scope:
receiver
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
transport_lbtru_interface (source)
Specifies the network interface over which UM LBT-RU sources receive connection requests from topic receivers.
Can specify full IP address of interface, or just network part (see Specifying Interfaces for details). Be aware
that this option is applied to the transport session when the first topic is created on that session. Thus, setting
a different interface for a subsequent topic that maps onto the same transport session will have no effect.
20.2 Reference
185
Default is set to default_interface (context), if specified. Otherwise, it is set to INADDR_ANY, meaning that it
will accept incoming connection requests from any interface.
20.2.3
Scope:
source
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
transport_lbtru_maximum_ports (context)
Maximum size of LBT-RU source transport session pool.
See LBT-RU Transport Session Management for how LBT-RU source transport sessions are managed.
20.2.4
Scope:
context
Type:
lbm_uint16_t
Units:
number of ports
Default
value:
When
Set:
5
to
Can only be set during object initialization.
transport_lbtru_port (source)
The UDP port to be used for the source transport session.
This is the source-side option. For receive-side ports, see transport_lbtru_port_low (receiver).
Setting this option to non-zero overrides the use of the pool of LBT-RU source transport sessions.
See LBT-RU Transport Session Management for how LBT-RU source transport sessions are managed.
See Port Assignments for more information about configuring ports.
186
Transport LBT-RU Network Options
Scope:
source
Type:
lbm_uint16_t
Default
value:
Byte order:
0 (use open port)
When
Set:
20.2.5
Network
to
Can only be set during object initialization.
transport_lbtru_port_high (context)
High UDP port number of range for pool of LBT-RU source transport sessions.
When transport_lbtru_port (source) is not specified, a newly-created transport session will use an unused port
from this range. Receivers that join the source's transport session send connection requests, acknowledgements, and NAKs to the source port.
See also transport_lbtru_port_high (context).
This is the source-side option. For the corresponding receiver option, see transport_lbtru_port_high (receiver).
See LBT-RU Transport Session Management for how LBT-RU source transport sessions are managed.
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14389
When
Set:
20.2.6
Host
to
Can only be set during object initialization.
transport_lbtru_port_high (receiver)
High port number to use for receiving LBT-RU data.
20.2 Reference
187
This is the receive-side option. For the corresponding source option, see transport_lbtru_port_high (context).
When a newly-created receiver joins a source's transport session, it finds a free port from this range, binds to
it, and informs the source of the receiver's IP and port. The UM source will send message data to that IP and
port.
Unlike most UM port ranges, if the library is not able to find an unused port in this range, it will log a warning
(Core-5688-3300), but instead of failing the receiver creation, it will allocate a port from the host's ephemeral
pool and operate normally. Thus, it is possible for a receiver to get messages on a port outside of the configured
range.
See Port Assignments for more information about configuring ports.
Scope:
receiver
Type:
lbm_uint16_t
Default
value:
Byte order:
14379
When
Set:
20.2.7
Host
to
Can only be set during object initialization.
transport_lbtru_port_low (context)
Low UDP port number of range for pool of LBT-RU source transport sessions.
When transport_lbtru_port (source) is not specified, a newly-created transport session will use an unused port
from this range. Receivers that join the source's transport session send connection requests, acknowledgements, and NAKs to the source port.
See also transport_lbtru_port_high (context).
This is the source-side option. For the corresponding receiver option, see transport_lbtru_port_low (receiver).
See LBT-RU Transport Session Management for how LBT-RU source transport sessions are managed.
See Port Assignments for more information about configuring ports.
188
Transport LBT-RU Network Options
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14380
When
Set:
20.2.8
Host
to
Can only be set during object initialization.
transport_lbtru_port_low (receiver)
Low port number to use for receiving LBT-RU data.
This is the receive-side option. For the corresponding source option, see transport_lbtru_port_low (context).
When a newly-created receiver joins a source's transport session, it finds a free port from this range, binds to
it, and informs the source of the receiver's IP and port. The UM source will send message data to that IP and
port.
Unlike most UM port ranges, if the library is not able to find an unused port in this range, it will log a warning
(Core-5688-3300), but instead of failing the receiver creation, it will allocate a port from the host's ephemeral
pool and operate normally. Thus, it is possible for a receiver to get messages on a port outside of the configured
range.
See Port Assignments for more information about configuring ports.
Scope:
receiver
Type:
lbm_uint16_t
Default
value:
Byte order:
14360
When
Set:
Host
to
Can only be set during object initialization.
Chapter 21
Transport LBT-RU Reliability Options
LBT-RU's reliability options closely model LBT-RM's. The descriptions and illustrations in Transport LBT-RM Reliability Options generally apply to LBT-RU, with appropriate option name changes.
21.1
Reference
21.1.1
transport_lbtru_ignore_interval (source)
The interval to ignore NAKs after a retransmission is sent.
This option affects the transport session underlying the source rather than the source itself. The transport
session uses the value from the first source created on the session and ignores subsequent sources.
Refer to Source Object for additional information.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
190
Transport LBT-RU Reliability Options
21.1.2
transport_lbtru_nak_backoff_interval (receiver)
The maximum interval between transmissions of a single NAK.
For LBT-RU transport sessions only. The actual value is randomized (to reduce self-similar behaviors) and
is uniform on the range [0.5∗interval, 1.5∗interval]. This option affects the transport session underlying the
receiver rather than the receiver itself. The transport session uses the value from the first receiver created
on the session and ignores subsequent receivers. Refer to Receiver Object and Interrelated Configuration
Options for additional information.
21.1.3
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
transport_lbtru_nak_generation_interval (receiver)
The maximum time that a piece of data may be outstanding before the data is unrecoverably lost.
For LBT-RU transport sessions only. Although the minimum valid value is 5 milliseconds, larger values are
advisable. This option affects the transport session underlying the receiver rather than the receiver itself.
The transport session uses the value from the first receiver created on the session and ignores subsequent
receivers. Refer to Receiver Object and Interrelated Configuration Options for additional information.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
21.1 Reference
21.1.4
191
transport_lbtru_nak_initial_backoff_interval (receiver)
The interval between loss detection and transmission of the first NAK.
For LBT-RU transport sessions only.
The actual time the receiver will wait to NAK is random. The algorithm used to determine the time range is
(1/2 ∗ initial_backoff_interval - 3/2 ∗ initial_backoff_interval). This can result in a wait interval longer than the
specified value. A value of 0 indicates that the receiver should immediately send a NAK.
21.1.5
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0 (disabled)
to
Can only be set during object initialization.
transport_lbtru_nak_suppress_interval (receiver)
The maximum interval to suppress sending NAKs after an NCF is received.
For LBT-RU transport sessions only. This option affects the transport session underlying the receiver rather
than the receiver itself. The transport session uses the value from the first receiver created on the session and
ignores subsequent receivers. Refer to Receiver Object for additional information.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
192
Transport LBT-RU Reliability Options
21.1.6
transport_lbtru_receiver_socket_buffer (context)
Value used to set SO_RCVBUF value of the LBT-RU receiver unicast socket (both sender and receiver sides).
In some cases the OS will not allow all of this value to be used. See Socket Buffer Sizes for platform-dependent
information.
See also our white paper Topics in High Performance Messaging for background and guidelines on UDP buffer
sizing.
21.1.7
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
8388608 (8MB)
to
Can only be set during object initialization.
transport_lbtru_source_socket_buffer (context)
Value used to set SO_SNDBUF value of the LBT-RU send multicast socket.
In some cases the OS will not allow all of this value to be used. See Socket Buffer Sizes for platform-dependent
information. A value of 0 instructs UM to use the OS default.
21.1.8
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
1048576 (1MB)
to
Can only be set during object initialization.
transport_lbtru_transmission_window_limit (source)
Caps the total amount of memory that a transmission window uses, which includes data and overhead.
21.1 Reference
193
For example, if the transport_lbtru_transmission_window_size (source) is 24 MB (default) and the source sends
20 byte messages with the "flush" flag, the actual amount of memory used can approximate 300 MB. The default
value of this option does not limit the transmission window.
21.1.9
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
0 (zero)
to
Can only be set during object initialization.
transport_lbtru_transmission_window_size (source)
The maximum amount of buffered data that the LBT-RU source is allowed to retain for retransmissions.
The minimum valid value is 65536 bytes. This option affects the transport session underlying the source rather
than the source itself. The transport session uses the value from the first source created on the session and
ignores subsequent sources. Refer to Source Object for additional information.
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
25165824 (24 MB)
to
Can only be set during object initialization.
194
Transport LBT-RU Reliability Options
Chapter 22
Transport LBT-RU Operation Options
LBT-RU's operational options closely model LBT-RM's. The descriptions and illustrations in Transport LBT-RM
Operation Options generally apply to LBT-RU, with appropriate option name changes.
The following options are present for LBT-RU but not LBT-RM:
• transport_lbtru_client_map_size (source)
• transport_lbtru_connect_interval (receiver)
• transport_lbtru_acknowledgement_interval (receiver)
• transport_lbtru_client_activity_timeout (source)
The image below illustrates the timing of the latter two LBT-RU unique options:
22.1
Reference
196
Transport LBT-RU Operation Options
22.1.1
transport_lbtru_acknowledgement_interval (receiver)
The interval between sending acknowledgements.
For LBT-RU transport session only. Each client continually sends acknowledgements to let the source know
that the client is still alive. This option affects the transport session underlying the receiver rather than the
receiver itself. The transport session uses the value from the first receiver created on the session and ignores
subsequent receivers. Refer to Receiver Object for additional information.
22.1.2
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
transport_lbtru_activity_timeout (receiver)
The maximum time that an LBT-RU session may be quiescent before it is deleted and an EOS event is delivered
for all topics using this transport session.
For LBT-RU transport sessions only. This option affects the transport session underlying the receiver rather
than the receiver itself. The transport session uses the value from the first receiver created on the session and
ignores subsequent receivers. Refer to Receiver Object for additional information.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
60000 (60 seconds)
to
Can only be set during object initialization.
22.1 Reference
22.1.3
197
transport_lbtru_client_activity_timeout (source)
The maximum time that an LBT-RU client may be quiescent, i.e. not sending ACKs, before the sender assumes
that it is dead and stops sending to it.
This option affects the transport session underlying the source rather than the source itself. The transport
session uses the value from the first source created on the session and ignores subsequent sources. Refer to
Source Object for additional information.
22.1.4
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
transport_lbtru_client_map_size (source)
The size of the hash table used to store client information and state.
This option affects the transport session underlying the source rather than the source itself. The transport
session uses the value from the first source created on the session and ignores subsequent sources. Refer to
Source Object for additional information.
22.1.5
Scope:
source
Type:
size_t
Units:
Default
value:
When
Set:
table entries
7
to
Can only be set during object initialization.
transport_lbtru_coalesce_threshold (source)
UM passes implicitly batched messages to the Operating System sendmsg() as a set unless the size of the set
exceeds the coalescing threshold at which point the messages are coalesced and passed to the O/S as one
198
Transport LBT-RU Operation Options
copy.
This option accommodates the different number of iovecs supported by different O/Ss. Tuning this option
balances the efficiency of less iovecs handled by the OS vs. the expense of an additional copy operation of
the messages before sending. The default value is also the maximum allowable value for Solaris, AIX and
HPUX. For Linux and Microsoft Windows and Darwin, the maximum allowable value is 1023. These maximum
allowable values are one less than what the O/S provides. This option affects the transport session underlying
the source rather than the source itself. The transport session uses the value from the first source created on
the session and ignores subsequent sources. Refer to Source Object for additional information.
22.1.6
Scope:
source
Type:
int
Units:
number of messages
Default
value:
When
Set:
15
to
Can only be set during object initialization.
transport_lbtru_connect_interval (receiver)
The interval between sending connection requests.
For LBT-RU transport session only. This option affects the transport session underlying the receiver rather than
the receiver itself. The transport session uses the value from the first receiver created on the session and
ignores subsequent receivers. Refer to Receiver Object for additional information.
22.1.7
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
100 (0.1 seconds)
to
Can only be set during object initialization.
transport_lbtru_data_rate_limit (context)
Maximum aggregate transmission rate of all LBT-RU sessions original data for this particular context.
22.1 Reference
199
Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Note: For backwards compatibility with earlier versions, the lbm_context_attr_setopt() function will accept
both 32 and 64 bit values for this option. Note however that a 32-bit value can only specify a rate limit a little
larger than 4 Gbps.
22.1.8
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
10000000 (10 Mbps)
to
Can only be set during object initialization.
transport_lbtru_datagram_max_size (context)
The maximum UDP datagram payload size that can be generated for a LBT-RU transport session. Note that
this does not include UDP, IP, or packet overhead added by the network stack. The default value is 8192, the
minimum is 500 bytes, and the maximum is 65535.
See Message Fragmentation and Reassembly for more information.
Informatica does not recommend setting datagram max size options to the network MTU. See Datagram Max
Size and Network MTU.
Warning
When the DRO is in use, it is recommended that all UM applications and components (including the DRO and
Persistent Store) share the same maximum datagram size setting. See Protocol Conversion.
Scope:
context
Type:
lbm_uint_t
Units:
bytes
Default
value:
When
Set:
Version:
8192
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
200
Transport LBT-RU Operation Options
22.1.9
transport_lbtru_maximum_connect_attempts (receiver)
The maximum number of connect attempts to make before this transport session is deleted and an EOS event
is delivered for all topics using this transport session.
This option affects the transport session underlying the receiver rather than the receiver itself. The transport
session uses the value from the first receiver created on the session and ignores subsequent receivers. Refer
to Receiver Object for additional information.
22.1.10
Scope:
receiver
Type:
lbm_ulong_t
Default
value:
When
Set:
600
to
Can only be set during object initialization.
transport_lbtru_rate_interval (context)
Period that LBT-RU rate limiter runs.
Reducing period reduces burst intensity, but also increases CPU load. Refer to Rate Controls for additional
information about the UM rate limiting algorithm.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
100
to
Can only be set during object initialization.
22.1 Reference
201
String value
Integer value
Description
"10"
10
LBT-RU rate limiter runs every 10 milliseconds.
"20"
20
LBT-RU rate limiter runs every 20 milliseconds.
"50"
50
LBT-RU rate limiter runs every 50 milliseconds.
"100"
100
LBT-RU rate limiter runs every 100 milliseconds. Default for all.
22.1.11
transport_lbtru_recycle_receive_buffers (context)
Enables the use of buffer recycling for socket operations.
See Receive Buffer Recycling for more information, including restrictions on the use of this feature.
Scope:
context
int
Type:
When
Set:
Version:
22.1.12
to
Can only be set during object initialization.
This option was implemented in UM 6.12
Value
Description
1
Use buffer recycling.
0
Buffer recycling is not used. Default for all.
transport_lbtru_retransmit_rate_limit (context)
Maximum aggregate transmission rate of all LBT-RU sessions retransmissions for this particular context.
This should always be less than the value used for original data. Refer to Rate Controls for additional information about the UM rate limiting algorithm.
Note: For backwards compatibility with earlier versions, the lbm_context_attr_setopt() function will accept
202
Transport LBT-RU Operation Options
both 32 and 64 bit values for this option. Note however that a 32-bit value can only specify a rate limit a little
larger than 4 Gbps.
22.1.13
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
5000000 (5 Mbps)
to
Can only be set during object initialization.
transport_lbtru_sm_maximum_interval (source)
The maximum interval between LBT-RU session messages.
In lieu of data being sent, LBT-RU sends session messages to each client to inform them of sequence numbers
and to let receivers know that the sender is still transmitting. This option affects the transport session underlying
the source rather than the source itself. The transport session uses the value from the first source created on
the session and ignores subsequent sources. Refer to Source Object for additional information.
22.1.14
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
transport_lbtru_sm_minimum_interval (source)
The minimum interval between LBT-RU session messages.
In lieu of data being sent, LBT-RU sends session messages to each client to inform them of sequence numbers
and to let receivers know that the sender is still transmitting. This option affects the transport session underlying
the source rather than the source itself. The transport session uses the value from the first source created on
the session and ignores subsequent sources. Refer to Source Object for additional information.
22.1 Reference
22.1.15
203
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
transport_lbtru_use_session_id (source)
Control whether a session ID is used for LBT-RU Transport sessions.
This option should be set to 0 if a version 3.3 (and beyond) LBT-RU source must interoperate with a version
pre-3.3 receiver.
Scope:
source
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UM 3.3
Value
Description
1
Indicates the application desires LBT-RU to use a session ID. Default for all.
0
Indicates the application does not desire LBT-RU to use a session ID. For use when version pre-3.3
receivers must be used with TCP sources that are version 3.3 and beyond.
204
Transport LBT-RU Operation Options
Chapter 23
Transport LBT-IPC Operation Options
The image below illustrates the timing of an LBT-IPC transport session.
The Source Session Message mechanism enables the receiver to detect when a source goes away and works
similarly to LBT-RU. It operates independently of message writes/reads in the Shared Memory Area.
23.1
LBT-IPC Transport Session Management
When a source is created, the application can explicitly map it to a transport session by setting the transport_←lbtipc_id (source) option. If a previous source was created on the same context with the same ID number, this new
source will be mapped to the same transport session. Note that ID numbers can be re-used by different contexts on
the same host. The resulting transport sessions will be separate, independent, and non-interfering.
Alternatively, if the application does not explicitly specify a source ID, UM will implicitly assign the new source to a
pool of transport sessions defined when the context was created. The pool is defined as a range of ID numbers
specified by the options transport_lbtipc_id_low (context) and transport_lbtipc_id_high (context). The numeric range
defines the number of transport sessions in the pool.
When a new source is created and the source port is not explicitly defined, UM will check to see how many transport
sessions are currently active from the pool within the context. If it is less than the configured range of IDs then UM
206
Transport LBT-IPC Operation Options
will use the next ID in the range transport_lbtipc_id_low (context) to transport_lbtipc_id_high (context). However,
if the context already has activated all transport sessions in the pool, then the new topic is mapped to one of the
existing transport sessions, in round-robin fashion.
23.2
Reference
23.2.1
transport_lbtipc_activity_timeout (receiver)
The maximum period of inactivity (lack of session messages) from an IPC source before the UM delivers an
EOS event for all topics using the transport session.
Refer to Receiver Object and Interrelated Configuration Options for additional information.
23.2.2
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
60,000 (60 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.5ea2/UME 2.2ea1
transport_lbtipc_behavior (source)
Desired flow control behavior when multiple receivers have joined the same LBT-IPC transport session.
See also Transport LBT-IPC. This option affects the transport session underlying the source rather than the
source itself. The transport session uses the value from the first source created on the session and ignores
subsequent sources.
Refer to Source Object for additional information.
Scope:
source
Type:
lbm_ushort_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
23.2 Reference
207
String value
Integer value
Description
"source_paced"
LBM_SRC_TOPIC_ATTR_LBTIPC_BE←HAVIOR_SOURCE_PACED
"receiver_paced"
LBM_SRC_TOPIC_ATTR_LBTIPC_BE←HAVIOR_RECEIVER_PACED
Your application writes as fast as it can to
the LBT-IPC shared memory area. Slower
receivers can experience loss. A source
does not consider if any receivers have
successfully read a message before it reclaims it. Default for all.
Your application writes to the LBT-IPC
shared memory area only as fast as the
slowest receiver consumes data. A source
will not reclaim a message until all receivers have successfully read the message. This slows down all receiver on the
LBT-IPC transport session.
23.2.3
transport_lbtipc_datagram_max_size (context)
The maximum datagram size that can be generated for a LBT-IPC transport session. While IPC does not
use UDP datagrams, this option limits the size of the UM message which is given to the underlying transport
type, including all UM headers and overhead. The default value is 65535, the minimum is 500 bytes, and the
maximum is 65535.
See Message Fragmentation and Reassembly for more information.
Informatica does not recommend setting datagram max size options to the network MTU. See Datagram Max
Size and Network MTU.
Warning
When the DRO is in use, it is recommended that all UM applications and components (including the DRO and
Persistent Store) share the same maximum datagram size setting. See Protocol Conversion.
Scope:
context
Type:
lbm_uint_t
Units:
bytes
Default
value:
When
Set:
Version:
65535
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
208
Transport LBT-IPC Operation Options
23.2.4
transport_lbtipc_dro_loss_recovery_timeout (receiver)
For IPC transport sessions originating from a UM Router endpoint portal, delay declaring as unrecoverable a
lost message.
Message streams traversing a UM router can have the message order changed. If the final leg of the message
stream uses the IPC protocol, these out-of-order messages will normally trigger immediate unrecoverable loss.
This timeout allows an opportunity for the messages to be re-ordered properly.
The value 0 disables this delay (i.e. receivers immediately declare unrecoverable loss).
See UM Router Reliable Loss for more information.
23.2.5
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
0
to
Can only be set during object initialization.
This option was implemented in LBM 6.12
transport_lbtipc_id (source)
The preferred Transport ID for a specific source's LBT-IPC session.
If 0, the UM context attempts to find one in the given Transport ID range of transport_lbtipc_id_low (context)
and transport_lbtipc_id_high (context). Refer to Source Object for additional information.
Scope:
source
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
0 (use open ID)
to
Can only be set during object initialization.
This option was implemented in LBM 3.5ea2/UME 2.2ea1
23.2 Reference
23.2.6
209
transport_lbtipc_id_high (context)
Highest transport ID of the range of available LBT-IPC Transport IDs.
See LBT-RU Transport Session Management for more information.
23.2.7
Scope:
context
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
20,005
to
Can only be set during object initialization.
This option was implemented in LBM 3.5ea2/UME 2.2ea1
transport_lbtipc_id_low (context)
Lowest transport ID of the range of available LBT-IPC Transport IDs.
See LBT-RU Transport Session Management for more information.
Scope:
context
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
20,001
to
Can only be set during object initialization.
This option was implemented in LBM 3.5ea2/UME 2.2ea1
210
Transport LBT-IPC Operation Options
23.2.8
transport_lbtipc_maximum_receivers_per_transport (source)
The maximum number of receiving contexts that can join an IPC transport session.
Once a receiving context joins an IPC transport session, it can receive messages on multiple topics. Increasing
this value increases the amount of shared memory allocated per transport session by a negligible amount.
23.2.9
Scope:
source
Type:
lbm_ushort_t
Default
value:
When
Set:
Version:
20
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
transport_lbtipc_pend_behavior_linger_loop_count (context)
When using pend as the LBTIPC receiver thread behavior, the receiver loop can linger in a temporary busy wait
behavior before pending again.
At high sustained rates or during short bursts of data, this can result in a significant reduction in the number
of kernel calls if more data arrives relatively quickly. Once the burst subsides, the CPU utilization drops again
since the receiver would be pending. The default value of 1 results in legacy pend behavior. If the value is set
large, significant CPU will be consumed.
23.2.10
Scope:
context
Type:
lbm_ulong_t
Default
value:
When
Set:
Version:
1
to
Can only be set during object initialization.
This option was implemented in UM 6.10
transport_lbtipc_receiver_operational_mode (context)
The mode in which UM operates to process LBT-IPC messages.
23.2 Reference
211
See Embedded Mode for additional information.
Scope:
context
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"embedded"
LBM_CTX_ATTR_OP_EMBEDDED
UM spawns a thread to process received LBT-IPC
messages. Default for all.
"sequential"
LBM_CTX_ATTR_OP_SEQUENTIAL
Your application must call lbm_context_←process_lbtipc_messages() to process received
LBT-IPC messages. If you also set the context's
operational_mode option to sequential, your
application must donate an additional thread
to service the lbm_context_process_events()
calls. Note: You can use sequential mode with the
C API, but not with the Java API or .NET API. The
Java and .NET APIs do not provide an equivalent
lbm_context_process_lbtipc_messages() API
for LBT- IPC.
23.2.11
transport_lbtipc_receiver_thread_behavior (context)
Receiver behavior for monitoring the signaling semaphore set by the IPC source when it writes new data to the
shared memory area.
Note that the IPC thread is not the same as the Context thread.
Scope:
context
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.5ea2/UME 2.2ea1
212
Transport LBT-IPC Operation Options
String value
Integer value
Description
"pend"
LBM_CTX_ATTR_IPC_RCV_THREAD_←PEND
"busy_wait"
LBM_CTX_ATTR_IPC_RCV_THREAD_←BUSY_WAIT
Receiver waits (sleep) for notification from
OS that IPC source has updated the signaling semaphore. This option is best when the
IPC source frequently writes new data to the
shared area. Default for all.
Provides the lowest latency as the receiver
monopolizes the CPU core looking for an incremented semaphore. This option works
best for infrequent or sporadic message delivery from the IPC source, but involves a
CPU cost.
23.2.12
transport_lbtipc_recycle_receive_buffers (context)
Enables the use of buffer recycling for IPC operations.
See Receive Buffer Recycling for more information, including restrictions on the use of this feature.
Scope:
context
Type:
int
When
Set:
Version:
23.2.13
to
Can only be set during object initialization.
This option was implemented in UM 6.12
Value
Description
1
Use buffer recycling.
0
Buffer recycling is not used. Default for all.
transport_lbtipc_sm_interval (source)
Time period between sessions message sent from source to receivers.
23.2 Reference
213
Refer to Source Object and Interrelated Configuration Options for additional information.
23.2.14
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10,000 (10 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.5ea2/UME 2.2ea1
transport_lbtipc_transmission_window_size (source)
Size of an LBT-IPC transport's shared memory area.
This value may vary across platforms. The actual size of the shared memory area equals the value you specify
for this option plus about 64 KB for header information. The minimum value for this option is 65,536. Refer to
Source Object for additional information.
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
Version:
25165824 (24 MB)
to
Can only be set during object initialization.
This option was implemented in LBM 3.5ea2/UME 2.2ea1
214
Transport LBT-IPC Operation Options
Chapter 24
Transport LBT-SMX Operation Options
The image below illustrates the timing of an LBT-SMX transport session.
The Source Session Message mechanism enables the receiver to detect when a source goes away and works
similarly to LBT-RU. It operates independently of message writes/reads in the Shared Memory Area.
24.1
LBT-SMX Transport Session Management
When a source is created, the application can explicitly map it to a transport session by setting the transport_←lbtsmx_id (source) option. If a previous source was created on the same context with the same ID number, this new
source will be mapped to the same transport session. Note that ID numbers can be re-used by different contexts on
the same host. The resulting transport sessions will be separate, independent, and non-interfering.
Alternatively, if the application does not explicitly specify a source ID, UM will implicitly assign the new source to a
pool of transport sessions defined when the context was created. The pool is defined as a range of ID numbers
specified by the options transport_lbtsmx_id_low (context) and transport_lbtsmx_id_high (context). The numeric
range defines the number of transport sessions in the pool.
When a new source is created and the source port is not explicitly defined, UM will check to see how many transport
sessions are currently active from the pool within the context. If it is less than the configured range of IDs then UM
will use the next ID in the range transport_lbtsmx_id_low (context) to transport_lbtsmx_id_high (context). However,
216
Transport LBT-SMX Operation Options
if the context already has activated all transport sessions in the pool, then the new topic is mapped to one of the
existing transport sessions, in round-robin fashion.
24.2
Reference
24.2.1
transport_lbtsmx_activity_timeout (receiver)
The maximum period of inactivity (lack of updates to the source's shared activity counter) from an SMX source
before UM delivers an EOS event for all topics using the transport session.
You should configure this option to a value greater than the source's transport_lbtsmx_sm_interval so receivers
do not erroneously report a source as inactive.
24.2.2
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
60,000 (60 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 6.1
transport_lbtsmx_datagram_max_size (source)
The maximum datagram size that can be sent for an LBT-SMX transport session.
While SMX does not use UDP datagrams, this option limits the size of the UM message which is given to the
underlying transport type, including all UM headers and overhead. This value includes 16 bytes of header
information per message, plus an additional 24 bytes of reserved space for compatibility with other egress
transports when re-sending SMX messages through a UM Dynamic Router. Therefore, the largest usable
message size for the default setting of 8192 bytes would be 8176 bytes (8192 - 16 - 24). The minimum is 32
bytes. The maximum size is limited by available memory.
This option imposes a hard limit on message size because the LBT-SMX transport does not support datagram
fragmentation or reassembly. Unlike other transports that do support fragmentation, attempts to send messages
larger than the datagram size configured by this option fail.
24.2 Reference
217
The minimum value for this option is 32 bytes. Unlike other transports, there is no hard-coded maximum value;
the maximum is limited only by the amount of memory available.
Note: The source's configured transport_lbtsmx_transmission_window_size (source) must be at least twice as
large as the source's configured transport_lbtsmx_datagram_max_size. If the transmission window has not
been configured to be large enough to hold at least two maximum-sized SMX datagrams, then a warning will
be issued and the source's transport_lbtsmx_transmission_window_size option will be automatically adjusted
upwards to the nearest power-of-2 size in bytes that can fit at least two maximum-sized datagrams.
See Message Fragmentation and Reassembly for more information.
Informatica does not recommend setting datagram max size options to the network MTU. See Datagram Max
Size and Network MTU.
Warning
When the DRO is in use, it is recommended that all UM applications and components (including the DRO and
Persistent Store) share the same maximum datagram size setting. See Protocol Conversion.
24.2.3
Scope:
source
Type:
lbm_uint_t
Units:
bytes
Default
value:
When
Set:
Version:
8192
to
Can only be set during object initialization.
This option was implemented in UM 6.1
transport_lbtsmx_id (source)
The preferred Transport ID for a specific source's LBT-SMX session.
To use this option, configure a non-zero value. For the default value of 0 (zero), the UM context selects the next
available Transport ID in the Transport ID range of transport_lbtsmx_id_low (context) and transport_lbtsmx_←id_high (context).
Refer to Source Object for additional information.
218
Transport LBT-SMX Operation Options
24.2.4
Scope:
source
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
0
to
Can only be set during object initialization.
This option was implemented in UM 6.1
transport_lbtsmx_id_high (context)
Highest transport ID in the range of available LBT-SMX Transport IDs.
See LBT-SMX Transport Session Management for more information.
24.2.5
Scope:
context
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
30,005
to
Can only be set during object initialization.
This option was implemented in UM 6.1
transport_lbtsmx_id_low (context)
Lowest transport ID in the range of available LBT-SMX Transport IDs.
See LBT-SMX Transport Session Management for more information.
Scope:
context
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
30,001
to
Can only be set during object initialization.
This option was implemented in UM 6.1
24.2 Reference
24.2.6
219
transport_lbtsmx_maximum_receivers_per_transport (source)
The maximum number of receiving contexts that can join an SMX transport session.
Once a receiving context joins an SMX transport session, it can receive messages on multiple topics. Increasing
this value increases the amount of shared memory allocated per transport session by a negligible amount.
24.2.7
Scope:
source
Type:
lbm_ushort_t
Default
value:
When
Set:
Version:
64
to
Can only be set during object initialization.
This option was implemented in UM 6.1
transport_lbtsmx_message_statistics_enabled (context)
Controls whether or not UM records LBT-SMX transport statistics
Enabling statistics gives better visibility of application behavior, at the expense of a small but measurable
amount of latency.
Scope:
context
Type:
int
Default
value:
When
Set:
Version:
0
to
Can only be set during object initialization.
This option was implemented in UM 6.1
Value
Description
1
UM records source and receiver LBT-SMX transport statistics.
220
Transport LBT-SMX Operation Options
24.2.8
Value
Description
0
UM does not record source and receiver LBT-SMX transport statistics. Default for all.
transport_lbtsmx_sm_interval (source)
Time period between updates to an LBT-SMX source's shared activity counter, which enables connected receivers to determine the source's liveness.
You should configure this option to a value less than the receivers' corresponding transport_lbtsmx_activity_←timeout (receiver) setting so receivers do not time out sources too early.
Refer to Source Object for additional information.
24.2.9
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10,000 (10 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 6.1
transport_lbtsmx_transmission_window_size (source)
Size of an LBT-SMX transport's shared memory area.
Must be a power of two and be twice a large as the source's transport_lbtsmx_datagram_max_size (source).
If you configure a value that is not a power of 2 or is less than twice the size of the maximum datagram size,
UM issues a warning log message and automatically rounds up the value of this option to the next power of 2
window size that can fit at least two maximum-sized datagrams. The minimum value for this option is 64 bytes.
Refer to Source Object for additional information.
Scope:
source
Type:
size_t
24.2 Reference
221
Units:
bytes
Default
value:
When
Set:
Version:
131072 (128 KB)
to
Can only be set during object initialization.
This option was implemented in UM 6.1
222
Transport LBT-SMX Operation Options
Chapter 25
Transport Acceleration Options
Transport acceleration options enable kernel-bypass acceleration in conjunction with the following vendor
solutions:
• Myricom® Datagram Bypass Layer (DBL™)
• Solarflare® Onload
• Mellanox® 10-Gigabit Ethernet or InfiniBand hardware
25.1
Myricom® Datagram Bypass Layer (DBL™)
DBL is a kernel-bypass technology that accelerates sending and receiving UDP traffic and operates with DBLenabled Myricom 10-Gigabit Ethernet adapter cards for Linux and Microsoft® Windows.
DBL does not support fragmentation and reassembly, so do not send messages larger than the MTU size configured
on the DBL interface.
DBL acceleration is compatible with the following Ultra Messaging transport types:
• LBT-RM (UDP-based reliable multicast)
• LBT-RU (UDP-based reliable unicast)
• Multicast Immediate Messaging
• Multicast Topic Resolution
To use DBL Transport Acceleration, perform the following steps:
1. Install the Myricom 10-Gigabit Ethernet NIC.
2. Install the DBL shared library.
3. Update your search path to include the location of the DBL shared library.
4. Set option transport_∗_datagram_max_size and option resolver_datagram_max_size (context) to a value of
no more than 28 bytes smaller than the Myricom interface's configured MTU size.
224
Transport Acceleration Options
25.2
Reference
25.2.1
dbl_lbtrm_acceleration (context)
Flag indicating if DBL acceleration is enabled for LBT-RM transports.
See Myricom® Datagram Bypass Layer (DBL™).
Scope:
context
Type:
int
When
Set:
Version:
25.2.2
to
Can only be set during object initialization.
This option was implemented in LBM 4.0.
Value
Description
1
DBL acceleration is enabled for LBT-RM.
0
DBL acceleration is not enabled for LBT-RM. Default for all.
dbl_lbtru_acceleration (context)
Flag indicating if DBL acceleration is enabled for LBT-RU transports.
See Myricom® Datagram Bypass Layer (DBL™).
Scope:
context
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.0.
25.2 Reference
25.2.3
225
Value
Description
1
DBL acceleration is enabled for LBT-RU.
0
DBL acceleration is not enabled for LBT-RU. Default for all.
dbl_mim_acceleration (context)
Flag indicating if DBL acceleration is enabled for multicast immediate messaging (MIM).
See Myricom® Datagram Bypass Layer (DBL™).
Scope:
context
int
Type:
When
Set:
Version:
25.2.4
to
Can only be set during object initialization.
This option was implemented in LBM 4.0.
Value
Description
1
DBL acceleration is enabled for MIM.
0
DBL acceleration is not enabled for MIM. Default for all.
dbl_resolver_acceleration (context)
Flag indicating if DBL acceleration is enabled for topic resolution.
See Myricom® Datagram Bypass Layer (DBL™).
Scope:
context
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.0.
226
Transport Acceleration Options
25.3
Value
Description
1
DBL acceleration is enabled for topic resolution.
0
DBL acceleration is not enabled for topic resolution. Default for all.
Solarflare® Onload
Solarflare Onload is a kernel-bypass technology that accelerates message traffic and operates with Solarflare 10←GbE Ethernet NICs.
Note
Onload does not support fragmentation and reassembly, so do not send messages larger than the MTU size
configured on the Solarflare interface.
Warning
Onload does not support both accelerated and non-accelerated processes subscribing to the same multicast
group on the same host. An attempt to do so will result in the non-accelerated process becoming "deaf" to
the shared multicast group. See "Onload User Guide", chapter 9.11 "Multicast Operation and Stack Sharing",
sub-section "Multicast Receive - Onload Stack and Kernel Stack".
Ultra Messaging loads the Onload library dynamically during Ultra Messaging initialization on the following Ultra
Messaging platforms:
• Linux-glibc-2.3-i686
• Linux-glibc-2.3-x86_64 Linux-glibc-2.5-x86_64
Onload default behavior accelerates all sockets. You can access the Onload onload_set_stackname API extension
to select the sockets you want to accelerate by using UM configuration options. Selecting sockets with a stackname
lets you accelerate data transmission sockets and not sockets for control messages, topic resolution, or responses.
You can select a stackname with the configuration options onload_acceleration_stack_name (receiver) and onload←_acceleration_stack_name (source) for the following Ultra Messaging transport types:
• LBT-RM (UDP-based reliable multicast)
• LBT-RU (UDP-based reliable unicast)
• TCP
25.4 Reference
227
Note
If you set the LBM_SUPPRESS_ONLOAD environment variable to any value, Ultra Messaging does not dynamically load the Onload library at runtime. In this case, you cannot use the onload_acceleration_stack_←name options.
If you use the onload_set_stackname API directly for any other accelerated sockets, note that after Ultra Messaging
accelerates a transport socket, Ultra Messaging resets the stackname to the default for all threads by calling:
onload_set_stackname(ONLOAD_ALL_THREADS, ONLOAD_SCOPE_NOCHANGE, "");
Ultra Messaging resets the stackname during source creation and when a receiver matched topic opens a transport
session.
To enable Onload socket acceleration for selected transports, perform the following steps:
1. Install Onload.
2. Set the Onload environment variable EF_DONT_ACCELERATE = 1 to disable Onload default behavior.
3. To enable acceleration for all applications in an environment, export the following environment variable:
export LD_PRELOAD=libonload.so
4. To enable acceleration on a per-application basis, start the application as in the following example:
onload [app_options]
5. Set UM configuration option onload_acceleration_stack_name (source) according to the thread the source
uses.
Note: Disable batching to ensure that it is the application thread that sends the data out.
6. Set UM configuration option onload_acceleration_stack_name (receiver) according to the thread the receiver
uses.
Note: Receiver transports might not share the same thread if MTT is enabled.
7. Set option transport_∗_datagram_max_size and option resolver_datagram_max_size (context) to a value of
no more than 28 bytes smaller than the Solarflare interface's configured MTU size.
For detailed information about onload stack names, refer to the Solarflare® Onload User Guide.
25.4
Reference
25.4.1
onload_acceleration_stack_name (receiver)
The stackname to use when creating an OpenOnload transport data socket.
The stackname must be eight characters or less. Because this is a transport setting, the first receiver applies
its configuration option setting, and other receivers that join the transport inherit the setting of the first source.
To disable the stackname, set this option to NULL, which must be all uppercase.
Note: Use of this option requires Solarflare OpenOnload and applies to LBT-RM, LBT-RU, and TCP transports.
228
Transport Acceleration Options
25.4.2
Scope:
receiver
Type:
string
Default
value:
When
Set:
Version:
NULL
to
Can only be set during object initialization.
This option was implemented in UM 6.5.
onload_acceleration_stack_name (source)
The stackname to use when creating an OpenOnload transport data socket.
The stackname must be eight characters or less. Because this is a transport setting, the first source applies its
configuration option setting, and other sources that join the transport inherit the setting of the first source. To
disable the stackname, set this option to NULL, which must be all uppercase.
Note: Use of this option requires Solarflare OpenOnload and applies to LBT-RM, LBT-RU, and TCP transports.
25.5
Scope:
source
Type:
string
Default
value:
When
Set:
Version:
NULL
to
Can only be set during object initialization.
This option was implemented in UM 6.5.
UD Acceleration for Mellanox® Hardware Interfaces
UD (Unreliable Datagram) acceleration is a kernel-bypass technology that accelerates sending and receiving UDP
traffic and operates with Mellanox 10-Gigabit Ethernet or InfiniBand adapter cards for 64-bit Linux on X86 platforms.
UD acceleration does not support fragmentation and reassembly, so do not send messages larger than the MTU
size configured on the Mellanox interface.
UD acceleration is available for the following Ultra Messaging transport types:
• LBT-RM (UDP-based reliable multicast)
• LBT-RU (UDP-based reliable unicast)
25.6 Reference
229
• Multicast Immediate Messaging
• Multicast Topic Resolution
To use UD acceleration, perform the following steps:
1. Install the Mellanox NIC.
2. Install the VMA package, which is part of the UD acceleration option .
3. Include the appropriate transport acceleration options in your Ultra Messaging Configuration File.
4. Set option transport_∗_datagram_max_size and option resolver_datagram_max_size (context) to a value of
no more than 28 bytes smaller than the Mellanox interface's configured MTU size.
25.6
Reference
25.6.1
resolver_ud_acceleration (context)
Flag indicating if Accelerated Multicast is enabled for Topic Resolution. Accelerated Multicast requires Mellanox
InfiniBand or 10 Gigabit Ethernet hardware.
UD Acceleration of topic resolution relies on hardware-supported loopback, which InfiniBand provides, but
which the 10 Gigabit Ethernet ConnectX hardware does not.
Note: If 10 Gigabit Ethernet ConnectX hardware is used and multiple UM contexts are desired on the host, this
option must be disabled.
Scope:
context
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 5.2.
Value
Description
1
Accelerated Topic Resolution is enabled.
0
Accelerated Topic Resolution is not enabled. Default for all.
230
Transport Acceleration Options
25.6.2
ud_acceleration (context)
Flag indicating if Accelerated Multicast is enabled for LBT-RM.
Accelerated Multicast requires InfiniBand or 10 Gigabit Ethernet hardware and the purchase and installation
of the Ultra Messaging Accelerated Multicast Module. See your Ultra Messaging representative for licensing
specifics.
Scope:
context
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.
Value
Description
1
Accelerated Multicast is enabled.
0
Accelerated Multicast is not enabled. Default for all.
Chapter 26
Smart Source Options
See Smart Sources for introductory information on Smart Sources.
26.1
Reference
26.1.1
mem_mgt_callbacks (source)
Callback functions (and optional associated client data pointer) that are called when a Smart Source allocates,
reallocates, and deallocates memory.
The callbacks are called by the user thread that invokes lbm_ssrc_create() for create, and by lbm_ssrc_←delete() for delete. See lbm_mem_mgt_malloc_cb_func, lbm_mem_mgt_realloc_cb_func, lbm_mem_←mgt_free_cb_func.
See Smart Sources and Memory Management for restrictions.
See Smart Sources for more information about Smart Sources.
Scope:
source
Type:
lbm_mem_mgt_callbacks_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
232
Smart Source Options
26.1.2
smart_src_enable_spectrum_channel (source)
This option enables spectrum channel use with Smart Sources.
See Smart Sources and Spectrum for restrictions.
See Smart Sources for more information about Smart Sources.
Scope:
source
Type:
int
When
Set:
26.1.3
to
Can only be set during object initialization.
Value
Description
1
The source will allocate spectrum channel resources.
0
The source will not allocate spectrum channel resources. Default for all.
smart_src_max_message_length (source)
The number of bytes allocated for application messages to each Smart Source buffer.
Smart Source buffers are pre-allocated when the source is created. The final allocation size is the value
specified for this option, plus the sizes required for internal headers, plus a possible padding value intended to
ensure that the final internal buffer allocation is a power of 2. Because of these additions, the actual amount of
memory allocated can be over twice as much as requested.
There are three types of buffers sized by smart_src_max_message_length: user buffers, retention buffers (for
late join), and transmission window buffers (for transport retransmissions). User buffers and retention buffers
are created by lbm_ssrc_create(), and are deleted by lbm_ssrc_delete(). Transmission window buffers are
created only when the first Smart Source on a transport session is created, and are deleted when the last
Smart Source on a transport session is deleted.
Different numbers of buffers can be allocated for each buffer type. See smart_src_user_buffer_count (source)
for user buffers, transport_lbtrm_smart_src_transmission_window_buffer_count (source) and transport_lbtru←_smart_src_transmission_window_buffer_count (source) for transmission window buffers, and smart_src_←retention_buffer_count (source) for retention buffers.
26.1 Reference
233
The smart_src_max_message_length option affects both the transport session underlying the source and also
the source itself. The transport session uses the value from the first source created on the session when it
allocates the transmission window; subsequent sources created on the same session do not affect the transmission window. However, the sizes of the user buffers and retention buffers are specific to each Smart Source
on a session.
The default value was specifically chosen so that for a Smart Source with no optional headers (no message
properties, no spectrum channel, etc.), the total memory consumed per buffer, including internal headers, is
512 bytes.
Note that unlike most UM configuration options, the default value for smart_src_max_message_length is likely
to change with new versions of UM. This is because the addition of new capabilities to the Smart Sources
feature often requires the addition of internal headers to the message buffer, thus reducing the available user
space while staying within the 512-byte total buffer size default target. To assist application designers who want
to use the default, the constant SSRC_DEFAULT_MAX_MSG_LEN is defined in lbm.h.
Also note that the application designer can avoid that uncertainty by simply defining smart_src_max_message←_length to be the maximum size of his messages, and allowing the final allocation size of the message buffer
to vary by UM version. This is the recommended approach.
See Smart Sources for more information about Smart Sources.
26.1.4
Scope:
source
Type:
int
Units:
bytes
Default
value:
When
Set:
SSRC_DEFAULT_MAX_MSG_LEN (368)
to
Can only be set during object initialization.
smart_src_message_property_int_count (source)
The maximum number of 32-bit integer message properties that can be set on messages for a particular Smart
Source.
See Smart Sources and Message Properties for restrictions.
See Smart Sources for more information about Smart Sources.
Scope:
source
Type:
int
234
Smart Source Options
26.1.5
Units:
32-bit integer properties
Default
value:
When
Set:
0
to
Can only be set during object initialization.
smart_src_retention_buffer_count (source)
The number of Smart Source buffers that are allocated for Late Join and other topic level retransmission features
such as Off Transport Recovery.
Once created, the application cannot change the number of buffers. Also, the number of buffers should be a
power of 2. If a value is supplied that is not a power of 2, the value is increased to the next larger power of two
and a warning message is logged.
The buffer size is determined by smart_src_max_message_length (source), see that option description for more
details.
The normal Late Join options "retransmit_retention_∗" do not apply to Smart Sources.
See Smart Sources for more information about Smart Sources.
26.1.6
Scope:
source
Type:
int
Units:
Default
value:
When
Set:
buffers
1024
to
Can only be set during object initialization.
smart_src_user_buffer_count (source)
The number of Smart Source buffers that are allocated when the source is created.
Once created, the application cannot change the number of buffers. Also, the number of buffers should be a
power of 2. If a value is supplied that is not a power of 2, the value is increased to the next larger power of two
and a warning message is logged.
26.1 Reference
235
The buffer is sized by the smart_src_max_message_length (source) option.
See Smart Sources for more information about Smart Sources.
26.1.7
Scope:
source
Type:
int
Units:
Default
value:
When
Set:
buffers
32
to
Can only be set during object initialization.
transport_lbtrm_smart_src_transmission_window_buffer_count (source)
The number of Smart Source buffers allocated for transport-level retransmissions.
Once created, the application cannot change the number of buffers. Also, the number of buffers should be a
power of 2. If a value is supplied that is not a power of 2, the value is increased to the next larger power of two
and a warning message is logged.
This option affects the transport session underlying the source rather than the source itself. The transport
session uses the value from the first source created on the session and ignores subsequent sources.
The option smart_src_max_message_length (source) is used to size the buffers (see that option description for
more details). This means that the first Smart Source created on the session defines the maximum possible
size of user messages for all Smart Sources on the transport session. It is not legal to create a subsequent
Smart Source on the same transport session with a larger max message size, although smaller values are
permissible.
The normal LBT-RM transmission window options "transport_lbtrm_transmission_window_∗" do not apply to
Smart Sources.
See Smart Sources for more information about Smart Sources.
Scope:
source
Type:
int
Units:
Default
value:
When
Set:
buffers
16384 (16K)
to
Can only be set during object initialization.
236
Smart Source Options
26.1.8
transport_lbtru_smart_src_transmission_window_buffer_count (source)
The number of Smart Source buffers allocated for transport-level retransmissions.
Once created, the application cannot change the number of buffers. Also, the number of buffers should be a
power of 2. If a value is supplied that is not a power of 2, the value is increased to the next larger power of two
and a warning message is logged.
This option affects the transport session underlying the source rather than the source itself. The transport
session uses the value from the first source created on the session and ignores subsequent sources.
The option smart_src_max_message_length (source) is used to size the buffers (see that option description for
more details). This means that the first Smart Source created on the session defines the maximum possible
size of user messages for all Smart Sources on the transport session. It is not legal to create a subsequent
Smart Source on the same transport session with a larger max message size, although smaller values are
permissible.
The normal LBT-RU transmission window options "transport_lbtru_transmission_window_∗" do not apply to
Smart Sources.
Note
If transport_source_side_filtering_behavior (source) is enabled, each connecting receiver will be assigned
its own transmission window buffer. As the number of connecting receivers increases, the total memory
consumption of the source can become very large.
See Smart Sources for more information about Smart Sources.
Scope:
source
Type:
int
Units:
Default
value:
When
Set:
buffers
16384 (16K)
to
Can only be set during object initialization.
Chapter 27
Encrypted TCP Options
27.1
Reference
27.1.1
tls_certificate (context)
When TLS is enabled, this option specifies the path to a file containing an OpenSSL-compatible PEM-formatted
certificate that will be presented as the TLS server certificate when a TLS connection is established by a client.
See Encrypted TCP.
27.1.2
Scope:
context
Type:
string
Default
value:
When
Set:
Version:
NULL
to
Can only be set during object initialization.
This option was implemented in UM 6.9
tls_certificate_key (context)
When TLS is enabled, this option specifies the path to a file containing the private key associated with the
"server" certificate.
238
Encrypted TCP Options
The server certificate is specified by the tls_certificate (context) option. Note that this private key must be
protected from intruders. For that reason, when the certificate and private key files are generated, the private
key file is typically encrypted with a passphrase. The passphrase is supplied using the tls_certificate_key_←password (context) option.
27.1.3
Scope:
context
Type:
string
Default
value:
When
Set:
Version:
NULL
to
Can only be set during object initialization.
This option was implemented in UM 6.9
tls_certificate_key_password (context)
When TLS is enabled, this option specifies the passphrase needed to decrypt the server private key file.
The private key file is specified by the tls_certificate_key (context) option.
27.1.4
Scope:
context
Type:
string
Default
value:
When
Set:
Version:
NULL
to
Can only be set during object initialization.
This option was implemented in UM 6.9
tls_cipher_suites (context)
When TLS is enabled, this option defines the list of one or more (comma separated) names of cipher suites
that are acceptable to this context.
The names are in OpenSSL format (the names with dashes). If more than one name is supplied, they should
be in descending order of preference. When a remote context negotiates encrypted TCP, the two sides must
find a cipher suite in common, otherwise the connection will be canceled. The default is highly secure and is
recommended.
27.1 Reference
239
For information on valid cipher suite specifications, see Encrypted TCP.
27.1.5
Scope:
context
Type:
string
Default
value:
When
Set:
Version:
DHE-RSA-AES256-GCM-SHA384
to
Can only be set during object initialization.
This option was implemented in UM 6.9
tls_compression_negotiation_timeout (context)
The number of milliseconds allowed for TLS and/or compression handshake and negotiation.
This negotiation happens when the TCP connection is initiated. If the negotiation does not complete within this
amount of time, the connection is canceled. Note that in many cases, this will result in a retry a short time later.
If the timeout is caused by mismatched endpoints, it can result in unbounded flapping of the connection.
27.1.6
Scope:
context
Type:
int
Units:
Default
value:
When
Set:
Version:
milliseconds
5000
to
Can only be set during object initialization.
This option was implemented in UM 6.9
tls_trusted_certificates (context)
When TLS is enabled, this option specifies the path to a file containing one or more OpenSSL-compatible
PEM-formatted TLS client certificates and certificate authorities.
If this option is not supplied, the default behavior is to use the system-level trusted certificates and certificate
authorities (operating-system dependent). The TLS server uses these trusted certificates to verify the identity of
connecting clients. If a client connects and presents a certificate which is not in the server's trusted certificates
file, the connection will be canceled. Note that in many cases, this will result in a retry a short time later, which
can lead to unbounded flapping of the connection.
240
Encrypted TCP Options
27.1.7
Scope:
context
Type:
string
Default
value:
When
Set:
Version:
NULL
to
Can only be set during object initialization.
This option was implemented in UM 6.9
use_tls (context)
This option enables data encryption on all TCP links established within the context.
This includes but may not be limited to TCP transports, Late Join, and Request/Response.
Scope:
context
Type:
int
Default
value:
When
Set:
Version:
0
to
Can only be set during object initialization.
This option was implemented in UM 6.9
String value
Integer value
Description
"1"
1
All TCP data will be encrypted.
"0"
0
No encryption will be implemented. Default for all.
Chapter 28
Compressed TCP Options
28.1
Reference
28.1.1
compression (context)
This option enables compression and sets the desired data compression algorithm on all TCP links established
within the context.
This includes but may not be limited to TCP transports, Late Join, and Request/Response. Currently, only LZ4
lossless data compression is supported.
Scope:
context
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UM 6.9.
String value
Integer value
Description
"none"
LBM_CTX_ATTR_COMPRESSION_NONE
"lz4"
LBM_CTX_ATTR_COMPRESSION_LZ4
No compression will be implemented. Default for all.
All TCP data will be compressed using LZ4.
242
Compressed TCP Options
Chapter 29
Multicast Immediate Messaging Network
Options
The multicast address and port used for incoming and outgoing multicast immediate messages can be set with
mim_address (context) and mim_destination_port (context) options.
A context may use different multicast addresses and/or ports for incoming and outgoing messages by setting one
or more of:
• mim_incoming_address (context)
• mim_outgoing_address (context)
• mim_incoming_destination_port (context)
• mim_outgoing_destination_port (context)
In case of conflict, the most recently set option wins.
As with LBT-RM on multi-homed hosts, the interface UM uses for MIM follows the interface used with multicast topic
resolution. See resolver_multicast_interface (context).
Warning
The addresses and ports you configure for MIM traffic should not overlap with any addresses or ports - or
address and port ranges - configured for LBT-RM transports or Topic Resolution traffic. For example, do not
use the same multicast address for both Topic Resolution (resolver_multicast_address (context)) and MIM
(mim_address (context)). Use different addresses and ports for all multicast address options and port options.
See also Multicast Immediate Messaging for general information on MIM.
29.1
Reference
29.1.1
mim_address (context)
Convenience option to set both the incoming and outgoing multicast addresses for multicast immediate messages.
244
Multicast Immediate Messaging Network Options
See mim_outgoing_address (context) and mim_incoming_address (context) for their respective default values.
See Multicast Immediate Messaging for general information about MIM.
29.1.2
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
n.a.
to
Can only be set during object initialization.
mim_destination_port (context)
The UDP destination port that multicast immediate messages are sent to and received from.
See Port Assignments for more information about configuring ports. See Multicast Immediate Messaging for
general information about MIM.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14401
When
Set:
29.1.3
Network
to
Can only be set during object initialization.
mim_incoming_address (context)
The IP multicast address (or domain name of the multicast address) that multicast immediate messages are
received from.
The value 0.0.0.0 disables reception of multicast immediate messages. See Multicast Immediate Messaging
for general information about MIM.
Scope:
context
Type:
struct in_addr
29.1 Reference
245
Default
value:
When
Set:
29.1.4
0.0.0.0
to
Can only be set during object initialization.
mim_incoming_destination_port (context)
The UDP destination port that multicast immediate messages are received from.
See Port Assignments for more information about configuring ports. See Multicast Immediate Messaging for
general information about MIM.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14401
When
Set:
29.1.5
Network
to
Can only be set during object initialization.
mim_outgoing_address (context)
The IP multicast address (or domain name of the multicast address) that multicast immediate messages are
sent to.
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
224.10.10.21
to
Can only be set during object initialization.
246
Multicast Immediate Messaging Network Options
29.1.6
mim_outgoing_destination_port (context)
The UDP destination port that multicast immediate messages are sent to.
See Port Assignments for more information about configuring ports. See Multicast Immediate Messaging for
general information about MIM.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14401
When
Set:
Network
to
Can only be set during object initialization.
Chapter 30
Multicast Immediate Messaging Reliability
Options
For every MIM reliability option, there is a corresponding LBT-RM reliability option. For more information on how
MIM reliability options interact and for illustrations, see Transport LBT-RM Reliability Options.
See also Multicast Immediate Messaging for general information on MIM.
30.1
Reference
30.1.1
mim_ignore_interval (context)
The interval to ignore NAKs after a retransmission is sent.
For multicast immediate message senders only. Similar to transport_lbtrm_ignore_interval (source).
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
248
Multicast Immediate Messaging Reliability Options
30.1.2
mim_nak_backoff_interval (context)
For LBT-RM transport sessions only. The maximum interval between transmissions of a single NAK.
For multicast immediate message receivers only. Similar to transport_lbtrm_nak_backoff_interval (receiver).
See Multicast Immediate Messaging for general information about MIM.
30.1.3
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
mim_nak_generation_interval (context)
The maximum time that a piece of data may be outstanding before the data is unrecoverably lost.
For multicast immediate message receivers only. Similar to transport_lbtrm_nak_generation_interval (receiver).
See Multicast Immediate Messaging for general information about MIM.
30.1.4
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
mim_nak_initial_backoff_interval (context)
For LBT-RM transport sessions only. The interval between loss detection and transmission of the first NAK.
30.1 Reference
249
For multicast immediate message receivers only. Similar to transport_lbtrm_nak_initial_backoff_interval (receiver).
See Multicast Immediate Messaging for general information about MIM.
30.1.5
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
50 (0.05 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
mim_nak_suppress_interval (context)
The maximum interval to suppress sending NAKs after an NCF or a NAK from another receiver.
For multicast immediate message receivers only. Similar to transport_lbtrm_nak_suppress_interval (receiver).
See Multicast Immediate Messaging for general information about MIM.
30.1.6
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
mim_send_naks (context)
This flag indicates whether LBT-RM should send negative acknowledgements (NAKs) for missing packets or
not.
250
Multicast Immediate Messaging Reliability Options
For multicast immediate message receivers only. Similar to transport_lbtrm_send_naks (receiver).
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
int
When
Set:
30.1.7
to
Can only be set during object initialization.
Value
Description
1
NAKs are sent for missing packets to request retransmission. Default for all.
0
Do not send NAKs for missing packets.
mim_transmission_window_limit (context)
Caps the total amount of memory that a transmission window uses, which includes data and overhead.
For multicast immediate message senders only.
(source).
Similar to transport_lbtrm_transmission_window_limit
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
size_t
Units:
bytes
Default
value:
When
Set:
0 (zero)
to
Can only be set during object initialization.
30.1 Reference
30.1.8
251
mim_transmission_window_size (context)
The maximum amount of buffered payload data, excluding UM headers, that the LBT-RM source is allowed to
retain for retransmissions.
For multicast immediate message senders only. Similar to transport_lbtrm_transmission_window_size (source).
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
size_t
Units:
bytes
Default
value:
When
Set:
25165824 (24 MB)
to
Can only be set during object initialization.
252
Multicast Immediate Messaging Reliability Options
Chapter 31
Multicast Immediate Messaging Operation
Options
For many MIM operation options, there is a corresponding LBT-RM operation option. For more information on how
MIM operation options interact and for illustrations, see Transport LBT-RM Operation Options.
Note that the LBT-RM rate controller also governs MIM transmission rates. Hence there is no separate option for
setting MIM transmission rate.
See also Multicast Immediate Messaging for general information on MIM.
31.1
Reference
31.1.1
immediate_message_receiver_function (context)
Callback function (and associated event queue and client data pointer) called when a topicless immediate
message is received.
A value of NULL (the default) disables this feature.
Alternatively, the API lbm_context_rcv_immediate_msgs() can be used.
See Immediate Messaging for general information on immediate messages.
Scope:
context
Type:
lbm_context_rcv_immediate_msgs_func←_t
NULL
Default
value:
When
to
Set:
Config File:
Can only be set during object initialization.
Cannot be set from an UM configuration file.
254
Multicast Immediate Messaging Operation Options
31.1.2
immediate_message_topic_receiver_function (context)
Callback function (and associated event queue and client data pointer) that is called when an immediate message is received for a topic for which there is no receiver.
A value of NULL (the default) disables this feature.
Alternatively, the API lbm_context_rcv_immediate_topic_msgs() can be used.
See Immediate Messaging for general information on immediate messages.
Scope:
context
Type:
lbm_context_rcv_immediate_msgs_func←_t
NULL
Default
value:
When
to
Set:
Config File:
31.1.3
Can only be set during object initialization.
Cannot be set from an UM configuration file.
mim_activity_timeout (context)
The maximum time that an LBT-RM session may be quiescent before it is deleted and an EOS event is delivered
for all topics using this transport session.
For multicast immediate message receivers only. Similar to transport_lbtrm_activity_timeout (receiver). However, multicast immediate message channels do not deliver an EOS indication.
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
milliseconds
60000 (60 seconds)
31.1 Reference
255
When
Set:
31.1.4
to
Can only be set during object initialization.
mim_delivery_control_activity_check_interval (context)
The interval between activity checks of a Multicast Immediate Messaging delivery controller.
Multiple MIM delivery controllers may exist to accommodate multiple messages from a single MIM sender received across more than one UM Router (DRO). These multiple delivery controllers allow for duplicate message
detection.
31.1.5
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
5000 (5 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0.
mim_delivery_control_activity_timeout (context)
The maximum time that a Multicast Immediate Messaging delivery controller may be quiescent before it is
deleted.
MIM delivery controllers may be created to accommodate multiple messages from a single MIM sender received
across more than one UM Router (DRO). These multiple delivery controllers allow for duplicate message detection.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
60000 (60 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0.
256
Multicast Immediate Messaging Operation Options
31.1.6
mim_delivery_control_order_tablesz (context)
For multicast immediate messages with ordered delivery, this controls the size of the hash table used to hold
data.
See Multicast Immediate Messaging for general information about MIM.
31.1.7
Scope:
context
Type:
size_t
Units:
Default
value:
When
Set:
table entries
1031
to
Can only be set during object initialization.
mim_implicit_batching_interval (context)
The maximum timeout between when the first message of an implicitly batched immediate message is queued
until the batch is sent. A message will not stay in the queue longer than this value before being sent in the worst
case.
See Implicit Batching for details. See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
31.1 Reference
31.1.8
257
mim_implicit_batching_minimum_length (context)
The minimum length of an implicitly batched multicast immediate message. When the total length of the implicitly batched messages reaches or exceeds this value, the batch is sent.
See Implicit Batching for details. See Multicast Immediate Messaging for general information about MIM.
31.1.9
Scope:
context
Type:
size_t
Units:
bytes
Default
value:
When
Set:
2048 (8192 for Microsoft Windows)
to
Can only be set during object initialization.
mim_ordered_delivery (context)
For multicast immediate messages only. Indicates whether or not the MIM source should have its data delivered
in order.
The default value also guarantees fragmentation and reassembly of large messages. Changing this option
from the default value results in large messages being delivered as individual fragments of less than 8K each,
requiring the application to reassemble them. See also Ordered Delivery for more information about large
message fragmentation and reassembly.
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
int
When
Set:
to
Can only be set during object initialization.
Value
Description
1
0
Indicates the source should have its data delivered in order. Default for all.
The source should have its data delivered as soon as possible and may come in out of order.
258
Multicast Immediate Messaging Operation Options
31.1.10
mim_sm_maximum_interval (context)
The maximum interval between LBT-RM session messages.
For multicast immediate message senders only. Similar to transport_lbtrm_sm_maximum_interval (source).
See Multicast Immediate Messaging for general information about MIM.
31.1.11
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
mim_sm_minimum_interval (context)
The minimum interval between LBT-RM session messages.
For multicast immediate message senders only. Similar to transport_lbtrm_sm_minimum_interval (source).
See Unicast Immediate Messaging for more information.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
31.1 Reference
31.1.12
259
mim_sqn_window_increment (context)
Determines the increment by which the sequence number window is moved when detecting the receipt of
duplicate multicast immediate messages.
For multicast immediate message receivers only.
Must be a multiple of 8 and an even divisor of mim_sqn_window_size (context).
See Multicast Immediate Messaging for general information about MIM.
31.1.13
Scope:
context
Type:
lbm_ulong_t
Units:
messages
Default
value:
When
Set:
Version:
8192
to
Can only be set during object initialization.
This option was implemented in LBM 4.2.8/UME 3.2.8/UMQ 2.1.8
mim_sqn_window_size (context)
For multicast immediate message receivers only. Determines the window size used to detect the receipt of
duplicate multicast immediate messages. Must be a multiple of 8.
See Multicast Immediate Messaging for general information about MIM.
Scope:
context
Type:
lbm_ulong_t
Units:
messages
Default
value:
When
Set:
Version:
16384
to
Can only be set during object initialization.
This option was implemented in LBM 4.2.8/UME 3.2.8/UMQ 2.1.8
260
Multicast Immediate Messaging Operation Options
31.1.14
mim_src_deletion_timeout (context)
The timeout after a multicast immediate message is sent before the internal source is deleted and cleaned up.
See Multicast Immediate Messaging for general information about MIM.
31.1.15
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
30000 (30 seconds)
to
Can only be set during object initialization.
mim_tgsz (context)
The transmission group size used for this Topic when LBT-RM is used.
For multicast immediate message senders only. Similar to transport_lbtrm_tgsz (source).
See Unicast Immediate Messaging for more information.
Scope:
context
Type:
lbm_uint16_t
Units:
packets
Default
value:
When
Set:
8
to
Can only be set during object initialization.
31.1 Reference
31.1.16
261
mim_unrecoverable_loss_function (context)
Callback function (and associated client data pointer) that is called when a MIM receiver has unrecoverable
loss.
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:
context
Type:
lbm_mim_unrecloss_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
262
Multicast Immediate Messaging Operation Options
Chapter 32
Late Join Options
Late Join allows sources to save a predefined amount of their messaging traffic for late-joining receivers. Sources
set the configuration options that determine whether they use Late Join or not, and receivers set options that
determine whether they will participate in Late Join recovery if sources use Late Join.
UMP's persistent store is built on Late Join technology. In the Estimating Recovery Time discussion below, the
terms Late Join buffers and UMP store are roughly equivalent.
For more, review Late Join in the Ultra Messaging Concepts Guide, especially Configuring Late Join for Large
Numbers of Messages.
32.1
Estimating Recovery Time
Late Join message recovery time is a function of how much data must be recovered and how fast messages are
retransmitted. To estimate Late Join recovery time R in minutes, use the formula:
R = D / ( 1 - ( txrate / rxrate ) )
where:
D is the downtime (in minutes) across all receivers
txrate is the average source transmission rate of normal (live stream) messages during recovery (in kmsgs/sec).
rxrate is the average source retransmission rate from source-side Late Join buffers during recovery (in kmsgs/sec). This rate needs to be greater than txrate.
For example, consider the following scenario:
D = 10 minutes
txrate = 10k messages / second
rxrate = 25k messages / second
Plugging these values into the formula gives an estimated recovery time in minutes:
R = 10 / ( 1 - ( 10 / 25 ) )
or 16.67 minutes. Note that this formula assumes the following:
• Retransmit rate(rxrate) is as linear as possible with use of option response_tcp_nodelay (context) to 1.
• Transmit rate (txrate) from all relevant sources is fairly constant and equal
264
Late Join Options
• Retransmit rate (rxrate) from Late Join buffers is fairly constant and equal, and should be measured in a
live test, if possible. You can adjust the recovery rate with two Late Join configuration options: retransmit_←request_outstanding_maximum (receiver) and retransmit_request_interval (receiver).
32.2
Reference
32.2.1
late_join (source)
Configure the source to enable both Late Join and Off-Transport Recovery operation for receivers.
See Using Late Join and Off-Transport Recovery (OTR).
Scope:
source
Type:
int
When
Set:
32.2.2
to
Can only be set during object initialization.
Value
Description
1
Enable source for Late Join and OTR. (Forced on for Persistence.)
0
Disable source for Late Join and OTR. Default for all.
late_join_info_request_interval (receiver)
The interval at which the receiver requests a Late Join Information Record (LJI) from the source.
Controlling these requests helps reduce receiver start-up traffic on your network.
See Late Join.
32.2 Reference
32.2.3
265
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
late_join_info_request_maximum (receiver)
The maximum number of requests the receiver issues for a Late Join Information Record (LJI) from the source.
If the receiver has not received an LJI after this number of requests, it stops requesting.
32.2.4
Scope:
receiver
Type:
lbm_ulong_t
Default
value:
When
Set:
Version:
60
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
retransmit_initial_sequence_number_request (receiver)
When a late-joining receiver detects (from the topic advertisement) that a source is enabled for Late Join but
has sent no messages, this flag option lets the receiver request an initial sequence number from a source.
Sources respond with a TSNI.
Scope:
receiver
Type:
int
Default
value:
When
Set:
Version:
1
to
Can only be set during object initialization.
This option was implemented in LBM 4.2.
266
Late Join Options
Value
Description
1
The receiver requests an initial sequence number from Late Join enabled sources that have not
sent any messages. Default for all.
0
The receiver does not request an initial sequence number.
32.2.5
retransmit_message_caching_proximity (receiver)
This option determines how a receiver handles new messages that are being published while the receiver is in
the process of recovering older messages through the retransmit request mechanism.
A receiver has the ability to cache new messages during the recovery process in order to facilitate a smooth
transition from recovery to live stream. This option value determines how close (proximate) a newly received
message sequence number must be to the latest retransmitted sequence number for the receiver to cache
it. New messages that arrive while the receiver is not within proximity will be discarded, and the receiver will
attempt to recover those messages later via the retransmit request mechanism.
An option value between 0 and 0x7FFFFFFE (2,147,483,646) enables proximity caching, with larger values
allowing caching to begin earlier during recovery. Values 0x7FFFFFFF and above disable proximity caching.
This value has meaning for only receivers using ordered delivery of data.
See Configuring Late Join for Large Numbers of Messages for additional information.
Scope:
receiver
Type:
lbm_ulong_t
Units:
messages
Default
value:
When
Set:
Version:
5000 (was 0xFFFFFFFF = 4,294,967,295 in versions prior to 6.8)
to
Can only be set during object initialization.
This option was implemented in LBM 3.3.2/UME 2.0.
32.2 Reference
32.2.6
267
retransmit_request_interval (receiver)
The interval between retransmission request messages to the source.
See Configuring Late Join for Large Numbers of Messages for additional information.
32.2.7
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
retransmit_request_maximum (receiver)
The maximum number of messages to request, counting backward from the current latest message, when
late-joining a topic.
Due to network timing factors, UM may transmit an additional message. For example, a value of 5 sends 5 or
possibly 6 retransmit messages to the new receiver. (Hence, you cannot request and be guaranteed to receive
only 1 last message–you may get 2.) A value of 0 indicates no maximum.
32.2.8
Scope:
receiver
Type:
lbm_ulong_t
Units:
messages
Default
value:
When
Set:
0
to
Can only be set during object initialization.
retransmit_request_message_timeout (receiver)
The maximum time from when a receiver first sends a retransmission request to when the receiver gives up on
receiving the retransmitted message and reports loss.
268
Late Join Options
See Configuring Late Join for Large Numbers of Messages for additional information.
32.2.9
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 6.0
retransmit_request_outstanding_maximum (receiver)
The maximum number of messages to request and to remain active (pending) at a single time.
A value of 0 indicates no maximum.
See Configuring Late Join for Large Numbers of Messages for additional information.
32.2.10
Scope:
receiver
Type:
lbm_ulong_t
Units:
messages
Default
value:
When
Set:
10
to
Can only be set during object initialization.
retransmit_retention_size_limit (source)
Sets a maximum limit on the size of the source's retransmit retention buffer when using a UME store.
With UME, stability and delivery confirmation events can delay the deletion of retained messages, which can
increase the size of the buffer above the retransmit_retention_size_threshold (source). Hence, this option
provides a hard size limit. UM sets a minimum value for this option of 8K for UDP and 64K for TCP, and issues
a log warning if you set a value less than the minimum.
32.2 Reference
269
With Smart Sources, this option is ignored. Retention buffers are preallocated.
32.2.11
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
25165824 (24 MB)
to
Can only be set during object initialization.
retransmit_retention_size_threshold (source)
Specifies the minimum size of the retained message buffer before UM can delete messages.
The buffer must reach this size before UM can delete any messages older than retransmit_retention_age_←threshold (source).
For UMP, these options combined with retransmit_retention_size_limit (source) affect the retention buffer size.
A value of 0 sets the size threshold to be always triggered, in which case deletion is determined by other
threshold criteria.
With Smart Sources, this option is ignored. Retention buffers are preallocated and are never deleted.
32.2.12
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
0 (threshold always triggered)
to
Can only be set during object initialization.
use_late_join (receiver)
Flag indicating if the receiver should participate in a late join operation or not.
270
Late Join Options
See Late Join for more information.
Scope:
receiver
int
Type:
When
Set:
to
Can only be set during object initialization.
Value
Description
1
The receiver will participate in using late join if requested to by the source. Default for all.
0
The receiver will not participate in using late join even if requested to by the source.
Chapter 33
Off-Transport Recovery Options
See also Off-Transport Recovery (OTR) for general information on OTR.
33.1
Reference
33.1.1
otr_message_caching_threshold (receiver)
This option sets the maximum number of messages a receiver can buffer. When the number of cached messages hits this threshold, Ultra Messaging drops and does not cache new streamed messages. Dropped
messages can be requested later as retransmissions.
This option applies for only receivers using sequence-number ordered delivery of data.
Scope:
receiver
Type:
lbm_ulong_t
Units:
messages
Default
value:
When
Set:
Version:
10000
to
Can only be set during object initialization.
This option was implemented in UM 6.0
272
Off-Transport Recovery Options
33.1.2
otr_request_initial_delay (receiver)
The length of time a receiver waits before initiating OTR lost-message requests.
See Off-Transport Recovery (OTR).
33.1.3
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
2000 (2 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 5.3
otr_request_log_alert_cooldown (receiver)
Each OTR request generates a log message. The first request's log message is a WARNING-level log message, and subsequent requests that quickly follow generate INFO-level log messages. After a time interval
defined by this option, the next request leading a new burst of requests again generates a WARNING-level log
message.
See Off-Transport Recovery (OTR).
33.1.4
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
300 (5 minutes)
to
Can only be set during object initialization.
This option was implemented in UM 5.3
otr_request_maximum_interval (receiver)
The maximum time interval between a receiver's OTR lost-message requests.
33.1 Reference
273
After the receiver initiates OTR and is waiting to receive the retransmission, the initial interval (set by otr←_request_minimum_interval (receiver)) doubles in length for each request until it reaches this option's value,
then continues at this interval (until timeout or UM recovers messages).
Note
When using TCP Request/Response, this value must be shorter than response_tcp_deletion_timeout (context).
See Off-Transport Recovery (OTR).
33.1.5
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 5.3
otr_request_message_timeout (receiver)
The maximum time from when a receiver first sends an OTR lost-message request to when the receiver gives
up on receiving the retransmitted message and reports loss.
See Off-Transport Recovery (OTR).
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
60000 (60 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 6.0
274
Off-Transport Recovery Options
33.1.6
otr_request_minimum_interval (receiver)
The initial time interval between a receiver's OTR lost-message requests.
While the receiver is waiting to receive the retransmission, the interval doubles in length for each request until
it reaches the maximum interval set by otr_request_maximum_interval (receiver).
See Off-Transport Recovery (OTR).
33.1.7
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in UM 5.2
otr_request_outstanding_maximum (receiver)
The maximum number of OTR lost-message requests outstanding at any given time. Each message specifies
an individual lost message. A value of 0 indicates no maximum.
See Off-Transport Recovery (OTR).
Scope:
receiver
Type:
lbm_ulong_t
Units:
messages
Default
value:
When
Set:
Version:
200
to
Can only be set during object initialization.
This option was implemented in UM 5.2
33.1 Reference
33.1.8
275
use_otr (receiver)
Flag indicating if the receiver can use OTR or not.
See Off-Transport Recovery (OTR).
Scope:
receiver
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UM 5.2
String value
Integer value
Description
"0"
0
The receiver is not enabled to use OTR to recover lost messages.
"1"
1
The receiver is enabled to use OTR to recover lost messages.
"2"
2
If the receiver is a persistent receiver, the receiver is enabled to use OTR
to recover lost messages. Default for all.
276
Off-Transport Recovery Options
Chapter 34
Unicast Immediate Messaging Network
Options
In early versions of UM, the Unicast Immediate Messaging (UIM) feature was primarily used to support the
Request/Response feature. Therefore, the configuration options related to UIMs have names that start with "request" and "response". However, as UM has evolved, the UIM feature has come to be used by a great many UM
features, such as Late Join, Persistence, and Queuing.
To maintain backwards compatibility, the old names of the configuration options have been retained. The reader
must simply be aware that the "request_..." and "response_..." options affect more than just the request/response
feature.
See Unicast Immediate Messaging for general information on UIM. See also Unicast Immediate Messaging Operation Options for operationally-oriented options.
34.1
Reference
34.1.1
request_tcp_bind_request_port (context)
Allows you to turn off UIM port binding (also known as "request port binding").
Setting this option to 0 prevents sockets from being bound to the UIM port. Turning off UIM port binding also
turns off several UM features such as: Request/Response Model, Using Late Join, Off-Transport Recovery
(OTR), the reception of Unicast Immediate Messages, persistence, brokered queuing, and ULB.
See Unicast Immediate Messaging for general information on UIM.
Scope:
context
Type:
int
Default
value:
1
278
Unicast Immediate Messaging Network Options
When
Set:
Version:
34.1.2
to
Can only be set during object initialization.
This option was implemented in LBM 3.3.7/UME 2.0.5.
Value
Description
1
Set UIM port binding. Default for all.
0
Turn off UIM port binding.
request_tcp_interface (context)
Specifies the network interface over which UM accepts TCP connections for reception of UIM messages.
You can specify a full IP address of interface, or just the network part (see Specifying Interfaces for details).
Default is set to default_interface (context), if specified. Otherwise, it is set to INADDR_ANY, meaning that it
will not bind to a specific interface. You can also modify the default by setting the option to 0.0.0.0/0 which
produces the same result.
See Unicast Immediate Messaging for general information on UIM.
34.1.3
Scope:
context
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
request_tcp_port (context)
Port number used for UIM port (also known as "request port").
A context binds to and listens on the UIM port to be able to accept TCP connections for reception of Unicast
Immediate Messages (UIMs). The port is either explicitly specified by request_tcp_port (context), or is selected
from the range: [request_tcp_port_low (context), request_tcp_port_high (context)].
34.1 Reference
279
If request_tcp_port (context) is 0, the context binds to the first open port within the range of [request_tcp_port←_low (context), request_tcp_port_high (context)]. If nonzero, the specific port number is used instead.
See Unicast Immediate Messaging for general information on UIM. See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
0 (use open port)
When
Set:
34.1.4
Network
to
Can only be set during object initialization.
request_tcp_port_high (context)
High port number to use for UIM port (also known as "request port").
A context binds to and listens on the UIM port to be able to accept TCP connections for reception of Unicast
Immediate Messages (UIMs). The port is either explicitly specified by request_tcp_port (context), or is selected
from the range: [request_tcp_port_low (context), request_tcp_port_high (context)].
See Unicast Immediate Messaging for more information about UIM. See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14395
When
Set:
34.1.5
Host
to
Can only be set during object initialization.
request_tcp_port_low (context)
Low port number to use for UIM port (also known as "request port").
280
Unicast Immediate Messaging Network Options
A context binds to and listens on the UIM port to be able to accept TCP connections for reception of Unicast
Immediate Messages (UIMs). The port is either explicitly specified by request_tcp_port (context), or is selected
from the range: [request_tcp_port_low (context), request_tcp_port_high (context)].
See Unicast Immediate Messaging for general information on UIM. See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
14391
When
Set:
Host
to
Can only be set during object initialization.
Chapter 35
Unicast Immediate Messaging Operation
Options
In early versions of UM, the Unicast Immediate Messaging (UIM) feature was primarily used to support the
Request/Response feature. Therefore, the configuration options related to UIMs have names that start with "request" and "response". However, as UM has evolved, the UIM feature has come to be used by a great many UM
features, such as Late Join, Persistence, and Queuing.
To maintain backwards compatibility, the old names of the configuration options have been retained. The reader
must simply be aware that the "request_..." and "response_..." options affect more than just the request/response
feature.
See Unicast Immediate Messaging for general information on UIM. See also Unicast Immediate Messaging Network Options for network-oriented options.
35.1
Reference
35.1.1
request_tcp_exclusiveaddr (context)
Controls whether the context sets SO_EXCLUSIVEADDRUSE before it binds to the UIM port (also known as
the "Request Port").
Applicable only to Windows.
The default setting in Windows allows multiple binds to the same port. By default, UM will set SO_EXCLUSI←VEADDRUSE to minimize port sharing. Refer to Microsoft's web site for more information on SO_EXCLUSI←VEADDRUSE.
See Unicast Immediate Messaging for general information on UIM.
282
Unicast Immediate Messaging Operation Options
Scope:
context
int
Type:
When
Set:
35.1.2
to
Can only be set during object initialization.
Value
Description
1
0
Set SO_EXCLUSIVEADDRUSE. Default for Windows.
Do not set SO_EXCLUSIVEADDRUSE.
request_tcp_listen_backlog (context)
The backlog used in the TCP listen() call to set the queue length for incoming UIM connections (also known as
"request connections" or "response connections").
See Unicast Immediate Messaging for general information on UIM.
35.1.3
Scope:
context
Type:
int
Default
value:
When
Set:
5
to
Can only be set during object initialization.
request_tcp_reuseaddr (context)
Controls whether the context sets SO_REUSEADDR before it binds to the UIM port (also known as the "←Request Port").
See Unicast Immediate Messaging for general information on UIM.
35.1 Reference
283
Warning
This option is not recommended for Microsoft Windows users because the SO_REUSEADDR socket option in
Windows allows a socket to forcibly bind to a port in use by another socket. Multiple sockets using the same
port results in indeterminate behavior.
Scope:
context
Type:
int
When
Set:
35.1.4
to
Can only be set during object initialization.
Value
Description
1
Set SO_REUSEADDR.
0
Do not set SO_REUSEADDR. Default for all.
response_session_maximum_buffer (context)
Maximum number of bytes of application data which can be queued for a UIM connection.
When the application sends a UIM message via a UIM API function, UM may not be able to immediately send
the message. For example, if many messages are bring sent but the receiver is slow, TCP flow control may
prevent messages from being sent. UM will queue outgoing UIM messages that cannot be sent immediately. If
that queue fills, then the UIM send API will either block, or will return -1 with the error code LBM_EWOULD_←BLOCK.
This queue is shared across all API methods of sending UIMs, including lbm_unicast_immediate_message(),
lbm_send_response(), etc.
See Unicast Immediate Messaging for general information on UIM.
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
65536
to
Can only be set during object initialization.
284
Unicast Immediate Messaging Operation Options
35.1.5
response_session_sender_socket_buffer (context)
Value used to set the SO_SNDBUF value of the UIM connection.
In some cases the OS will not allow all of this value to be used. A value of 0 instructs UM to use the OS defaults.
See Socket Buffer Sizes for platform-dependent information.
See Unicast Immediate Messaging for general information on UIM.
35.1.6
Scope:
context
Type:
lbm_ulong_t
Units:
bytes
Default
value:
When
Set:
0 (use TCP autotuning)
to
Can only be set during object initialization.
response_tcp_deletion_timeout (context)
Time period that the context waits before deleting a UIM connection.
UIM connections are dynamic, being created when needed and deleted when no longer needed. The purpose
of this timer is to keep the TCP connection up for a time after it is no longer needed, just in case it becomes
needed again. The exact semantics of this timer are described in Unicast Immediate Messaging.
NOTE: When using Off-Transport Recovery (OTR), this value must be longer than otr_request_maximum_←interval (receiver).
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
20,000 (20 seconds)
to
Can only be set during object initialization.
35.1 Reference
35.1.7
285
response_tcp_interface (context)
Specifies the network interface over which UM initiates outgoing TCP connections for UIMs.
You can specify the full IP address of interface, or just the network part (see Specifying Interfaces for details).
Default is set to default_interface (context), if specified. Otherwise, it is set to INADDR_ANY, meaning that it
will not bind to a specific interface. You can also modify the default by setting the option to 0.0.0.0/0 which
produces the same result.
See Unicast Immediate Messaging for general information on UIM.
35.1.8
Scope:
context
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
response_tcp_nodelay (context)
Controls whether the context sets TCP_NODELAY before it binds to the UIM port (also known as the "Request
Port").
Setting TCP_NODELAY disables Nagle's algorithm, which somewhat decreases the efficiency and throughput
of TCP, but decreases the latency of individual messages.
See Unicast Immediate Messaging for general information on UIM.
Scope:
context
Type:
int
When
Set:
to
Can only be set during object initialization.
286
Unicast Immediate Messaging Operation Options
Value
Description
1
TCP response sockets should set TCP_NODELAY (disable Nagle).
0
TCP response sockets should not set TCP_NODELAY (leave Nagle enabled). Default for all.
Chapter 36
Implicit Batching Options
36.1
Reference
36.1.1
implicit_batching_interval (source)
The maximum timeout between when the first message of an implicit batch is queued until the batch is sent. A
message will not stay in the queue longer than this value before being sent in the worst case.
See Implicit Batching for details.
36.1.2
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
May be set during operation.
implicit_batching_minimum_length (source)
The minimum length of an implicitly batched message. When the total length of the implicitly batched messages
reaches or exceeds this value, the batch is sent.
288
Implicit Batching Options
See Implicit Batching for details.
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
2048 (8192 for Microsoft Windows)
to
May be set during operation.
Chapter 37
Delivery Control Options
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.
290
Delivery Control Options
Note
if the source disables TSNIs, tail loss can go undetected unless and until another application is sent on that
topic.
37.1
Burst Loss
Normally, when the delivery controller detects a gap in topic sequence numbers of received message fragments,
it waits for a NAK generation interval (defaults to 10 seconds) before declaring the missing message fragments
unrecoverably lost. This wait time allows the underlying transport layer to attempt to retrieve the missing message
fragments.
The configuration options delivery_control_maximum_burst_loss (receiver) and delivery_control_maximum_burst←_loss (hfx) specify a size for a contiguous gap in topic sequence numbers beyond which the gap is defined to be a
"burst loss". When this happens, the delivery controller immediately declares the entire gap to be unrecoverably lost
and resets its loss-handling structures. Thus, even if the underlying transport layer is subsequently able to retrieve
some or all of the missing message fragments, the delivery controller will discard them (since they are already
declared unrecoverably lost).
The purpose of this is to prevent long delays for large loss events for which the chances of successful recover are
very small.
The image below illustrates this.
For burst loss, a single LBM_MSG_UNRECOVERABLE_LOSS_BURST event is delivered for the entire sequence
number gap. (Contrast this with simple (not burst) loss events, where a separate LBM_MSG_UNRECOVERABL←E_LOSS event will be delivered to the receiver for each lost sequence number.)
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 gapless message delivery is a
high priority, delivery_control_maximum_burst_loss should be set to a very large value.
37.2 Reference
291
There is a possibility of successfully-received messages being discarded when a burst loss is detected.
Let's say a minor loss event is followed by several successful message fragments. The delivery of those
successfully-received message fragments will be delayed in hopes that the underlying transport layer can
retrieve the missing data. However, if a burst loss is detected while the delivery controller is still waiting for
recovery, the pending messages will be deleted as the loss-handling structures are cleaned up.
37.2
Reference
37.2.1
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.
37.2.2
Scope:
receiver
Type:
size_t
Default
value:
When
Set:
10273
to
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.
A value of 0 turns this loss check off.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
milliseconds
0 (disabled)
292
Delivery Control Options
When
Set:
37.2.3
to
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".
See Burst Loss for a detailed explanation of burst loss and its semantics.
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.
37.2.4
Scope:
receiver
Type:
lbm_uint_t
Units:
number of messages (fragments)
Default
value:
When
Set:
1024
to
Can only be set during object initialization.
delivery_control_maximum_total_map_entries (context)
The maximum total buffered map entries (unrecoverable loss messages as well as data) that all topics can
buffer.
When this is exceeded, unrecoverable loss is signaled for data until the total buffered subsides. A value of 0
implies no maximum value setting and allows any amount required to be buffered.
If you use OTR with cache management (otr_message_caching), consider disabling this option (set to 0).
37.2 Reference
37.2.5
293
Scope:
context
Type:
size_t
Units:
map entries
Default
value:
When
Set:
200000
to
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, but might add latency in other cases.
If you enable this option, and you use an event queue that is in polling mode, using lbm_event_dispatch(evq,
LBM_EVENT_QUEUE_POLL), then rather than dispatching exactly one event per call to lbm_event_dispatch,
you may get multiple events dispatched with a single call.
Scope:
context
int
Type:
When
Set:
37.2.6
to
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 a Multicast Immediate Messaging (MIM) transport
session.
A value of 0 turns this loss check off.
294
Delivery Control Options
37.2.7
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
0 (disabled)
to
Can only be set during object initialization.
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
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"deliver"
LBM_RCV_TOPIC_ATTR_CHANNEL_B←EHAVIOR_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_B←EHAVIOR_DISCARD_MSGS
Messages sent without channel information
will be discarded.
37.2.8
source_notification_function (receiver)
Callback functions (and associated client data pointer) that are called when a receiver creates or deletes a
delivery controller associated with a source.
37.2 Reference
295
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.
37.2.9
Scope:
receiver
Type:
lbm_rcv_src_notification_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
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
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"deliver"
LBM_RCV_TOPIC_ATTR_CHANNEL_B←EHAVIOR_DELIVER_MSGS
"discard"
LBM_RCV_TOPIC_ATTR_CHANNEL_B←EHAVIOR_DISCARD_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.
Messages sent with channel information for
a channel not in the receiver's set of subscribed channels will be discarded.
296
Delivery Control Options
Chapter 38
Wildcard Receiver Options
38.1
Reference
38.1.1
pattern_type (wildcard_receiver)
The type of expression UM uses to compare wildcard receiver patterns to new topics seen in topic advertisements or responses to wildcard receiver queries.
As of UM Version 6.1, wildcard receivers must use PCRE expressions.
Scope:
wildcard_receiver
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"pcre"
LBM_WILDCARD_RCV_PATT←ERN_TYPE_PCRE
The pattern is a regular expression usable by PCRE (Perl Compatible Regular Expressions) library. Default for all.
"regex" Deprecated in UM Version 6.1.
LBM_WILDCARD_RCV_PATT←ERN_TYPE_REGEX
The pattern is a regular expression usable by POSIX Extended
Regular Expressions.
298
Wildcard Receiver Options
String value
Integer value
Description
"appcb" Deprecated in UM Version 6.1.
LBM_WILDCARD_RCV_PATT←ERN_TYPE_APP_CB
The wildcard receiver ignores the
pattern and calls an application
callback set by the pattern_←callback (wildcard_receiver) option.
38.1.2
receiver_create_callback (wildcard_receiver)
Callback function (and associated client data pointer) that is called when a receiver is about to be created for a
topic which matched a wildcard receiver pattern.
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.
The callback function should always return 0.
38.1.3
Scope:
wildcard_receiver
Type:
lbm_wildcard_rcv_create_func_t
Default
value:
When
to
Set:
Config File:
NULL
Version:
This option was implemented in LBM 3.4/UME 2.1.
Can only be set during object initialization.
Cannot be set from an UM configuration file.
receiver_delete_callback (wildcard_receiver)
Callback function (and associated client data pointer) that is called when a receiver is about to be deleted.
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.
The callback function should always return 0.
38.1 Reference
38.1.4
299
Scope:
wildcard_receiver
Type:
lbm_wildcard_rcv_delete_func_t
Default
value:
When
to
Set:
Config File:
NULL
Version:
This option was implemented in LBM 3.4/UME 2.1.
Can only be set during object initialization.
Cannot be set from an UM configuration file.
resolver_no_source_linger_timeout (wildcard_receiver)
This sets the linger timeout value before a topic with no sources is removed and cleaned up.
Since wildcard receivers set the resolution_no_source_notification_threshold (receiver) to 10, the linger timer
starts after the wildcard receiver sends 10 queries and subsequently receives a no-source notification.
38.1.5
Scope:
wildcard_receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
resolver_query_maximum_interval (wildcard_receiver)
The longest - and last - interval in wildcard receiver topic querying.
A value of 0 disables wildcard receiver topic querying.
See also Disabling Aspects of Topic Resolution.
Scope:
wildcard_receiver
Type:
lbm_ulong_t
Units:
milliseconds
300
Wildcard Receiver Options
Default
value:
When
Set:
Version:
38.1.6
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_query_minimum_duration (wildcard_receiver)
The duration of wildcard queries in wildcard receiver topic querying.
Only PCRE and regex pattern types can use wildcard queries. A value of 0 guarantees that wildcard receiver
topic querying never completes.
38.1.7
Scope:
wildcard_receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
60 (1 minute)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_query_minimum_interval (wildcard_receiver)
Interval between the first topic query sent upon creation of the wildcard receiver and the second query sent by
the receiver.
A value of 0 disables wildcard receiver topic querying. This option has an effective minimum of 30 ms. See
UDP-Based Resolver Operation Options.
See also Disabling Aspects of Topic Resolution.
Scope:
wildcard_receiver
Type:
lbm_ulong_t
Units:
milliseconds
38.1 Reference
301
Default
value:
When
Set:
Version:
38.1.8
50 (0.05 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_wildcard_queries_per_second (context)
Maximum number of queries sent within a one second period during wildcard receiver topic querying.
A value of 0 means that queries for the wildcard topic are not limited to a maximum number of queries per
second.
Note that the topic's queries are still subject to being rate limited by resolver_wildcard_query_bps (context).
Refer to Rate Controls for additional information.
38.1.9
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
advertisements
0
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_wildcard_query_bps (context)
Maximum query rate during wildcard receiver topic querying.
A value of 0 means that queries for the wildcard topic are not limited to a maximum number of bits per second.
Note that the topic's queries are still subject to being rate limited by resolver_wildcard_queries_per_second
(context).
Refer to Rate Controls for additional information.
302
Wildcard Receiver Options
38.1.10
Scope:
context
Type:
lbm_uint64_t
Units:
bits per second
Default
value:
When
Set:
Version:
1000000
to
Can only be set during object initialization.
This option was implemented in LBM 4.0
resolver_wildcard_receiver_map_tablesz (context)
The size of the hash table used for storing wildcard receiver patterns.
A value of 0 disables caching wildcard receiver patterns. This value should be a prime number.
Scope:
context
Type:
size_t
Units:
map entries
Default
value:
When
Set:
10273
to
Can only be set during object initialization.
Chapter 39
Event Queue Options
39.1
Reference
39.1.1
event_queue_name (event_queue)
The name of an event queue, limited to 128 alphanumeric characters, hyphens or underscores.
This is only used for XML Configuration Files.
Scope:
event_queue
string
Type:
When
Set:
Version:
39.1.2
to
Can only be set during object initialization.
This option was implemented in LBM 4.3/UME 3.3/UMQ 2.3.
queue_age_enabled (event_queue)
Controls whether the length of time each event spends on the event queue is measured.
Useful only if you are monitoring event queue statistics.
See Automatic Monitoring.
304
Event Queue Options
39.1.3
Scope:
event_queue
Type:
int
Default
value:
When
Set:
0
to
May be set during operation.
Value
Description
1
Enables measuring of event queue entry ages.
0
Disables measuring of event queue entry ages. Default for all.
queue_cancellation_callbacks_enabled (event_queue)
Flag indicating whether the event queue is to do appropriate locking to provide cancellation callback support for
cancel/delete functions.
This must be enabled if you want to use the extended form of object deletion with a callback that indicates
completion of the deletion.
For example, see lbm_src_delete_ex().
Scope:
event_queue
Type:
int
When
Set:
to
Can only be set during object initialization.
Value
Description
1
Provide support for cancellation callbacks.
0
Do not provide cancellation callback support. Default for all.
39.1 Reference
39.1.4
305
queue_count_enabled (event_queue)
Controls whether the numbers of each type of queue entry are counted.
Useful only if you are monitoring event queue statistics.
39.1.5
Scope:
event_queue
Type:
int
Default
value:
When
Set:
0
to
May be set during operation.
Value
Description
1
Enables counting event queue entries.
0
Disables counting of event queue entries. Default for all.
queue_delay_warning (event_queue)
The event queue delay threshold (in microseconds) at which the monitor function for the event queue is called.
This delay is the time that an event has been queued before being dispatched. A value of 0 indicates the event
queue delay is not to be monitored and checked.
Scope:
event_queue
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
microseconds
0 (not monitored)
to
May be set during operation.
306
Event Queue Options
39.1.6
queue_enqueue_notification (event_queue)
Flag indicating whether to call the monitor function when an event is enqueued into the given event queue.
The thread enqueuing the event is the one that calls this function. So, when this is called, the monitoring
function in use should only assume this is only notification of enqueuing. The monitor function should not
dispatch events directly.
Scope:
event_queue
Type:
int
When
Set:
39.1.7
to
May be set during operation.
Value
Description
1
Enable notification.
0
Disable notification. Default for all.
queue_objects_purged_on_close (event_queue)
Flag indicating whether the event queue should be immediately purged of any pending events associated with a
recently closed object (e.g. source, receiver) during the close operation, or be left on the queue to be discarded
as the event queue drains normally.
In either case, UM does not deliver the defunct events to the application. The Immediate purge setting reclaims memory immediately, while the Delay purge setting spreads the reclamation work over time,
reducing the CPU impact of closing objects associated with the queue.
Scope:
event_queue
int
Type:
When
Set:
to
Can only be set during object initialization.
39.1 Reference
39.1.8
307
Value
Description
1
Immediate purge. Default for all.
0
Delay purge.
queue_service_time_enabled (event_queue)
Controls whether the amount of time required to service each event on the event queue is measured.
Useful only if you are monitoring event queue statistics.
See Automatic Monitoring.
39.1.9
Scope:
event_queue
Type:
int
Default
value:
When
Set:
0
to
May be set during operation.
Value
Description
1
Enables measuring of event queue service times.
0
Disables measuring of event queue service times. Default for all.
queue_size_warning (event_queue)
The event queue size threshold (in number of events) at which the monitor function for the event queue is called.
A value of 0 indicates the event queue size is not to be monitored and checked.
308
Event Queue Options
Scope:
event_queue
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
number of events
0 (not monitored)
to
May be set during operation.
Chapter 40
Ultra Messaging Persistence Options
The options described in this section are for persistence, and are invalid for users of the UMS (streaming-only)
product.
See the Guide for Persistence for more information.
40.1
Reference
40.1.1
ume_ack_batching_interval (context)
The interval between checks by UME of consumed, unacknowledged messages.
See also ume_use_ack_batching (receiver).
See Batching Acknowledgments for more information.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
100 (0.1 seconds)
to
Can only be set during object initialization.
This option was implemented in UMS 5.0, UME 5.0, UMQ 5.0.
310
Ultra Messaging Persistence Options
40.1.2
ume_activity_timeout (receiver)
Establishes the period of time from a receiver's last activity to the release of the receiver's Reg ID. Stores return
an error to any new request for the receiver's Reg ID during this period.
Overrides the receiver-activity-timeout setting configured for the receiver's topic on the store. The default
value of 0 (zero) disables this option.
See also Persistence Proxy Sources.
40.1.3
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0 (zero)
to
Can only be set during object initialization.
ume_activity_timeout (source)
Establishes the period of time from a source's last activity to the release of the source's Reg ID. Stores return
an error to any new source requesting the source's Reg ID during this period.
If proxy sources are enabled (ume_proxy_source (source)), the store does not release the source's Reg ID and
UME elects a proxy source. Overrides the source-activity-timeout setting configured for the source's topic on
the store. The default value of 0 (zero) disables this option.
If neither proxy sources nor ume_state_lifetime (source) are configured, the store also deletes the source's
state and cache.
See also Persistence Proxy Sources.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0 (zero)
to
Can only be set during object initialization.
40.1 Reference
40.1.4
311
ume_allow_confirmed_delivery (receiver)
Specifies whether or not UME allows the sending of confirmed delivery notifications back to the source.
See also ume_confirmed_delivery_notification (source).
For more information, see Delivery Confirmation Concept.
Scope:
receiver
Type:
int
When
Set:
Version:
40.1.5
to
Can only be set during object initialization.
This option was implemented in UM 5.0.
Value
Description
1
Indicates that UME can send confirmed delivery notifications. Default for all.
0
Indicates that UME can not send confirmed delivery notifications.
ume_application_outstanding_maximum (receiver)
This UMP receiver option enables the UMP Throttled Delivery feature and sets an upper threshold on the number of message fragments from a single source that are delivered or in an event queue, but not yet consumed.
When the number of message fragments exceeds this threshold, the receiver stops buffering all incoming
message fragments. Thus, messages from the source transport stream might be dropped and recovered via
OTR or UMP late-join mechanisms.
This feature effectively limits the recovery rate and live stream rate to the receiver message consumption rate. If
OTR is disabled for the receiver, this threshold applies only during initial Late Join recovery. Setting this option
to 0 (zero) disables the UMP Throttled Delivery feature.
312
Ultra Messaging Persistence Options
40.1.6
Scope:
receiver
Type:
lbm_ulong_t
Units:
message fragments
Default
value:
When
Set:
Version:
0 (disabled)
to
Can only be set during object initialization.
This option was implemented in UMP 6.7
ume_confirmed_delivery_notification (source)
Flag indicating the application is interested in receiving notifications of consumption of messages by receivers
(confirmed delivery) via the source event mechanism.
Generates the source events LBM_SRC_EVENT_UME_DELIVERY_CONFIRMATION and/or LBM_SRC_E←VENT_UME_DELIVERY_CONFIRMATION_EX. When turned off, receivers do not send delivery confirmation
notifications to the source unless the release policy dictates the need for them. For more information, see
Delivery Confirmation Concept.
Note
Smart Sources do not support delivery confirmation.
Scope:
source
Type:
int
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"0"
LBM_SRC_TOPIC_ATTR_UME_CDELV←_EVENT_NONE
LBM_SRC_TOPIC_ATTR_UME_CDELV←_EVENT_PER_FRAGMENT
The source does not wish to receive delivery
confirmation notifications. Default for all.
The source wishes to receive delivery confirmation notifications for all messages and
message fragments.
LBM_SRC_TOPIC_ATTR_UME_CDELV←_EVENT_PER_MESSAGE
The source wishes to receive only one delivery confirmation for a message regardless
of how many fragments it comprised.
"1"
"2"
40.1 Reference
313
String value
Integer value
Description
"3"
LBM_SRC_TOPIC_ATTR_UME_CDELV←_EVENT_FRAG_AND_MSG
The source wishes to receive delivery confirmation notifications for all messages and
message fragments. In addition, the notification contains a WHOLE_MESSAGE_C←ONFIRMED flag when the last fragment of a
message has been delivered.
40.1.7
ume_consensus_sequence_number_behavior (receiver)
The behavior that the receiver will follow when determining the consensus sequence number used as the
sequence number to begin reception at upon re-registration after a failure or suspension.
This setting is only used when quorum-consensus is also used on the source.
Scope:
receiver
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"lowest"
LBM_RCV_TOPIC_ATTR_UME_QC_SQ←N_BEHAVIOR_LOWEST
Consensus is determined as the lowest of
the latest sequence numbers seen from any
store.
"majority"
LBM_RCV_TOPIC_ATTR_UME_QC_SQ←N_BEHAVIOR_MAJORITY
"highest"
LBM_RCV_TOPIC_ATTR_UME_QC_SQ←N_BEHAVIOR_HIGHEST
Consensus is determined as the latest sequence number agreed upon by the majority
of stores within a group. Between groups,
the latest of all majority decisions is used.
Default for all.
Consensus is determined as the highest of
the latest sequence numbers seen from any
store.
314
Ultra Messaging Persistence Options
40.1.8
ume_consensus_sequence_number_behavior (source)
The behavior that the source follows when determining the consensus sequence number used as the first
message of a source upon re-registration after a failure or suspension.
This setting is only used when quorum-consensus is also used.
Scope:
source
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"lowest"
LBM_SRC_TOPIC_ATTR_UME_QC_SQ←N_BEHAVIOR_LOWEST
Consensus is determined as the lowest of
the latest sequence numbers seen from any
store.
"majority"
LBM_SRC_TOPIC_ATTR_UME_QC_SQ←N_BEHAVIOR_MAJORITY
Consensus is determined as the latest sequence number agreed upon by the majority of stores within a group. Between groups,
the latest of all majority decisions is used.
"highest"
LBM_SRC_TOPIC_ATTR_UME_QC_SQ←N_BEHAVIOR_HIGHEST
Consensus is determined as the highest of
the latest sequence numbers seen from any
store. Default for all.
40.1.9
ume_explicit_ack_only (receiver)
Flag indicating if the receiver should automatically send acknowledgements to any stores and to the source or
if the application desires to explicitly generate acknowledgements itself.
See also Explicit Acknowledgments.
Scope:
receiver
Type:
int
When
Set:
to
Can only be set during object initialization.
40.1 Reference
315
Value
Description
1
The receiving application will generate acknowledgements explicitly and the UME receiver should
not automatically generate them.
0
The UME receiver will automatically generate and send acknowledgements based on message
consumption. Default for all.
40.1.10
ume_flight_size (source)
Specifies the number of messages allowed to be in flight (unstabilized at a store and without delivery confirmation) before a new message send either blocks or triggers a notification (source event).
See ume_flight_size_behavior (source).
Note that the flight size is also limited by ume_flight_size_bytes (source). The blocking behavior is enforced if
either threshold is met.
Note: for very small flight sizes, it is recommended to configure the Store's UM config option response_tcp_←nodelay (context) to 1.
40.1.11
Scope:
source
Type:
unsigned int
Units:
messages
Default
value:
When
Set:
Version:
1000
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.1/UME 3.1.1
ume_flight_size_behavior (source)
The behavior that UME follows when a message send exceeds the source's flight size.
See ume_flight_size (source).
316
Ultra Messaging Persistence Options
Scope:
source
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.1/UME 3.1.1
String value
Integer value
Description
"Block"
LBM_FLIGHT_SIZE_BEHAVIOR_BLOCK
"Notify"
LBM_FLIGHT_SIZE_BEHAVIOR_NOTIFY
The send call blocks when a source sends
a message that exceeds its flight size. If
the source uses a non-blocking send, the
send returns an LBM_EWOULD_BLOCK.
Default for all.
A message send that exceeds the configured flight size does not block but triggers a
flight size notification (source event), indicating that the flight size has been surpassed.
UME also sends a source event notification
if the number of in-flight messages falls below the configured flight size.
40.1.12
ume_flight_size_bytes (source)
Specifies the number of bytes of message payload allowed to be in flight (unstabilized at a store and without
delivery confirmation) before a new message send either blocks or triggers a notification source event.
See ume_flight_size_behavior (source).
Note that the flight size is also limited by ume_flight_size (source). The blocking behavior is enforced if either
threshold is met. If ume_flight_size_bytes is set to zero, then only ume_flight_size is used.
If using Receiver-paced Persistence, this option must be greater than 0 (zero) but less than or equal to the
repository's source-flight-size-bytes-maximum value, otherwise the source registration will fail. See Implementing RPP for more information on the coordination between RPP source and store configuration options.
Note: for very small flight sizes, it is recommended to configure the Store's UM config option response_tcp_←nodelay (context) to 1.
40.1 Reference
40.1.13
317
Scope:
source
Type:
lbm_uint64_t
Units:
bytes
Default
value:
When
Set:
Version:
0 (disabled)
to
Can only be set during object initialization.
This option was implemented in UME 5.3
ume_force_reclaim_function (source)
Callback function (and associated client data pointer) that is called when a source is forced to release a retained
message due to size limitations specified.
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.
40.1.14
Scope:
source
Type:
lbm_ume_src_force_reclaim_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
ume_late_join (source)
Flag indicating the source should allow late join operation for receivers and persistent stores.
This option is retained for backwards compatibility. The late_join (source) setting should be used instead.
Scope:
source
Type:
int
When
Set:
to
Can only be set during object initialization.
318
Ultra Messaging Persistence Options
40.1.15
Value
Description
1
The source allows late join receivers and persistent stores.
0
The source does not allow late join receivers or persistent stores. Default for all.
ume_message_stability_lifetime (source)
The total time in milliseconds from the initial send of a message before a UMP source gives up entirely on
receiving a stability acknowledgement for the message.
The source then delivers a forced reclaim notice to the application. This option is part of the Proactive Retransmissions feature.
40.1.16
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1200000 (20 minutes)
to
Can only be set during object initialization.
This option was implemented in UME 6.0
ume_message_stability_notification (source)
Flag indicating the source is interested in receiving notifications of message stability from persistent stores via
the source event mechanism.
Even when turned off, stores continue to send message stability notifications to the source for retention purposes. However, no notification will be delivered to the application.
40.1 Reference
319
Note
Smart Sources only support "0" (none) or "2" (per-message).
Scope:
source
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"0"
LBM_SRC_TOPIC_ATTR_UME_STABL←E_EVENT_NONE
The source does not wish to receive message stability notifications from the store.
"1"
LBM_SRC_TOPIC_ATTR_UME_STABL←E_EVENT_PER_FRAGMENT
"2"
LBM_SRC_TOPIC_ATTR_UME_STABL←E_EVENT_PER_MESSAGE
The source wishes to receive all message
and message fragment stability notifications
from the store. Default for all.
The source wishes to receive only a single message stability notifications from the
store when the entire message has been
stabilized. This notification contains the Sequence Number of the last fragment of the
whole message but does NOT contain store
information.
"3"
LBM_SRC_TOPIC_ATTR_UME_STABL←E_EVENT_FRAG_AND_MSG
40.1.17
The source wishes to receive all message
and message fragment stability notifications
from the store. In addition, the notification contains a WHOLE_MESSAGE_STA←BLE flag when the last fragment of a message has been stabilized.
ume_message_stability_timeout (source)
The time in milliseconds from initial send of a message until it is resent by the source because the source has
not received a stability acknowledgement for the store (or a quorum of stores).
Setting this option to 0 (zero) disables the Proactive Retransmissions feature.
Scope:
source
Type:
lbm_ulong_t
Units:
milliseconds
320
Ultra Messaging Persistence Options
Default
value:
When
Set:
Version:
40.1.18
5000 (5 seconds)
to
Can only be set during object initialization.
This option was implemented in UME 6.0
ume_proactive_keepalive_interval (context)
Maximum period of inactivity after which a persistent receiver proactively sends an acknowledgement to the
store.
A persistent receiver sends consumption acknowledgements to the store to update that receiver's state in
the store. In the absence of new consumption acknowledgments, a receiver will re-send the most-recent acknowledgement periodically to maintain that state. The ume_proactive_keepalive_interval option specifies the
maximum interval between successive acknowledgements. This value should be set less than the ume_←activity_timeout (receiver) and the state lifetime, ideally no more than 1/3 of the lesser of those two. Valid
settings are greater than or equal to 1500 (1.5 seconds, the effective minimum), or zero to disable proactive
keepalives and revert to pre-UM 6.9 keepalive behavior.
Note that disabling proactive keepalives is generally not recommended, and cannot be done for a persistent
receiver which is assigned to a Transport Services Provider (XSP).
40.1.19
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
3000 (3 seconds)
to
Can only be set during object initialization.
This option was implemented in UME 6.9.1
ume_proxy_source (source)
Controls whether any stores with which the source registers should provide a proxy source in the event the
actual source terminates.
Proxy source support is only available for quorum/consensus store configurations. In addition, proxy source
support requires that the source register with an actual registration ID, and not request that the store assign it
a registration ID.
40.1 Reference
40.1.20
321
Scope:
source
Type:
int
Default
value:
When
Set:
0
to
Can only be set during object initialization.
Value
Description
1
Enables proxy source support.
0
Disables proxy source support. Default for all.
ume_receiver_liveness_interval (context)
The maximum interval between delivery confirmations or keepalive messages send to the source.
Expiration of this interval triggers another keepalive and an interval reset.
40.1.21
Scope:
context
Type:
int
Units:
Default
value:
When
Set:
Version:
milliseconds
0 (disable; do not send keepalives)
to
Can only be set during object initialization.
This option was implemented in UME 5.2.
ume_receiver_paced_persistence (receiver)
Enables Receiver-paced Persistence (RPP) for the receiver, and specifies the blocking behavior.
If the source and store agree that the topic is receiver-paced, a receiver that leaves this option at 0 will have
a store registration error. Similarly, if the source and store agree that the topic is source paced, a receiver
322
Ultra Messaging Persistence Options
setting this option to 1 or 2 will have a store registration error. See Receiver-paced Persistence Operations
for additional information. Also see repository-allow-receiver-paced-persistence.
Scope:
receiver
Type:
lbm_uint8_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UME 5.3. Value "2" was added in UME 6.9
String value
Integer value
Description
"0"
"1"
0
1
Indicates that the receiver is not a RPP receiver. Default for all.
Indicates that the receiver is a blocking RPP receiver.
"2"
2
Indicates that the receiver is a non-blocking RPP receiver.
40.1.22
ume_receiver_paced_persistence (source)
Specifies that the source is a Receiver-paced Persistence (RPP) source and may change certain topic repository options to values allowed by the repository.
If the repository has set repository-allow-receiver-paced-persistence to 0 (disable), setting this option to 1
creates a store registration error. See Receiver-paced Persistence Operations for additional information.
Scope:
source
Type:
lbm_uint8_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UME 5.3
Value
Description
1
Indicates that source is a RPP source.
0
Indicates that source is not a RPP source. Default for all.
40.1 Reference
40.1.23
323
ume_recovery_sequence_number_info_function (receiver)
Callback function (and associated client data pointer) that is called when a receiver is about to complete registration from the stores in use by the source and the low sequence number is to be determined.
The application has the ability to modify the sequence number to use if it desires.
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.
40.1.24
Scope:
receiver
Type:
lbm_ume_rcv_recovery_info_ex_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
ume_registration_extended_function (receiver)
Callback function (and associated client data pointer) that is called when a receiver is about to attempt to
register with a persistent store.
The app must return the registration ID to request from the store or 0 if it will allow the store to allocate one.
This function passes additional extended information, such as the store being used and a source client data
pointer, etc.
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_ume_rcv_regid_ex_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
324
Ultra Messaging Persistence Options
40.1.25
ume_registration_function (receiver)
Callback function (and associated client data pointer) that is called when a receiver is about to attempt to
register with a persistent store.
The app must return the registration ID to request from the store or 0 if it will allow the store to allocate one.
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.
This option is retained for backwards compatibility. The ume_registration_extended_function (receiver) setting
should be used instead.
40.1.26
Scope:
receiver
Type:
lbm_ume_rcv_regid_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
ume_registration_interval (receiver)
The interval between registration attempts by the receiver to a persistent store in use by the source.
For networks with large numbers of receivers connecting to a store, this value can be increased to reduce the
registration load on the store.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
3000 (3 seconds)
to
Can only be set during object initialization.
40.1 Reference
40.1.27
325
ume_registration_interval (source)
The interval between registration attempts by the source. Before declaring Registration Complete, sources wait
at least one full interval, unless all stores have registered.
When using the round-robin store behavior, this is the value between registration attempts with the various
stores. In other words, attempt to register with primary, wait interval, attempt to register with secondary, wait
interval, etc.
40.1.28
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
3000 (3 seconds)
to
Can only be set during object initialization.
ume_repository_ack_on_reception (source)
For Receiver-paced Persistence (RPP) sources with a repository-type of disk or reduced-fd, specifies
that the stability acknowledgement should be sent upon message reception by the store instead of when the
message has been written to disk.
Note that this reduces the robustness of the persisted stream and makes it more susceptible to message loss
in the event of multiple failures.
This source option is ignored if RPP is not enabled. With non-RPP sources, the store's acknowledgement
behavior is controlled directly by the store's repository-allow-ack-on-reception configuration element.
When RPP is enabled, the store checks this option's value against the repository element repository-allowack-on-reception. If repository-allow-ack-on-reception is false, then the store will reject the registration from
any source that enables ume_repository_ack_on_reception. See Implementing RPP for more information on
the coordination between RPP source and store configuration options.
326
Ultra Messaging Persistence Options
Scope:
source
lbm_uint8_t
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UME 5.3
Value
Description
1
The repository sends a stability acknowledgement for a message as soon as it has received the
message.
0
The repository sends a stability acknowledgement for a message once it has been written to disk.
Default for all.
40.1.29
ume_repository_disk_file_size_limit (source)
For Receiver-paced Persistence (RPP) sources with a repository-type of disk or reduced-fd, specifies
the maximum amount of disk space used to store retained messages.
This source option is ignored if RPP is not enabled. For non-RPP sources, the repository's file size limit is
controlled directly by the store's repository-disk-file-size-limit configuration element.
When RPP is enabled, the store range checks this option's value against the repository element repositorydisk-file-size-limit, and rejects the registration if the source requests more bytes than that store's limit. As long
as the source request is less than or equal to repository-disk-file-size-limit, the store will use the source's
value in its operation. The default value (zero) causes the store to use its repository-disk-file-size-limit value.
See Implementing RPP for more information on the coordination between RPP source and store configuration
options.
Scope:
source
Type:
lbm_uint64_t
Units:
bytes
Default
value:
When
Set:
Version:
0 (disabled)
to
Can only be set during object initialization.
This option was implemented in UME 5.3
40.1 Reference
40.1.30
327
ume_repository_size_limit (source)
For Receiver-paced Persistence (RPP) sources with a repository-type of memory, disk or reduced-fd,
specifies the maximum number of message bytes retained by the store (includes payload only). For the disk
or reduced-fd repository type, this value configures the size of the memory cache.
This source option is ignored if RPP is not enabled. For non-RPP sources, the repository size limit is controlled
directly by the store's repository-size-limit configuration element.
When RPP is enabled, the store range checks this option's value against the repository element repositorysize-threshold, and rejects the registration if the source requests more bytes than that store's limit. As long
as the source request is less than or equal to repository-size-threshold, the store will use the source's value
in its operation. The default value (zero) causes the store to use its repository-size-threshold value. See
Implementing RPP for more information on the coordination between RPP source and store configuration
options.
40.1.31
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
Version:
0 (disabled)
to
Can only be set during object initialization.
This option was implemented in UME 5.3
ume_repository_size_threshold (source)
For Receiver-paced Persistence (RPP) sources with a repository-type of memory, disk or reduced-fd,
specifies the minimum number of message bytes retained by the store (includes payload only). For the disk
or reduced-fd repository type, this value configures the size of the memory cache.
This source option is ignored if RPP is not enabled. For non-RPP sources, the repository size threshold is
controlled directly by the store's repository-size-threshold configuration element.
When RPP is enabled, the store range checks this option's value against the repository element repositorysize-threshold, and rejects the registration if the source requests more bytes than that store's threshold. As
long as the source request is less than or equal to repository-size-threshold, the store will use the source's
value in its operation. The default value (zero) causes the store to use its repository-size-threshold value.
See Implementing RPP for more information on the coordination between RPP source and store configuration
options.
328
Ultra Messaging Persistence Options
40.1.32
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
Version:
0 (disabled)
to
Can only be set during object initialization.
This option was implemented in UME 5.3
ume_retention_intergroup_stability_behavior (source)
The behavior that the source will follow when determining, across store groups, both message stability and
registration completion.
A source cannot release a message until the message is stable. To be stable, a message must first be stable
within the group and then stable between groups.
Scope:
source
Type:
int
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"any", "any-group"
LBM_SRC_TOPIC_ATTR_UME_STA←BLE_BEHAVIOR_ANY
"all-active"
LBM_SRC_TOPIC_ATTR_UME_STA←BLE_BEHAVIOR_ALL_ACTIVE
Registration is complete when it is complete in any group. Messages are stable
when they are stable in any group. Default for all.
A group is active if it has at least a quorum of registered stores, or as determined by the ume_retention_intragroup←_stability_behavior option. Registration is
complete when it is complete in all active
groups. At least one group must be active. Messages are stable when they are
stable in all active groups.
"majority"
LBM_SRC_TOPIC_ATTR_UME_STA←BLE_BEHAVIOR_MAJORITY
Registration is complete when it is complete in a majority of groups. Messages
are stable when they are stable in a majority of groups.
40.1 Reference
329
String value
Integer value
Description
"all", "all-groups"
LBM_SRC_TOPIC_ATTR_UME_STA←BLE_BEHAVIOR_ALL
Registration is complete when it is complete in all groups. Messages are stable
when they are stable in all groups.
40.1.33
ume_retention_intragroup_stability_behavior (source)
The behavior that the source will follow when determining, within a store group, both message stability and
group registration completion.
A source cannot release a message until the message is stable. To be stable, a message must first be stable
within the group and then stable between groups.
Scope:
source
int
Type:
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"quorum"
LBM_SRC_TOPIC_ATTR_UME_STAB←LE_BEHAVIOR_QUORUM
"all-active"
LBM_SRC_TOPIC_ATTR_UME_STAB←LE_BEHAVIOR_ALL_ACTIVE
Registration is complete for the group
when a majority of the stores in the group
are registered. A message is stable within
the group when a majority of the stores
have acknowledged the message as stable. Default for all.
Registration is complete for the group
when a majority of the stores in the group
are registered. Stores registered with a
source are active stores. A message is
stable within the group when each active
store in that group has acknowledged the
message as stable.
"all", "all-stores"
LBM_SRC_TOPIC_ATTR_UME_STAB←LE_BEHAVIOR_ALL
Registration is complete for the group
when all stores in the group are registered.
A message is stable within the group when
all stores in the group are registered and
have acknowledged the message as stable.
330
Ultra Messaging Persistence Options
40.1.34
ume_retention_size_limit (source)
The release policy regarding aggregate size limit before messages are forced to be released.
With Smart Sources, this option is ignored. Retention buffers are preallocated. This option is retained for
backwards compatibility. The retransmit_retention_size_limit (source) setting should be used instead.
40.1.35
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
25165824 (24 MB)
to
Can only be set during object initialization.
ume_retention_size_threshold (source)
The release policy regarding aggregate size threshold before messages are released.
With Smart Sources, this option is ignored. Retention buffers are preallocated.
This option is retained for backwards compatibility. The retransmit_retention_size_threshold (source) setting
should be used instead.
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
0 (no threshold)
to
Can only be set during object initialization.
40.1 Reference
40.1.36
331
ume_retention_unique_confirmations (source)
The release policy regarding the number of confirmations from different receivers required before the source
can release a message.
This option enhances, but does not supersede, message stability notification from the store(s). If the number of
unique confirmations for a message is less than this amount, the message will not be released. If the number
of unique confirmations for a message exceeds or equals this amount, then the message may be released
if no other release policy setting overrides the decision. A value of 0 indicates there is no unique number of
confirmations required for reclamation. For more information, see Delivery Confirmation Concept.
Note
Smart Sources do not support delivery confirmation.
40.1.37
Scope:
source
Type:
size_t
Units:
Default
value:
When
Set:
number of confirmations
0 (none required)
to
Can only be set during object initialization.
ume_session_id (context)
Specifies the default Session ID to use for sources and receivers within a context. A value of 0 (zero) indicates
no Session ID is to be set.
See also Managing RegIDs with Session IDs. Valid formats for session IDs are as follows: A hexadecimal string with a maximum value of FFFFFFFFFFFFFFFE, prefixed with '0x'. An octal string with a maximum value of 1777777777777777777776 prefixed with '0'. A decimal string with a maximum value of
18446744073709551614. Prior to LBM 5.2.2, all UME session IDs were interpreted as hexadecimal, and
did not accept the '0x' prefix. If upgrading from an earlier version to LBM 5.2.2 or later, prepend '0x' to the
original setting to use the originally assigned session ID.
Scope:
context
Type:
lbm_uint64_t
Default
value:
0 (zero)
332
Ultra Messaging Persistence Options
When
Set:
Version:
40.1.38
to
Can only be set during object initialization.
This option was implemented in LBM 4.2/UME 3.2
ume_session_id (receiver)
Specifies the Session ID to use for a receiver. A value of 0 (zero) indicates the context ume_session_id will be
used.
See also Managing RegIDs with Session IDs.
Valid formats for session IDs are as follows: A hexadecimal string with a maximum value of FFFFFFFFFFFF←FFFE, prefixed with '0x'. An octal string with a maximum value of 1777777777777777777776 prefixed with '0'.
A decimal string with a maximum value of 18446744073709551614. Prior to LBM 5.2.2, all UME session IDs
were interpreted as hexadecimal, and did not accept the '0x' prefix. If upgrading from an earlier version to LBM
5.2.2 or later, prepend '0x' to the original setting to use the originally assigned session ID.
40.1.39
Scope:
receiver
Type:
lbm_uint64_t
Default
value:
When
Set:
Version:
0 (zero)
to
Can only be set during object initialization.
This option was implemented in LBM 4.2/UME 3.2
ume_session_id (source)
Specifies the Session ID to use for a source. A value of 0 (zero) indicates the context ume_session_id will be
used.
See also Managing RegIDs with Session IDs.
Valid formats for session IDs are as follows: A hexadecimal string with a maximum value of FFFFFFFFFFFF←FFFE, prefixed with '0x'. An octal string with a maximum value of 1777777777777777777776 prefixed with '0'.
A decimal string with a maximum value of 18446744073709551614. Prior to LBM 5.2.2, all UME session IDs
were interpreted as hexadecimal, and did not accept the '0x' prefix. If upgrading from an earlier version to LBM
5.2.2 or later, prepend '0x' to the original setting to use the originally assigned session ID.
40.1 Reference
40.1.40
333
Scope:
source
Type:
lbm_uint64_t
Default
value:
When
Set:
Version:
0 (zero)
to
Can only be set during object initialization.
This option was implemented in LBM 4.2/UME 3.2
ume_source_liveness_timeout (context)
The expected maximum interval between keepalive or delivery confirmation messages from a receiver.
If neither are received within the interval, the source declares the receiver "dead".
40.1.41
Scope:
context
Type:
int
Units:
Default
value:
When
Set:
Version:
milliseconds
0 (disable; do not track receivers)
to
Can only be set during object initialization.
This option was implemented in UME 5.2.
ume_sri_flush_sri_request_response (source)
This option determines if a source flushes the Implicit Batching buffer after it sends a Source Registration
Information (SRI) record in response to a SRI request from a receiver.
Flushing this buffer places the SRI record immediately on the transport, which speeds up the process of receivers registering, but also can impose a greater load on the overall network since it can reduce the amount of
transport batching.
See ume_sri_immediate_sri_request_response (source) for more information on SRI messages.
334
Ultra Messaging Persistence Options
Note
Smart Sources do not support batching, so this option is ignored by a Smart Source.
Scope:
source
lbm_ulong_t
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
Value
Description
1
The source places a SRI record in the Implicit Batching buffer and then flushes the buffer.
0
The source places a SRI record in the Implicit Batching buffer and lets normal batch scheduling
determine when to place the SRI on the transport. Default for all.
40.1.42
ume_sri_immediate_sri_request_response (source)
This option controls how quickly a source responds to a receiver's request for an SRI record.
A persistent source need to send information about its Stores so that the receivers can properly register with
those stores. The information messages sent by the sources, contained in a Source Registration Information
(SRI) record, is sent on the source's data transport session, and therefore have an effect on the transfer of
application data messages. This configuration option is provided to assist you in managing the impact of SRI
messages on the normal flow of data when a registering receiver requests the SRI record.
Note
Smart Sources do not support batching, so this option is ignored by a Smart Source.
Scope:
source
lbm_ulong_t
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
40.1 Reference
335
Value
Description
1
Indicates that the source sends an SRI record and also flushes the implicit batching buffer to
immediately put the SRI record on the transport. This maximizes the speed at which a receiver
completes its registration, but also can impose a greater load on the overall network since it can
reduce the amount of transport batching. Default for all.
0
Indicates that the source waits for the period of time defined by ume_sri_request_response_←latency (source) before sending an SRI record. This reduces overall system load, especially if
multiple receivers are registering, as it allows a single SRI record to satisfy the registration needs
of multiple receivers.
40.1.43
ume_sri_inter_sri_interval (source)
This option controls how frequently a source sends SRI records in reaction to a change in the source's registration with its stores.
Source Registration Information (SRI) records are sent by a source to its receivers for either of two reasons:
• a receiver has requested an SRI, usually because it is in the process of initializing and registering, or
• the source sees a change in its registration with its stores. For example, if a store becomes unresponsive
and the source loses registration with it. Or if a previously failed store returns to service, and the source
successfully registers with it.
This configuration option is concerned with the latter case (change in a source's registration with its stores):
the source will send SRI records to receivers to inform them of the change. It sends multiple copies over time
to maximize the chances of successful reception. It uses this configuration option to determine the interval
between these SRI sends.
The default value results in the source sending 2 SRI packets every second. This value cannot be set to 0. See
also ume_sri_max_number_of_sri_per_update (source).
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
336
Ultra Messaging Persistence Options
40.1.44
ume_sri_max_number_of_sri_per_update (source)
The maximum number of SRI packets sent by a source after a change in the source's registration with its stores.
For more information about these SRI messages, see ume_sri_inter_sri_interval (source).
40.1.45
Scope:
source
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
20
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
ume_sri_request_interval (receiver)
The interval at which a registering receiver requests information about the persistent Store(s) from the source.
The receiver cannot complete registration with the Store(s) until the source supplies the information, in the form
of a Store Information Record (SRI). If no SRI is received within this interval, the receiver will continue to send
requests until either the information is received, or until the ume_sri_request_maximum (receiver) is reached.
If that limit is reached without having received the SRI, the receiver registration fails.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
40.1 Reference
40.1.46
337
ume_sri_request_maximum (receiver)
The maximum number of requests the receiver issues for a Store Information Record (SRI) from the source.
If the receiver has not received an SRI after this number of requests, it stops requesting and fails its registration.
See ume_sri_request_interval (receiver).
40.1.47
Scope:
receiver
Type:
lbm_ulong_t
Default
value:
When
Set:
Version:
60
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
ume_sri_request_response_latency (source)
The interval a source waits before sending an SRI packet in response to a request from a receiver.
At the expiration of this interval, the SRI record may also be slightly delayed by normal batch scheduling unless
ume_sri_flush_sri_request_response (source) is set to 1.
See ume_sri_immediate_sri_request_response (source) for more information about how and why to use this.
Note
Smart Sources do not support batching, so this option is ignored by a Smart Source.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
100 (0.1 seconds)
to
Can only be set during object initialization.
This option was implemented in UMP 6.0
338
Ultra Messaging Persistence Options
40.1.48
ume_state_lifetime (receiver)
Establishes the period of time from a receiver's last activity to the deletion of the receiver's state and cache by
the store.
You can also configure a receiver-state-lifetime for the receiver's topic on the store. The store uses whichever
is shorter. The default value of 0 (zero) disables this option.
See also Persistence Proxy Sources.
40.1.49
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0 (zero)
to
Can only be set during object initialization.
ume_state_lifetime (source)
Establishes the period of time from a source's last activity to the deletion of the source's state and cache by the
store, regardless of whether a proxy source has been created or not.
You can also configure a source-state-lifetime for the source's topic on the store. The store uses whichever is
shorter. The default value of 0 (zero) disables this option.
See also Persistence Proxy Sources.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0 (zero)
to
Can only be set during object initialization.
40.1 Reference
40.1.50
339
ume_store (source)
Enable persistence for this source and add a store specification to the list of stores specified for the source.
Unlike most other UME settings, every time this setting is called, it adds another store specification to the list
and does NOT overwrite previous specifications.
Each entry contains the IP address, TCP port, registration ID, and group index for the store. For the configuration file as well as API string setting functions, the string value for this option is formatted as "DomainID:IP←:port:RegID:GroupIDX" where DomainID is the store's UM domain ID, IP is the store's IP address, port is the
TCP port for the store, RegID is the registration ID that the source desires to use, and GroupIDX is the group
index that the store belongs to. The DomainID, RegID, and GroupIDX pieces may be left off the string if desired.
If so, UMP assumes the value of 0 for them.
With most configuration options, a previously-specified value can be overridden by simply specifying the option
again with a new value. However, because each occurrence of ume_store adds a new store specification,
use the IP address 0.0.0.0 and TCP port 0 to remove all previously specified stores. This allows subsequent
store specifications to, in effect, override the earlier stores.
One or more stores means the source will use persistence. If no stores are specified, then persistence will not
be provided for the source.
When the binary form of option setting is used, UM does NOT expect an array of structures. Instead, only one
Store specification can be supplied for each call to lbm_src_topic_attr_setopt(). However, when the binary
form of option retrieval lbm_src_topic_attr_getopt() is used, the list of Stores is returned as an array, and the
optlen parameter should be set as:
optlen = (max_num_stores * sizeof(lbm_ume_store_entry_t));
Scope:
source
Type:
lbm_ume_store_entry_t
When
Set:
40.1.51
to
Can only be set during object initialization.
ume_store_activity_timeout (source)
The timeout value used to indicate when a store is unresponsive.
The store must not be active within this interval to be considered unresponsive. This value must be much larger
than the check interval.
340
Ultra Messaging Persistence Options
40.1.52
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
10,000 (10 seconds)
to
Can only be set during object initialization.
ume_store_behavior (source)
The behavior that the source follows for handling store failures.
Only quorum-consensus is allowed. The option is retained for backwards compatibility purposes.
Scope:
source
Type:
int
When
Set:
to
Can only be set during object initialization.
String value
Integer value
Description
"qc", "quorum-consensus"
LBM_SRC_TOPIC_ATTR_UME_S←TORE_BEHAVIOR_QC
The source uses multiple stores at
the same time based on store and
store group configuration. Default for
all.
40.1.53
ume_store_check_interval (source)
The interval between activity checks of the current store.
This interval also governs how often a source checks outstanding unstabilized messages to see if they have
reached the configured ume_message_stability_timeout (source) value yet.
40.1 Reference
40.1.54
341
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
ume_store_group (source)
Add a store group specification to the list of store groups specified for the source.
Unlike other UME settings, every time this setting is called, it adds another store group specification to the list
and does NOT overwrite previous specifications. Each entry contains the group index and group size for the
group. For the configuration file as well as string versions of setting this option, the string value is formatted as
"GroupIDX:GroupSZ" where GroupIDX is the index of the group and GroupSZ is the size of the group. Because
each entry adds a new store specification and does not overwrite previous values, an entry or string with the
group index of 0 and group size of 0 will cause all previous store group specifications to be removed.
Note: When setting this option multiple times, you must set this option in group-index order, from lowest to
highest. In other words, do not set this option for a group index lower in value than any previously set group
index value.
When the binary form of option setting is used, UM does NOT expect an array of structures. Instead, only one
group specification can be supplied for each call to lbm_src_topic_attr_setopt(). However, when the binary
form of option retrieval lbm_src_topic_attr_getopt() is used, the list of groups is returned as an array, and the
optlen parameter should be set as:
optlen = (max_num_store_groups * sizeof(lbm_ume_store_group_entry_t));
Scope:
source
Type:
lbm_ume_store_group_entry_t
When
Set:
to
Can only be set during object initialization.
342
Ultra Messaging Persistence Options
40.1.55
ume_store_name (source)
Add a named store specification to the list of stores specified for the source.
Unlike other UME settings, every time this setting is called, it adds another store specification to the list and
does NOT overwrite previous specifications. Each entry contains the store name, registration ID, and group
index for the store. For the configuration file as well as string versions of setting this option, the string value is
formatted as "name:RegID:GroupIDX" where name is the name of the store configured with the store attribute,
context-name in the umestored XML configuration file, RegID is the registration ID that the source desires
to use, and GroupIDX is the group index that the store belongs to. The RegID and GroupIDX pieces may be
left off the string if desired. If so, then the value of 0 is assumed for them. Store names are restricted to 128
characters in length, and may contain only alphanumeric characters, hyphens, and underscores.
When the binary form of option setting is used, UM does NOT expect an array of structures. Instead, only one
named store specification can be supplied for each call to lbm_src_topic_attr_setopt(). However, when the
binary form of option retrieval lbm_src_topic_attr_getopt() is used, the list of named stores is returned as an
array, and the optlen parameter should be set as:
optlen = (max_num_stores * sizeof(lbm_ume_store_name_entry_t));
Scope:
source
lbm_ume_store_name_entry_t
Type:
When
Set:
40.1.56
to
Can only be set during object initialization.
ume_use_ack_batching (receiver)
Specifies whether or not UME allows the batching of consumption acknowledgments sent to the store(s).
If enabled, UME checks for contiguous sequence numbered messages at the See also ume_ack_batching_←interval (context).
See Batching Acknowledgments for more information.
Scope:
receiver
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UMS 5.0, UME 5.0, UMQ 5.0.
40.1 Reference
343
Value
Description
1
Indicates that UME can acknowledge the consumption of a batch of messages. Default for all.
0
Indicates that UME acknowledges the consumption of individual messages by the receiver.
40.1.57
ume_use_late_join (receiver)
Flag indicating if the receiver should participate in late join operation or not.
This option is retained for backwards compatibility. The use_late_join (receiver) setting should be used instead.
Scope:
receiver
int
Type:
When
Set:
to
Can only be set during object initialization.
Value
Description
1
The receiver will participate in using late join if requested to by the source. Default for all.
0
The receiver will not participate in using late join even if requested to by the source.
40.1.58
ume_use_store (receiver)
Flag indicating if the receiver should participate in using a persistent store or not.
If "0" is supplied, the receiver will join as a streaming receiver.
Scope:
receiver
Type:
int
344
Ultra Messaging Persistence Options
When
Set:
to
Can only be set during object initialization.
Value
Description
1
The receiver will participate in using a persistent store if requested to by the source. Default for all.
0
The receiver will not participate in using a persistent store even if requested to by the source.
40.1.59
ume_user_receiver_registration_id (context)
32-bit value that is used as a user set identifier to be included as the receiver registration ID in acknowledgements send by any receivers in the context to sources as confirmed delivery notifications.
The value is not interpreted by UME in any way and has no relation to registration IDs used by the receiver. A
value of 0 indicates no user set value is in use and should not be sent with acknowledgements
40.1.60
Scope:
context
Type:
lbm_uint_t
Units:
Default
value:
When
Set:
identifier
0 (no user set value in use)
to
Can only be set during object initialization.
ume_write_delay (source)
For Receiver-paced Persistence (RPP) sources with a repository-type of disk or reduced-fd, specifies
the delay in milliseconds the store should delay before persisting a message to disk.
This source option is ignored if RPP is not enabled. For non-RPP sources, the store's write delay is controlled
directly by the store's repository-disk-write-delay configuration element.
When RPP is enabled, the store range checks this option's value against the repository element repositorydisk-write-delay, and rejects the registration if the source requests a longer delay than that store's limit. As
40.1 Reference
345
long as the source request is less than or equal to repository-disk-write-delay, the store will use the source's
value in its operation. The default value (zero) causes the store to use its repository-disk-write-delay value.
See Implementing RPP for more information on the coordination between RPP source and store configuration
options.
Scope:
source
Type:
lbm_uint32_t
Units:
Default
value:
When
Set:
Version:
milliseconds
0 (disabled)
to
Can only be set during object initialization.
This option was implemented in UME 5.3
346
Ultra Messaging Persistence Options
Chapter 41
Ultra Messaging Queuing Options
The options described in this section are for queuing, and are invalid for users of the UMS (streaming-only) and
UMP (streaming and persistent) products.
See the Guide for Queuing for more information.
41.1
Reference
41.1.1
umq_command_interval (context)
The interval at which all currently outstanding UMQ commands (registrations, de-registrations, message list
commands, indexed queueing commands, etc.) are re-sent if they have not yet been acknowledged by the
queue.
See Queuing.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
348
Ultra Messaging Queuing Options
41.1.2
umq_command_outstanding_maximum (context)
The maximum number of UMQ commands (registrations, de-registrations, message list commands, indexed
queueing commands, etc.) that may be outstanding at one time for each configured queue.
This option value must be greater than 0. Reducing this value may help alleviate some load on the UMQ queue
daemon, but may potentially cause registrations and other commands to take longer to complete.
41.1.3
Scope:
context
Type:
lbm_uint32_t
Units:
number of outstanding commands
Default
value:
When
Set:
Version:
1000
to
Can only be set during object initialization.
This option was implemented in UMQ 5.3.1.
umq_delayed_consumption_report_interval (receiver)
The maximum interval to delay sending consumption reports on the receiver.
Delaying consumption reports allows them to be batched together for efficiency but at the expense of delaying
the consumption reports themselves individually. The value of 0 indicates the consumption reports should not
be delayed.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
0
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
41.1 Reference
41.1.4
349
umq_hold_interval (receiver)
The maximum interval to hold control and data information within the UM queue delivery controller.
See Queuing.
41.1.5
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
umq_index_assignment_eligibility_default (receiver)
Controls whether new receivers are immediately eligible for index assignment upon registration with a queue
(the default) or whether they are ineligible upon registration and must be explicitly made eligible via a call to
lbm_rcv_umq_index_start_assignment().
See Queuing.
Scope:
receiver
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.2/UME 3.2/UMQ 1.2
String value
Integer value
Description
"Eligible"
LBM_RCV_TOPIC_ATTR_UMQ_INDEX←_ASSIGN_ELIGIBILITY_ELIGIBLE
"Ineligible"
LBM_RCV_TOPIC_ATTR_UMQ_INDEX←_ASSIGN_ELIGIBILITY_INELIGIBLE
The receiver may be assigned indices as
soon as it registers with a queue. Default
for all.
The receiver must first call lbm_rcv_umq←_index_start_assignment() before it can
be assigned any indices.
350
Ultra Messaging Queuing Options
41.1.6
umq_message_stability_notification (source)
Flag indicating the source is interested in receiving notifications of message stability from UMQ via the source
event mechanism.
Even when turned off, UMQ continues to send message stability notifications to the source for retention purposes. However, UMQ delivers no notification to the application.
Scope:
source
int
Type:
When
Set:
Version:
41.1.7
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
Value
Description
1
The source wishes to receive message stability notification. Default for all.
0
The source does not wish to receive message stability notifications.
umq_msg_total_lifetime (source)
Establishes the period of time from when a queue enqueues a message until the time the message cannot be
assigned or reassigned to a receiver. The queue deletes the message upon expiration of the lifetime.
The default value of 0 (zero) disables this option. See also Message Lifetime.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
0 (zero)
to
Can only be set during object initialization.
41.1 Reference
351
Version:
41.1.8
This option was implemented in LBM 4.2 / UME 3.2 / UMQ 2.1
umq_queue_activity_timeout (context)
The timeout value used to indicate when a queue is marked inactive.
The queue must be active within this interval to be marked inactive. This value must be much larger than the
check interval.
41.1.9
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
3000 (3.0 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
umq_queue_participation (receiver)
Flag indicating if the receiver desires to participate in Queuing operations or not.
See Queuing.
Scope:
receiver
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
352
Ultra Messaging Queuing Options
String value
Integer value
Description
"1"
1
The receiver desires to participate in Queuing operations. Default for all.
"0"
0
The receiver does not wish to participate in Queuing operations.
41.1.10
umq_queue_registration_id (context)
Add a broker/registration ID pair to the current list of broker/registration ID pairs.
Assigns a Registration ID when connected to the given broker name, using the format "BrokerName:RegID". If
a broker is not named or a broker does not support names, the broker will be given the name Default.
If a Registration ID is set for a given broker, that Registration ID is passed from the source through to the
receiver. This information can be used to identify the source from which the data originated.
Each time you set this option, it adds another BrokerName:RegID pair to a list and does not overwrite previous
specifications. If you supply an empty name, the list resets.
When the binary form of option setting is used, UM does NOT expect an array of structures. Instead, only one
broker/registration ID pair specification can be supplied for each call to lbm_context_attr_setopt(). However,
when the binary form of option retrieval lbm_context_attr_getopt() is used, the list of broker/registration ID
pairs is returned as an array, and the optlen parameter should be set as:
optlen = (max_num_regid_broker_pairs * sizeof(lbm_umq_queue_entry_t));
Scope:
context
lbm_umq_queue_entry_t
Type:
When
Set:
Version:
41.1.11
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
umq_receiver_type_id (receiver)
32-bit value that is used as an identifier to instruct the queue as to the type of receiver the receiver should be.
Used by the broker or ULB source to associate various settings with the connecting receiver.
41.1 Reference
353
For ULB receivers, see Application Sets and Receiver Type IDs for more information.
41.1.12
Scope:
receiver
Type:
lbm_uint_t
Units:
Default
value:
When
Set:
Version:
identifier
0
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
umq_retransmit_request_interval (receiver)
The interval between retransmission request messages to the queue.
See Queuing.
41.1.13
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
umq_retransmit_request_outstanding_maximum (receiver)
The maximum number of messages to request at a single time from the queue.
A value of 0 indicates no maximum.
Scope:
receiver
Type:
lbm_ulong_t
Units:
messages
354
Ultra Messaging Queuing Options
Default
value:
When
Set:
Version:
41.1.14
100
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
umq_session_id (context)
Specifies the Session ID to use for managing sources and receivers within a context.
A value of 0 (zero) indicates no Session ID is to be set. Valid formats for session IDs are as follows: A
hexadecimal string with a maximum value of FFFFFFFFFFFFFFFE, prefixed with '0x'. An octal string with a
maximum value of 1777777777777777777776 prefixed with '0'. A decimal string with a maximum value of
18446744073709551614.
41.1.15
Scope:
context
Type:
lbm_uint64_t
Default
value:
When
Set:
Version:
0 (zero)
to
Can only be set during object initialization.
This option was implemented in UMQ 5.3.
umq_ulb_application_set (source)
Defines the application sets for a ULB source. Format: "Index1:ID1,ID2,...;Index2:ID3,ID4,..."
"Index1" is the numeric index which defines an application set, and "ID1" is the numeric receiver type ID associated with one or more receivers (see umq_receiver_type_id (receiver)).
At least one application set must be specified for the source to use ULB.
The application set indices in the string can be specified in any order. However, they must be numbered
contiguously starting with 0 when the topic is allocated.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
41.1 Reference
355
For more information on application sets, see Application Sets and Receiver Type IDs.
Scope:
source
Type:
lbm_umq_ulb_receiver_type_entry_t
When
Set:
Version:
41.1.16
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_application_set_assignment_function (source)
The assignment function for one or more application sets specified as a list of entries in the format, "Index1←:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the desired assignment function
associated that application set.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
Type:
lbm_umq_ulb_application_set_attr_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
String value
Integer value
Description
"default"
LBM_SRC_TOPIC_ATTR_UMQ_ULB_A←SSIGNMENT_DEFAULT
LBM_SRC_TOPIC_ATTR_UMQ_ULB_A←SSIGNMENT_RANDOM
The default assignment function. Default
for all.
Randomized assignment function.
"random"
356
Ultra Messaging Queuing Options
41.1.17
umq_ulb_application_set_events (source)
The events mask of one or more application sets specified as a list of entries in the format, "Index1:value1;←Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the event mask to be set associated that application set.
The values may follow the same format as described in umq_ulb_events (source).
Application sets not listed default to a mask of 0.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
lbm_umq_ulb_application_set_attr_t
Type:
When
Set:
Version:
41.1.18
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_application_set_load_factor_behavior (source)
The behavior for the load factor for one or more application sets specified as a list of entries in the format,
"Index1:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the load factor behavior associated that application set.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
lbm_umq_ulb_application_set_attr_t
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
41.1 Reference
357
String value
Integer value
Description
"ignored"
LBM_SRC_TOPIC_ATTR_UMQ_ULB_L←F_BEHAVIOR_IGNORED
"provisioned"
LBM_SRC_TOPIC_ATTR_UMQ_ULB_L←F_BEHAVIOR_PROVISIONED
Load Factor information not sent and not
processed or taken into assignment consideration. Default for all.
Load Factor information on number of
sources sent and processed as well as
taken into consideration to reduce the active
portion size for each receiver.
"dynamic"
LBM_SRC_TOPIC_ATTR_UMQ_ULB_L←F_BEHAVIOR_DYNAMIC
41.1.19
Load Factor information sent and processed
as well as taken into consideration during
assignment to weight receiver choice.
umq_ulb_application_set_message_lifetime (source)
The message lifetime in milliseconds of one or more application sets specified as a list of entries in the format,
"Index1:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the message lifetime to be set
associated that application set. A message lifetime of 0 means UMQ never discards the message.
Application sets not listed default to a timeout of 0.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
Type:
lbm_umq_ulb_application_set_attr_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
358
Ultra Messaging Queuing Options
41.1.20
umq_ulb_application_set_message_max_reassignments (source)
The maximum number of message reassignments before UMQ discards a message for one or more application
sets specified as a list of entries in the format, "Index1:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the maximum number of reassignments associated that application set.
UMQ applies the initial assignment to this maximum. Setting this option to 1 means that the message will never
be reassigned. The default value of 0 means UMQ never discards the message due to too many reassignments.
Application sets not listed default to a maximum of 0.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
Type:
lbm_umq_ulb_application_set_attr_t
When
Set:
Version:
41.1.21
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_application_set_message_reassignment_timeout (source)
The message reassignment timeout (in milliseconds) of one or more application sets specified as a list of entries
in the format, "Index1:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the message reassignment
timeout to be set associated that application set.
Application sets not listed default to a timeout of 10000 (10 seconds).
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
Type:
lbm_umq_ulb_application_set_attr_t
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
41.1 Reference
41.1.22
359
umq_ulb_application_set_receiver_activity_timeout (source)
The receiver activity timeout (in milliseconds) of one or more application sets specified as a list of entries in the
format, "Index1:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the receiver activity timeout
associated that application set.
Application sets not listed default to an activity timeout of 10000 (10 seconds).
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
Type:
lbm_umq_ulb_application_set_attr_t
When
Set:
Version:
41.1.23
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_application_set_receiver_keepalive_interval (source)
The interval (in milliseconds) between keepalive messages to receivers for one or more application sets specified as a list of entries in the format, "Index1:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the receiver keepalive interval
associated that application set.
Application sets not listed default to an activity timeout of 1000 (1 second).
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
360
Ultra Messaging Queuing Options
Scope:
source
lbm_umq_ulb_application_set_attr_t
Type:
When
Set:
Version:
41.1.24
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_application_set_round_robin_bias (source)
The bias assignment towards unassigned receivers for one or more application sets specified as a list of entries
in the format, "Index1:value1;Index2:value2;..."
"Index1" is the numeric index which defines an application set, and "value1" is the round robin bias associated
that application set.
Large values increase the bias toward unassigned receivers. Zero (0) disables the bias.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
41.1.25
Scope:
source
Type:
lbm_umq_ulb_application_set_attr_t
Default
value:
When
Set:
Version:
1
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_check_interval (source)
The interval upon which ULB sources check for message reassignment, message discards, and receiver liveness.
See Ultra Load Balancing (ULB).
41.1 Reference
41.1.26
361
Scope:
source
Type:
unsigned long int
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_events (source)
A mask indicating what ULB events should be delivered to the source event callback. Applies to all application
sets and receiver types for the source.
For the configuration file as well as string API method of setting this option, the string value may be formatted
as hexadecimal value or a list of enumerated values separated by a '|' or ','.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
mask
0
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
String value
Integer value
Description
"Msg←-
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_MSG_CONS←UME (0x1)
Deliver message
events.
"MSG_TIMEOUT", "MsgTimeout"
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_MSG_TIMEO←UT (0x2)
Deliver message timeout/discard
events.
"MSG_ASSIGNMENT",
Assignment"
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_MSG_ASSIG←NMENT (0x4)
Deliver
events.
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_MSG_REASS←IGNMENT (0x8)
Deliver message reassignment
events.
"MSG_CONSUME",
Consume"
"Msg←-
"MSG_REASSIGNMENT",
MsgReassignment"
"←-
message
consumption
assignment
362
Ultra Messaging Queuing Options
String value
"MSG_COMPLETE",
Complete"
"Msg←-
Integer value
Description
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_MSG_COMP←LETE (0x10)
Deliver message completion
events. Messages are complete
once they are consumed or
discarded from all application
sets.
Deliver receiver timeout events.
"RCV_TIMEOUT", "RcvTimeout"
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_RCV_TIMEO←UT (0x20)
"RCV_REGISTRATION", "Rcv←Registration"
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_RCV_REGIS←TRATION (0x40)
Deliver
events.
"RCV_DEREGISTRATION",
RcvDeregistration"
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_RCV_DEREG←ISTRATION (0x80)
Deliver
events.
LBM_SRC_TOPIC_ATTR_UM←Q_ULB_EVENT_RCV_READY
(0x100)
Deliver receiver ready events.
"←-
"RCV_READY", "RcvReady"
41.1.27
receiver
receiver
registration
deregistration
umq_ulb_flight_size (source)
Specifies the number of messages allowed to be in flight (unconsumed) before a new message send either
blocks or triggers a notification (source event).
See Ultra Load Balancing (ULB).
41.1.28
Scope:
source
Type:
unsigned int
Units:
messages
Default
value:
When
Set:
Version:
1000
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.1/UME 3.1.1/UMQ 1.1.1
umq_ulb_flight_size_behavior (source)
The behavior that UMQ follows when a message send exceeds the source's flight size.
41.1 Reference
363
See umq_ulb_flight_size (source).
Scope:
source
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.1/UME 3.1.1/UMQ 1.1.1
String value
Integer value
Description
"Block"
LBM_FLIGHT_SIZE_BEHAVIOR_BLOCK
"Notify"
LBM_FLIGHT_SIZE_BEHAVIOR_NOTIFY
The send call blocks when a message send
exceeds the source's flight size. If the
message send is a non-blocking send, the
send returns an LBM_EWOULD_BLOCK.
Default for all.
A message send that exceeds the configured flight size does not block but triggers a
flight size notification (source event), indicating that the flight size has been surpassed.
UMQ also sends a source event notification
if the number of in-flight messages falls below the configured flight size.
41.1.29
umq_ulb_receiver_events (source)
Set the events mask of one or more receiver types specified as a list of entries in the format, "ID1:value1;ID2←:value2;..."
"ID1" is the numeric receiver type ID associated with one or more receivers (see umq_receiver_type_id (receiver)), and "value1" is the evet mask to be associated with receivers of that type.
The values may follow the same format as described in umq_ulb_events (source).
Receivers with types not listed default to a mask of 0.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
364
Ultra Messaging Queuing Options
Scope:
source
lbm_umq_ulb_receiver_type_attr_t
Type:
When
Set:
Version:
41.1.30
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_receiver_portion (source)
The portion size of one or more receiver types specified as a list of entries in the format: "ID1:value1;ID2←:value2;..."
"ID1" is the numeric receiver type ID associated with one or more receivers (see umq_receiver_type_id (receiver)), and "value1" is the portion size to be associated with receivers of that type.
Receivers with types not listed default to a portion size of 1.
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
lbm_umq_ulb_receiver_type_attr_t
Type:
When
Set:
Version:
41.1.31
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_receiver_priority (source)
The priority of one or more receiver types specified as a list of entries in the format, "ID1:value1;ID2:value2;..."
"ID1" is the numeric receiver type ID associated with one or more receivers (see umq_receiver_type_id (receiver)), and "value1" is the priority to be associated with receivers of that type.
Receivers with types not listed default to a priority of 0.
41.1 Reference
365
When the binary form of option setting is used, UM expects an array of structures. See Setting an Option from
Arrays of Binary Values.
Scope:
source
Type:
lbm_umq_ulb_receiver_type_attr_t
When
Set:
Version:
41.1.32
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1.
umq_ulb_source_activity_timeout (receiver)
The timeout value used to indicate when a ULB source is unresponsive.
The ULB source must not be active within this interval to be considered unresponsive. This value must be much
larger than the source check interval.
41.1.33
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.2 / UME 3.2 / UMQ 2.1
umq_ulb_source_check_interval (receiver)
The interval between activity checks of a ULB source.
Allow a ULB receiver to proactively attempt re-registration with a ULB source if the receiver has not seen any
activity (including keepalives) from that source in a specified amount of time, provided the source's transport
session is still alive and valid.
Scope:
receiver
Type:
lbm_ulong_t
366
Ultra Messaging Queuing Options
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
Can only be set during object initialization.
This option was implemented in LBM 4.2 / UME 3.2 / UMQ 2.1
Chapter 42
Hot Failover Operation Options
Hot Failover (HF) allows your applications to build in sender redundancy. See Hot Failover in the Ultra Messaging
Concepts Guide for a discussion of using Hot Failover within a single receiver context or across multiple receiver
contexts.
42.1
Reference
42.1.1
delivery_control_loss_check_interval (hfx)
The interval between periodic forced loss checks.
This option defaults to 0, indicating that loss checks should only be made when a new message arrives.
Scope:
hfx
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
msec
0 (no periodic loss checks)
to
Can only be set during object initialization.
This option was implemented in LBM 4.2
368
Hot Failover Operation Options
42.1.2
delivery_control_max_delay (hfx)
The minimum interval that must expire before the HFX Receiver declares a message unrecoverable and delivers
an unrecoverable loss message the application.
By default, the HFX Receiver only checks loss when it receives new messages. To enable periodic loss checks,
set the delivery_control_loss_check_interval (hfx) option.
42.1.3
Scope:
hfx
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
msec
10000 (10 seconds)
to
Can only be set during object initialization.
This option was implemented in LBM 4.2
delivery_control_maximum_burst_loss (hfx)
This controls the size of a topic sequence number gap past which the gap is declared a "burst loss".
Note that the default value for HFX is different than for non-HFX receivers.
See Burst Loss for a detailed explanation of burst loss and its semantics.
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.
See Hot Failover Across Multiple Contexts.
Scope:
hfx
Type:
lbm_uint_t
Units:
number of messages (fragments)
Default
value:
When
Set:
Version:
512
to
Can only be set during object initialization.
This option was implemented in LBM 4.2
42.1 Reference
42.1.4
369
delivery_control_maximum_total_map_entries (hfx)
The maximum number of map entries for the HFX order and loss maps.
This is a soft limit. When the sum of the number of loss records and the number of messages held for ordering
(messages that will be delivered once all prior messages have been delivered) is greater than this value,
the oldest consecutive sequence of loss records will be declared lost immediately to reduce the number of
outstanding map entries. A value of 0 indicates that the map should be allowed to grow without bound.
42.1.5
Scope:
hfx
Type:
size_t
Units:
map entries
Default
value:
When
Set:
Version:
200000
to
Can only be set during object initialization.
This option was implemented in LBM 4.2
duplicate_delivery (hfx)
Flag indicating whether duplicate messages should be discarded or simply marked as duplicates.
Setting this to 1 overrides the hf_duplicate_delivery (receiver) setting on all underlying HFX Receivers.
Scope:
hfx
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.2
Value
Description
1
The HFX delivers duplicate messages.
370
Hot Failover Operation Options
42.1.6
Value
Description
0
The HFX does not deliver duplicate messages. Default for all.
hf_duplicate_delivery (receiver)
Flag indicating if the Hot Failover receiver delivers duplicate messages or not.
In normal operation, Hot Failover only delivers the first copy received of a message.
See Hot Failover (HF) for more information.
Scope:
receiver
int
Type:
When
Set:
42.1.7
to
Can only be set during object initialization.
Value
Description
1
The Hot Failover receiver delivers duplicate messages.
0
The Hot Failover receiver does not deliver duplicate messages. Default for all.
hf_optional_messages (receiver)
Indicates if a Hot Failover receiver can receive optional messages.
See also Hot Failover (HF).
Scope:
receiver
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.2.5/UME 3.2.5/UMQ 2.1.5
42.1 Reference
42.1.8
371
Value
Description
1
Hot Failover receivers can receive optional messages. Default for all.
0
Hot Failover receivers do not receive optional messages.
hf_receiver (wildcard_receiver)
Specifies whether to create hot failover receivers for each topic that maps to the wildcard receiver pattern.
See Hot Failover (HF) for more information.
Scope:
wildcard_receiver
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in UMS 5.2.2
Value
Description
1
Create hot failover receivers for each matched topic.
0
Normal wildcard receiver operation. Hot failover sequence numbers are ignored. Default for all.
42.1.9
ordered_delivery (hfx)
Flag indicating if the HFX Receiver orders messages before delivery.
See Hot Failover Across Multiple Contexts.
372
Hot Failover Operation Options
Scope:
hfx
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.2
String value
Integer value
Description
"1"
1
The HFX Receiver delivers messages in order. Default for all.
"-1"
-1
The HFX Receiver delivers messages as soon as they are received. In
the case of fragmented messages, as soon as all fragments have been
received and reassembled.
Chapter 43
Automatic Monitoring Options
The Monitoring Options below apply to a given UM context. You can override the default values of these options
and apply monitoring option values to all UM contexts (transports and event queues) with the following environment
variables.
• LBM_MONITOR_INTERVAL
• LBM_MONITOR_TRANSPORT
• LBM_MONITOR_TRANSPORT_OPTS
• LBM_MONITOR_APPID
These variables will not override any Monitoring Options you explicitly set. The environment variables only override
Monitoring Options default values.
If you do not specify any monitoring options either in a UM configuration file or via lbm_context_attr_setopt() calls,
no monitoring will occur. However, if you then set the LBM_MONITOR_INTERVAL environment variable to 5, you
will turn on automatic monitoring for every UM context your application creates at 5 second intervals. If you then
set monitor_interval to 10 for a particular context, all transport sessions in that context will be monitored every 10
seconds.
For XML configuration files, you can configure an automatic monitoring context by setting the attribute
name=infa_statistics_context.
See also Automatic Monitoring in the Ultra Messaging Operations Guide for more information about this feature.
43.1
Reference
43.1.1
monitor_appid (context)
An application ID string used by automatic monitoring to identify the application generating the statistics.
See Automatic Monitoring.
374
Automatic Monitoring Options
Scope:
context
string
Type:
When
Set:
Version:
43.1.2
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
monitor_appid (event_queue)
An application ID string used by automatic monitoring to identify the application generating the statistics.
See Automatic Monitoring.
Scope:
event_queue
string
Type:
When
Set:
Version:
43.1.3
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
monitor_interval (context)
Interval at which automatic monitoring retrieves the statistics for all transport sessions on a context.
Setting this option to zero (the default) disables the automatic monitoring of a context's transport sessions.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
0
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
43.1 Reference
43.1.4
375
monitor_interval (event_queue)
Interval at which automatic monitoring retrieves the statistics for an event queue.
Setting this option to zero (the default) disables the automatic monitoring of an event queue. When monitoring
Event Queue statistics you must enable the Event Queue UM Configuration Options, queue_age_enabled
(event_queue), queue_count_enabled (event_queue) and queue_service_time_enabled (event_queue). UM
disables these options by default, which produces no event queue statistics.
43.1.5
Scope:
event_queue
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
0
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
monitor_interval (receiver)
Interval at which automatic monitoring retrieves the topic interest information for all receivers using a UM configuration file with this option set to a non-zero value.
Topic interest information contains source and topic information if the receiver has joined the source transport
session. If the topic interest information is blank, the receiver has not joined a source transport session. UM
System Monitoring uses this information to monitor the number of subscribed topics. Setting this option to zero
(the default) disables the automatic monitoring of receiver interest.
See Automatic Monitoring.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
0
to
Can only be set during object initialization.
This option was implemented in UM 6.5.
376
Automatic Monitoring Options
43.1.6
monitor_interval (wildcard_receiver)
Interval at which automatic monitoring retrieves the topic interest information for all receivers interested in topics
that match the wildcard receiver pattern.
Topic interest information contains source and topic information if the receiver has joined the source transport
session. If the topic interest information is blank, the receiver has not joined a source transport session. UM
System Monitoring uses this information to monitor the number of subscribed topics. Setting this option to zero
(the default) disables the automatic monitoring of a wildcard receiver interest.
See Automatic Monitoring.
43.1.7
Scope:
wildcard_receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
0
to
Can only be set during object initialization.
This option was implemented in UM 6.5.
monitor_transport (context)
The LBMMON transport module to be used for automatic monitoring.
See Automatic Monitoring.
Scope:
context
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
43.1 Reference
377
String value
Integer value
Description
"lbm"
LBM_CTX_ATTR_MON_TRANSPORT_L←BM
LBM_CTX_ATTR_MON_TRANSPORT_L←BMSNMP
Use the LBMMON lbm transport module.
Default for all.
Use the LBMMON lbmsnmp transport module. This value is required if you use the UM
SNMP Agent.
"lbmsnmp"
43.1.8
monitor_transport (event_queue)
The LBMMON transport module to be used for automatic monitoring.
See Automatic Monitoring.
Scope:
event_queue
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
String value
Integer value
Description
"lbm"
LBM_CTX_ATTR_MON_TRANSPORT_L←BM
LBM_CTX_ATTR_MON_TRANSPORT_L←BMSNMP
Use the LBMMON lbm transport module.
Default for all.
Use the LBMMON lbmsnmp transport module. This value is required if you use the UM
SNMP Agent.
"lbmsnmp"
43.1.9
monitor_transport_opts (context)
An option string to be passed to the LBMMON transport module for automatic monitoring. The format of the
option string is one or more instances of scope|optname=optval separated by semicolons.
For example:
378
Automatic Monitoring Options
context monitor_transport_opts context|resolver_multicast_interface="en0";source|trans
Note
Some UM options specify interfaces, which can be done by supplying the device name of the interface. Special
care must be taken when including this option in XML configuration files. See Interface Device Names and
XML for details.
See The LBM Transport Module for more information about Transport Options. (Options for the lbm transport
module and the lbmsnmp transport module are identical.)
Scope:
context
string
Type:
When
Set:
Version:
43.1.10
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
monitor_transport_opts (event_queue)
An option string to be passed to the LBMMON transport module for automatic monitoring. The format of the
option string is one or more instances of scope|optname=optval separated by semicolons.
For example:
event_queue monitor_transport_opts context|resolver_multicast_interface="en0";source|t
Note
Some UM options specify interfaces, which can be done by supplying the device name of the interface. Special
care must be taken when including this option in XML configuration files. See Interface Device Names and
XML for details.
See The LBM Transport Module for more information about Transport Options. (Options for the lbm transport
module and the lbmsnmp transport module are identical.)
43.1 Reference
379
Scope:
event_queue
string
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.4/UME 2.1.
380
Automatic Monitoring Options
Chapter 44
Deprecated Options
44.1
Reference
44.1.1
delivery_control_loss_tablesz (receiver)
This controls the size of the hash table index used for storing unrecoverable loss state on a per source per topic
basis.
For LBT-RM and other datagram-based transport sessions only. Larger values mean larger hash tables and
probably better CPU usage under loss scenarios at the cost of more memory per source per topic. Smaller
values mean smaller hash tables and probably worse CPU usage under loss scenarios but with less memory
usage. The value used should be a prime number for efficiency.
Scope:
receiver
Type:
size_t
Units:
Default
value:
When
Set:
Version:
table entries
131
to
Can only be set during object initialization.
Deprecated
382
Deprecated Options
44.1.2
delivery_control_order_tablesz (receiver)
This controls the size of the hash table index used for storing buffered data on a per source per topic basis
when ordered delivery is used.
For LBT-RM and other datagram-based transport sessions only. Larger values mean larger hash tables and
probably better CPU usage under loss scenarios at the cost of more memory per source per topic. Smaller
values mean smaller hash tables and probably worse CPU usage under loss scenarios but with less memory
usage. The value used should be a prime number for efficiency.
44.1.3
Scope:
receiver
Type:
size_t
Units:
Default
value:
When
Set:
Version:
table entries
131
to
Can only be set during object initialization.
Deprecated
implicit_batching_type (source)
Determines the algorithm to use for implicit batching.
This option has been deprecated because the adaptive batching algorithm has the same worst case for latency
as the default algorithm and is not better for throughput. This is because, even with adaptive batching, UM
cannot predict when the application will stop sending, at which point (unless the application calls the flush API)
the implicit batching interval must expire before the batch will be sent. To minimize latency while batching, it is
most effective to call the flush API whenever the application will not immediately send another message.
Scope:
source
int
Type:
When
Set:
Version:
to
May be set during operation.
This option was deprecated in UM 6.9.
44.1 Reference
383
String value
Integer value
Description
"default"
LBM_SRC_TOPIC_ATTR_IMPLICIT_BA←TCH_TYPE_DEFAULT
"adaptive"
LBM_SRC_TOPIC_ATTR_IMPLICIT_BA←TCH_TYPE_ADAPTIVE
Implicit batching is controlled entirely by the
implicit_batching_minimum_length (source)
and implicit_batching_interval (source) options. Refer to Message Batching for additional information. Default for all.
Source-paced batching method that attempts to adjust the amount of messages sent in each batch automatically.
The options, implicit_batching_minimum←_length (source) and implicit_batching_←interval (source), limit batch sizes and intervals but sizes and intervals will usually be
much smaller. Setting this option may have
a negative impact on maximum throughput.
44.1.4
network_compatibility_mode (context)
Enable compatibility mode which allows UM versions LBM-4.2/UME-3.2/UMQ-2.1 through UM 5.∗ to interoperate with UM versions prior to LBM-4.2/UME-3.2/UMQ-2.1 by blocking the sending of some header option
types.
This option has no effect on Ultra Messaging Versions 6.0 and later.
Scope:
context
int
Type:
When
Set:
Version:
Version:
44.1.5
to
Can only be set during object initialization.
This option was implemented in LBM 4.2/UME 3.2/UMQ 2.1.
This option was deprecated in UM 6.0 (documentation was updated to reflect this deprecation in UM 6.9).
otr_request_duration (receiver)
The length of time a receiver continues to send OTR lost-message requests before giving up. This option is
deprecated in favor of otr_request_message_timeout (receiver).
See Off-Transport Recovery (OTR).
384
Deprecated Options
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
20000 (20 seconds)
to
Can only be set during object initialization.
This option was implemented in UM 5.2
Version:
44.1.6
This option was deprecated in UM 6.0
pattern_callback (wildcard_receiver)
Callback function (and associated client data pointer) that is called when a pattern match is desired for a topic
discovered for a wildcard receiver if the pattern type is set to "appcb".
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.
A function return value of 0 indicates the given topic should be considered part of the wildcard. A value of 1 or
more indicates the topic should NOT be considered matching the wildcard.
44.1.7
Scope:
wildcard_receiver
Type:
lbm_wildcard_rcv_compare_func_t
Default
value:
When
to
Set:
Config File:
NULL
Can only be set during object initialization.
Cannot be set from an UM configuration file.
rcv_sync_cache (receiver)
UMCache only - a valid cache address (such as TCP:192.168.5.11:4567) in the standard form of TCP←:address:port enables a UM receiver to use UMCache to receive a snapshot of larger, multiple-field
messages stored by UMCache.
Receiving applications can then become synchronized with the live stream of messages sent on the receiver's
44.1 Reference
385
topic. address is the IP address of the machine where the UMCache runs and port is the configured port
where the cache request handler listens.
Scope:
receiver
Type:
umcache_reqlib_request_info_t
Default
value:
When
Set:
Version:
NULL
to
This option was implemented in UMS 5.0/UMP 5.0/UMQ 5.0
Version:
44.1.8
Can only be set during object initialization.
This option was deprecated in UM 6.9
rcv_sync_cache_timeout (receiver)
The maximum time period that a UM receiver waits for a snapshot message from the UMCache.
UMCache only.
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
2000 (2 seconds)
Version:
44.1.9
to
Can only be set during object initialization.
This option was implemented in UMS 5.0/UMP 5.0/UMQ 5.0
This option was deprecated in UM 6.9
receive_thread_pool_size (context)
For LBT-RM, LBT-RU, or TCP-LB transport sessions only. Defines the maximum number of threads available
for transports (excluding the context thread).
The MTT feature is replaced in 6.11 and beyond by Transport Services Provider (XSP).
For more information on the deprecated MTT feature, see Multi-Transport Threads.
386
Deprecated Options
Scope:
context
Type:
int
Default
value:
When
Set:
Version:
4
to
Version:
44.1.10
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1.
This option was deprecated in UM 6.9
resolver_active_source_interval (context)
Interval between sending Topic Resolution advertisements for active sources.
A value of 0 indicates that periodic advertisements should not be sent (sources will still respond to queries).
When set to 0, the resolver_active_threshold should typically also be set to 0. See also Disabling
Aspects of Topic Resolution.
Note: Although this option is eligible to be set during operation, two considerations exist. If this option is
disabled at initialization (set to 0), you cannot re-set the option during operation.Disabling this option by setting
it to 0 (zero) during operation prevents you from re-setting the option a second time during operation.
44.1.11
Scope:
context
Type:
unsigned long int
Units:
Default
value:
When
Set:
Version:
milliseconds
1000 (1 second)
to
May be set during operation.
This option was deprecated in LBM 4.0
resolver_active_threshold (context)
Number of seconds since the last application message was sent to a source that causes that source to be
marked inactive.
Inactive sources are not advertised periodically (but will continue to respond to queries). A value of 0 indicates
44.1 Reference
387
that sources will advertise periodically regardless of how often the application sends messages. Note that for
publishers with large numbers of sources, this can increase the topic resolution traffic load.
However, also note that this option SHOULD be set to 0 if periodic advertisements are disabled. See Disabling
Aspects of Topic Resolution and Interrelated Configuration Options.
44.1.12
Scope:
context
Type:
unsigned long int
Units:
Default
value:
When
Set:
Version:
seconds
60
to
May be set during operation.
This option was deprecated in LBM 4.0
resolver_context_advertisement_interval (context)
Interval between context advertisements.
Setting this option to 0 disables context advertisements, though UM Router and other functionality depends
upon context advertisements, so a value of 0 is not generally recommended.
44.1.13
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
This option was deprecated in UM 6.0
resolver_maximum_advertisements (context)
Maximum number of topics that will be advertised per active source interval.
A value of 0 means to advertise all topics.
388
Deprecated Options
44.1.14
Scope:
context
Type:
unsigned long int
Units:
Number of topics
Default
value:
When
Set:
Version:
0 (all topics)
to
May be set during operation.
This option was deprecated in LBM 4.0
resolver_maximum_queries (context)
Maximum number of topics that will be queried for per query interval.
A value of 0 means to query for all topics that do not have at least one source.
44.1.15
Scope:
context
Type:
unsigned long int
Units:
Number of topics
Default
value:
When
Set:
Version:
0 (all topics with no source)
to
May be set during operation.
This option was deprecated in LBM 4.0
resolver_query_interval (context)
Interval between query transmissions for receivers attempting Topic Resolution.
A value of 0 indicates queries should not be sent. See also Disabling Aspects of Topic Resolution.
Note: Although this option is eligible to be set during operation, two considerations exist. If this option is
disabled at initialization (set to 0), you cannot re-set the option during operation.Disabling this option by setting
it to 0 (zero) during operation prevents you from re-setting the option a second time during operation.
44.1 Reference
44.1.16
389
Scope:
context
Type:
unsigned long int
Units:
Default
value:
When
Set:
Version:
milliseconds
100 (0.1 seconds)
to
May be set during operation.
This option was deprecated in LBM 4.0
resolver_query_max_interval (wildcard_receiver)
This sets the maximum interval between wildcard queries in topic resolution (when used).
Only PCRE and regex pattern types can use wildcard queries. A value of 0 indicates wildcard queries should
not be sent. UM currently queries a maximum of 250 unique wildcard patterns (receivers).
Note: Although this option is eligible to be set during operation, two considerations exist.
• If this option is disabled at initialization (set to 0), you cannot re-set the option during operation.
• Disabling this option by setting it to 0 (zero) during operation prevents you from re-setting the option a
second time during operation.
44.1.17
Scope:
wildcard_receiver
Type:
unsigned long int
Units:
Default
value:
When
Set:
Version:
milliseconds
0 (do not query)
to
Can only be set during object initialization.
This option was deprecated in LBM 4.0
resolver_unicast_address (context)
The IP address (or domain name of the IP address) to send unicast topic resolution messages to.
390
Deprecated Options
This option was deprecated in UMS 5.0. Use resolver_unicast_daemon (context) instead.
If set to 0.0.0.0 (INADDR_ANY), then topic resolution uses multicast (the default). If set to anything else, then
topic resolution messages go to the IP address specified.
44.1.18
Scope:
context
Type:
struct in_addr
Default
value:
When
Set:
Version:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
This option was deprecated in UMS 5.0.
resolver_unicast_destination_port (context)
The UDP port to send unicast topic resolution messages to. This is the UDP port used by the UM resolution
daemon (lbmrd).
This option was deprecated in UMS 5.0. Use resolver_unicast_daemon (context) instead.
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
15380
When
Set:
Version:
44.1.19
Network
to
Can only be set during object initialization.
This option was deprecated in UMS 5.0.
resolver_unicast_port (context)
The local UDP port used for unicast topic resolution messages.
44.1 Reference
391
This option was deprecated in UMS 5.0. Use resolver_unicast_daemon (context) instead. The UM resolution
daemon (lbmrd) will send unicast topic resolution messages to this UDP port. A value of 0 indicates that
UM should pick an open port in the range (resolver_unicast_port_low (context), resolver_unicast_port_high
(context)). See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
Byte order:
0 (pick open port)
When
Set:
Version:
44.1.20
Network
to
Can only be set during object initialization.
This option was deprecated in UMS 5.0.
retransmit_message_map_tablesz (source)
The size of the hash table that the source uses to store messages for the retention policy in effect.
A larger table means more messages can be stored more efficiently, but takes up more memory. A smaller
table uses less memory, but costs more CPU time as more messages are retained. See Configuring Late
Join for Large Numbers of Messages for additional information.
44.1.21
Scope:
source
Type:
size_t
Default
value:
When
Set:
Version:
131
to
Can only be set during object initialization.
This option has been deprecated.
retransmit_request_generation_interval (receiver)
The maximum interval between when a receiver first sends a retransmission request and when the receiver
stops and reports loss on the remaining RXs not received.
See Configuring Late Join for Large Numbers of Messages for additional information.
392
Deprecated Options
This option is deprecated and has no effect. Use retransmit_request_message_timeout (receiver) instead.
44.1.22
Scope:
receiver
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
This option was deprecated in UM 6.0
retransmit_retention_age_threshold (source)
Specifies the minimum age of messages in the retained message buffer before UM can delete them. UM cannot
delete any messages younger than this value.
For UMS Late Joins, this and retransmit_retention_size_threshold (source) are the only options that affect
the retention buffer size. For UME, these two options combined with retransmit_retention_size_limit (source)
affect the retention buffer size. UM deletes a message when it meets all configured threshold criteria, i.e., the
message is older than this option (if set), and the size of the retention buffer exceeds the retransmit_←retention_size_threshold (if set). A value of 0 sets the age threshold to be always triggered, in which
case deletion is determined by other threshold criteria.
With Smart Sources, this option is ignored. Retention buffers are preallocated and are never deleted.
Scope:
source
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
seconds
0 (threshold always triggered)
to
Can only be set during object initialization.
This option was deprecated in LBM 6.10
44.1 Reference
44.1.23
393
source_cost_evaluation_function (context)
Callback function that you can use in the lbm_src_cost_function_cb() to evaluate or determine the cost of a
message path.
The UM Router (DRO) evaluates the cost of any new topic it detects. The callback supplied with this option can
affect the cost of topics to bias the UM Router toward certain message paths.
44.1.24
Scope:
context
Type:
lbm_src_cost_func_t
Default
value:
When
to
Set:
Config File:
NULL
Version:
This option was implemented in UMS 5.0/UMP 5.0/UMQ 5.0
Version:
This option was deprecated in UM 6.0
Can only be set during object initialization.
Cannot be set from an UM configuration file.
transport_datagram_max_size (context)
The maximum datagram size that can be generated by UM. The default value is 8192, the minimum is 400
bytes, and the maximum is 65535.
Do not use this configuration option.
This configuration option is replaced by the following transport-specific options: transport_tcp_datagram_max←_size (context), transport_lbtrm_datagram_max_size (context), transport_lbtru_datagram_max_size (context),
transport_lbtipc_datagram_max_size (context), transport_lbtsmx_datagram_max_size (source).
Scope:
context
Type:
unsigned int
Units:
bytes
Default
value:
When
Set:
Version:
8192
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.3.5/UME 2.0.3.
This option was deprecated in LBM 4.1
394
Deprecated Options
44.1.25
transport_lbtipc_acknowledgement_interval (receiver)
Period of time between acknowledgement (keepalive) messages sent from the receiver to the IPC source.
See also transport_lbtipc_client_activity_timeout (source).
44.1.26
Scope:
receiver
Type:
unsigned long int
Units:
Default
value:
When
Set:
Version:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
This option was deprecated in LBM 4.0
transport_lbtipc_client_activity_timeout (source)
The maximum period of inactivity (lack of acknowledgement keepalive messages) from a receiver before the
source deletes the receiver from its active receiver table.
The IPC source signals all receivers in its active receiver's table when it writes new data to the shared memory
area. See also transport_lbtipc_acknowledgement_interval (receiver).
Scope:
source
Type:
unsigned long int
Units:
Default
value:
When
Set:
Version:
milliseconds
10,000 (10 seconds)
to
Can only be set during object initialization.
This option was deprecated in LBM 4.0
44.1 Reference
44.1.27
395
transport_lbtrdma_datagram_max_size (context)
The maximum datagram size that can be generated for a LBT-RDMA transport session. The default value is
4096, the minimum is 500 bytes, and the maximum is 4096.
See Message Fragmentation and Reassembly for more information.
Warning
When the DRO is in use, it is recommended that all UM applications and components (including the DRO and
Persistent Store) share the same maximum datagram size setting. See Protocol Conversion.
Scope:
context
Type:
lbm_uint_t
Units:
bytes
Default
value:
When
Set:
Version:
4096
to
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
Version:
44.1.28
Can only be set during object initialization.
This option was deprecated in UM 6.9
transport_lbtrdma_interface (source)
Specifies the network interface over which UM LBT-RDMA sources receive connection requests from topic
receivers.
You can specify the full IP address of the interface, or just the network part (see Specifying Interfaces for
details).
Be aware that the first source joining a transport session sets the interface with this option. Thus, setting a
different interface for a subsequent topic that maps onto the same transport session will have no effect. Default
is set to INADDR_ANY, meaning that it accepts incoming connection requests from any interface.
Scope:
source
Type:
lbm_ipv4_address_mask_t
Default
value:
When
Set:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
396
Deprecated Options
44.1.29
Version:
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
Version:
This option was deprecated in UM 6.9
transport_lbtrdma_maximum_ports (context)
Maximum number of LBT-RDMA sessions to allocate.
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Units:
number of ports
Default
value:
When
Set:
Version:
5
to
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
Version:
44.1.30
Can only be set during object initialization.
This option was deprecated in UM 6.9
transport_lbtrdma_port (source)
Port number for a specific source's LBT-RDMA session.
Must be outside the transport_lbtrdma_port_low (context) and transport_lbtrdma_port_high (context) range.
See Port Assignments for more information about configuring ports.
Scope:
source
Type:
lbm_uint16_t
Default
value:
Byte order:
0 (zero)
When
Set:
Host
to
Can only be set during object initialization.
44.1 Reference
44.1.31
397
Version:
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
Version:
This option was deprecated in UM 6.9
transport_lbtrdma_port_high (context)
Highest port number that can be assigned to a LBT-RDMA session.
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
20,020
to
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
Version:
44.1.32
Can only be set during object initialization.
This option was deprecated in UM 6.9
transport_lbtrdma_port_low (context)
Lowest port number that can be assigned to a LBT-RDMA session.
See Port Assignments for more information about configuring ports.
Scope:
context
Type:
lbm_uint16_t
Default
value:
When
Set:
Version:
20,001
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
This option was deprecated in UM 6.9
398
Deprecated Options
44.1.33
transport_lbtrdma_receiver_thread_behavior (context)
Receiver behavior for monitoring a LBT-RDMA source's shared memory area for new data.
LBT-RDMA is deprecated.
Scope:
context
Type:
int
When
Set:
Version:
to
Version:
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
This option was deprecated in UM 6.9
String value
Integer value
Description
"pend"
LBM_CTX_ATTR_RDMA_RCV_THREA←D_PEND
"busy_wait"
LBM_CTX_ATTR_RDMA_RCV_THREA←D_BUSY_WAIT
Receiver waits (sleep) for notification from
RDMA that the source has updated the
shared memory area with new data. Default.
Default for all.
UM polls the shared memory area for new
data.
44.1.34
transport_lbtrdma_transmission_window_size (source)
Size of an LBT-RDMA transport's shared memory area.
This value may vary across platforms. The actual size of the shared memory area equals the value you specify
for this option plus about 64 KB for header information. The minimum value for this option is 65,536.
Refer to Source Object for additional information.
44.1 Reference
399
Scope:
source
Type:
size_t
Units:
bytes
Default
value:
When
Set:
Version:
25165824 (24 MB)
to
This option was implemented in LBM 4.1/UME 3.1/UMQ 1.1
Version:
44.1.35
Can only be set during object initialization.
This option was deprecated in UM 6.9
ume_message_map_tablesz (source)
The size of the hash table that the source uses to store messages for the retention policy in effect.
A larger table means more messages can be stored more efficiently, but takes up more memory. A smaller
table uses less memory, but costs more CPU time as more messages are retained. This setting no longer has
any effect.
44.1.36
Scope:
source
Type:
size_t
Default
value:
When
Set:
Version:
131
to
Can only be set during object initialization.
This option has been deprecated.
ume_primary_store_address (source)
IPv4 address of the persistent store to be used as the primary store.
A value of 0.0.0.0 (or INADDR_ANY) indicates no store is set as the primary. In other words, persistence is not
enabled for the source.
This setting is deprecated. Its use is not recommended except by legacy systems. Please use the ume_store
(source) option instead.
400
Deprecated Options
44.1.37
Scope:
source
Type:
struct in_addr
Default
value:
When
Set:
Version:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
This option was deprecated in UME 2.0
ume_primary_store_port (source)
TCP port of the primary persistent store. This setting is deprecated. Its use is not recommended except by
legacy systems. Please use the ume_store option instead.
See Port Assignments for more information about configuring ports.
Scope:
source
Type:
lbm_uint16_t
Default
value:
Byte order:
14567
When
Set:
Version:
44.1.38
Network
to
Can only be set during object initialization.
This option was deprecated in UME 2.0
ume_registration_id (source)
32-bit value that is used by a persistent store to identify a source.
If a source desires to identify itself as a previously known source (after a crash or shutdown), it should set the ID
to the value it was using before. A value of 0 indicates the source will allow the persistent store to assign an ID.
This setting is deprecated. Its use is not recommended except by legacy systems. Please use the ume_store
option instead.
Scope:
source
Type:
lbm_uint_t
Units:
identifier
44.1 Reference
401
Default
value:
When
Set:
Version:
44.1.39
0 (allow persistent store to assign ID)
to
Can only be set during object initialization.
This option was deprecated in UME 2.0
ume_retransmit_request_generation_interval (receiver)
The maximum interval between when a retransmission request is first sent and when it is given up on and loss
is reported.
This option is retained for backwards compatibility. The retransmit_request_generation_interval (receiver) setting should be used instead.
44.1.40
Scope:
receiver
Type:
unsigned long int
Units:
Default
value:
When
Set:
milliseconds
10000 (10 seconds)
to
Can only be set during object initialization.
ume_retransmit_request_interval (receiver)
The interval between retransmission request messages to the persistent store or to the source.
This option is retained for backwards compatibility. The retransmit_request_interval (receiver) setting should be
used instead.
Scope:
receiver
Type:
unsigned long int
Units:
Default
value:
When
Set:
milliseconds
500 (0.5 seconds)
to
Can only be set during object initialization.
402
Deprecated Options
44.1.41
ume_retransmit_request_maximum (receiver)
The maximum number of messages to request back from the current latest message when late joining a topic
or when registering with a UME store.
A value of 0 indicates no maximum.
This option is retained for backwards compatibility. The retransmit_request_maximum (receiver) setting should
be used instead.
44.1.42
Scope:
receiver
Type:
unsigned long int
Units:
messages
Default
value:
When
Set:
0
to
Can only be set during object initialization.
ume_retransmit_request_outstanding_maximum (receiver)
The maximum number of messages to request at a single time from the store or source.
A value of 0 indicates no maximum.
This option is retained for backwards compatibility. The retransmit_request_outstanding_maximum (receiver)
setting should be used instead.
Scope:
receiver
Type:
unsigned long int
Units:
messages
Default
value:
When
Set:
10
to
Can only be set during object initialization.
44.1 Reference
44.1.43
403
ume_secondary_store_address (source)
IPv4 address of the persistent store to be used as the secondary store.
A value of 0.0.0.0 (or INADDR_ANY) indicates no store is set as the secondary. This setting is deprecated. Its
use is not recommended except by legacy systems. Please use the ume_store (source) option instead.
44.1.44
Scope:
source
Type:
struct in_addr
Default
value:
When
Set:
Version:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
This option was deprecated in UME 2.0
ume_secondary_store_port (source)
TCP port of the secondary persistent store.
This setting is deprecated. Its use is not recommended except by legacy systems. Please use the ume_store
(source) option instead.
See Port Assignments for more information about configuring ports.
Scope:
source
Type:
lbm_uint16_t
Default
value:
Byte order:
14567
When
Set:
Version:
Network
to
Can only be set during object initialization.
This option was deprecated in UME 2.0
404
Deprecated Options
44.1.45
ume_tertiary_store_address (source)
IPv4 address of the persistent store to be used as the tertiary store.
A value of 0.0.0.0 (or INADDR_ANY) indicates no store is set as the tertiary.
This setting is deprecated. Its use is not recommended except by legacy systems. Please use the ume_store
(source) option instead.
44.1.46
Scope:
source
Type:
struct in_addr
Default
value:
When
Set:
Version:
0.0.0.0 (INADDR_ANY)
to
Can only be set during object initialization.
This option was deprecated in UME 2.0
ume_tertiary_store_port (source)
TCP port of the tertiary persistent store.
This setting is deprecated. Its use is not recommended except by legacy systems. Please use the ume_store
(source) option instead.
See Port Assignments for more information about configuring ports.
Scope:
source
Type:
lbm_uint16_t
Default
value:
Byte order:
14567
When
Set:
Version:
Network
to
Can only be set during object initialization.
This option was deprecated in UME 2.0
44.1 Reference
44.1.47
405
umq_flight_size (context)
Specifies the number of Multicast Immediate Messages allowed to be in flight (unstabilized at a queue) before
a new message send either blocks or triggers a notification (source event).
See Ultra Load Balancing (ULB).
Scope:
context
Type:
unsigned int
Units:
messages
Default
value:
When
Set:
Version:
1000
to
This option was implemented in LBM 4.1.1/UME 3.1.1/UMQ 1.1.1
Version:
44.1.48
Can only be set during object initialization.
This option was deprecated in UMQ 6.8
umq_flight_size (source)
Specifies the number of messages allowed to be in flight (unstabilized at a queue) before a new message send
either blocks or triggers a notification (source event).
See Ultra Load Balancing (ULB).
Scope:
source
Type:
unsigned int
Units:
messages
Default
value:
When
Set:
Version:
1000
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.1/UME 3.1.1/UMQ 1.1.1
This option was deprecated in UM 6.8
406
Deprecated Options
44.1.49
umq_flight_size_behavior (context)
The behavior that UMQ follows when a Multicast Immediate Message send exceeds the context's flight size.
See umq_flight_size (source).
Scope:
context
Type:
int
When
Set:
Version:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.1/UME 3.1.1/UMQ 1.1.1
This option was deprecated in UMQ 6.8
String value
Integer value
Description
"Block"
LBM_FLIGHT_SIZE_BEHAVIOR_BLOCK
"Notify"
LBM_FLIGHT_SIZE_BEHAVIOR_NOTIFY
The send call blocks when a MIM send exceeds the context's flight size. If the MIM
send is a non-blocking send, the send returns an LBM_EWOULD_BLOCK. Default
for all.
A message send that exceeds the configured flight size does not block but triggers
a flight size notification (context event), indicating that the flight size has been surpassed. UMQ also sends a context event
notification if the number of in-flight messages falls below the configured flight size.
44.1.50
umq_flight_size_behavior (source)
The behavior that UMQ follows when a message send exceeds the source's flight size.
See umq_flight_size (source).
Scope:
source
Type:
int
44.1 Reference
407
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 4.1.1/UME 3.1.1/UMQ 1.1.1
Version:
This option was deprecated in UM 6.8
String value
Integer value
Description
"Block"
LBM_FLIGHT_SIZE_BEHAVIOR_BLOCK
"Notify"
LBM_FLIGHT_SIZE_BEHAVIOR_NOTIFY
The send call blocks when a source sends
a message that exceeds its flight size. If
the source uses a non-blocking send, the
send returns an LBM_EWOULD_BLOCK.
Default for all.
A message send that exceeds the configured flight size does not block but triggers a
flight size notification (source event), indicating that the flight size has been surpassed.
UMQ also sends a source event notification
if the number of in-flight messages falls below the configured flight size.
44.1.51
umq_message_retransmission_interval (context)
The interval between retransmissions of data messages when submitting to a Queue.
See Queuing.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
500 (0.5 seconds)
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
This option was deprecated in UMQ 6.8
408
Deprecated Options
44.1.52
umq_message_stability_notification (context)
Flag indicating the context is interested in receiving notifications of message stability from Queues via the
context event mechanism.
Even when turned off, Queues will continue to send message stability notifications to the context for retention
purposes. However, no notification will be delivered to the application.
Scope:
context
Type:
int
When
Set:
Version:
Version:
44.1.53
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
This option was deprecated in UMQ 6.8
Value
Description
1
The context wishes to receive message stability notification. Default for all.
0
The context does not wish to receive message stability notifications.
umq_msg_total_lifetime (context)
Establishes the period of time from when a queue receives a message, or, for ULB, when a source sends a
message, until the time the message cannot be assigned or reassigned to a receiver. The queue deletes the
message upon expiration of the lifetime.
You can also set UMQ umestored option message-total-lifetime for the source's topic on the queue. However,
the message-total-lifetime option is overridden by any value assigned to umq_msg_total_lifetime (source). The
default value of 0 (zero) disables this option.
Note: This option is overridden by any message lifetime value set using send call, lbm_src_send_ex().
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
milliseconds
0 (zero)
44.1 Reference
409
When
Set:
Version:
to
This option was implemented in LBM 4.2 / UME 3.2 / UMQ 2.1
Version:
44.1.54
Can only be set during object initialization.
This option was deprecated in UMQ 6.8
umq_queue_check_interval (context)
The interval between activity checks of the individual UMQ queues.
See Queuing.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
Version:
milliseconds
500 (0.5 seconds)
to
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
Version:
44.1.55
Can only be set during object initialization.
This option was deprecated in UMQ 6.8
umq_queue_name (source)
The queue to submit messages to when sending.
See Queuing.
Scope:
source
Type:
string
When
Set:
Version:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
This option was deprecated in UMQ 6.8
410
Deprecated Options
44.1.56
umq_queue_participants_only (source)
Flag indicating the source only desires queue participants to listen to the topic.
See Queuing.
Scope:
source
Type:
int
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
Version:
This option was deprecated in UMQ 6.8
Value
Description
1
The source desires that only queue participants listen to the topic.
0
The source desires anyone to listen to the topic without regard to queue participation. Default for all.
44.1.57
umq_queue_query_interval (context)
The interval between queries sent for resolving Queues.
This option is no longer functional.
Scope:
context
Type:
lbm_ulong_t
Units:
Default
value:
When
Set:
milliseconds
200 (0.2 seconds)
to
Can only be set during object initialization.
44.1 Reference
44.1.58
411
Version:
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
Version:
This option was deprecated in UMQ 6.8
umq_require_queue_authentication (context)
Indicates if an application requires a queue to authenticate itself before accepting the queue's responses to
Queue Browser commands.
See Queuing.
Scope:
context
Type:
int
When
Set:
Version:
Version:
to
Can only be set during object initialization.
This option was implemented in UMQ 5.2.2.
This option was deprecated in UMQ 6.8
Value
Description
1
An application requires the queue to successfully authenticate before using browsing command
responses from the queue. Default for all.
0
An application does not require queue authentication.
44.1.59
umq_retention_intergroup_stability_behavior (context)
The behavior that the context will follow when determining the stability of a message from an inter-group perspective.
This has a direct impact on the release policy for the context in that a message must be stable before it may be
released. To be stable, a message must first be stable within the group and then stable between groups.
412
Deprecated Options
Scope:
context
int
Type:
When
Set:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
Version:
This option was deprecated in UMQ 6.8
String value
Integer value
Description
"any", "any-group"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_ANY
Message is considered stable once it is
stable in any group. Default for all.
"majority"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_MAJORITY
Message is considered stable once it is
stable in a majority of groups.
"all", "all-groups"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_ALL
Message is considered stable once it is
stable in all groups.
"all-active"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_ALL_ACTIVE
Message is considered stable once it is
stable in all active groups. A group is
considered active if it has at least a quorum of active or registered queues. Intergroup stability requires at least one stable
group.
44.1.60
umq_retention_intergroup_stability_behavior (source)
The behavior that the source will follow when determining the stability of a message from an inter-group perspective.
This has a direct impact on the release policy for the context in that a message must be stable before it may be
released. To be stable, a message must first be stable within the group and then stable between groups.
Scope:
source
int
Type:
When
Set:
Version:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
This option was deprecated in UMQ 6.8
44.1 Reference
413
String value
Integer value
Description
"any", "any-group"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_ANY
Message will be considered stable once
any group has reached intra-group stability for the message. Default for all.
"majority"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_MAJORITY
Message will be considered stable once
a majority of groups have reached intragroup stability for the message.
"all", "all-groups"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_ALL
Message will be considered stable once
all groups have reached intra-group stability for the message.
"all-active"
LBM_SRC_TOPIC_ATTR_UMQ_STA←BLE_BEHAVIOR_ALL_ACTIVE
Message will be considered stable once
all active groups have reached intragroup stability for the message.
44.1.61
umq_retention_intragroup_stability_behavior (context)
The behavior that the context will follow when determining the stability of a message from an intra-group perspective.
This has a direct impact on the release policy for the context in that a message must be stable before it may be
released. To be stable, a message must first be stable within the group and then stable between groups.
Scope:
context
Type:
int
When
Set:
Version:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
This option was deprecated in UMQ 6.8
String value
Integer value
Description
"quorum"
LBM_SRC_TOPIC_ATTR_UMQ_STAB←LE_BEHAVIOR_QUORUM
Message is considered stable within the
group once a quorum (or majority) of the
queues have acknowledged the message
as stable. Default for all.
414
Deprecated Options
String value
Integer value
Description
"all", "all-stores"
LBM_SRC_TOPIC_ATTR_UMQ_STAB←LE_BEHAVIOR_ALL
Message is considered stable with the
group once all queues have acknowledged
the message as stable.
"all-active"
LBM_SRC_TOPIC_ATTR_UMQ_STAB←LE_BEHAVIOR_ALL_ACTIVE
Message is considered stable with the
group once all active queues have acknowledged the message as stable.
44.1.62
umq_retention_intragroup_stability_behavior (source)
The behavior that the source will follow when determining the stability of a message from an intra-group perspective.
This has a direct impact on the release policy for the context in that a message must be stable before it may be
released. To be stable, a message must first be stable within the group and then stable between groups.
Scope:
source
int
Type:
When
Set:
Version:
Version:
to
Can only be set during object initialization.
This option was implemented in LBM 3.6/UME 3.0/UMQ 1.0.
This option was deprecated in UMQ 6.8
String value
Integer value
Description
"quorum"
LBM_SRC_TOPIC_ATTR_UMQ_STAB←LE_BEHAVIOR_QUORUM
Message will be considered stable within
the group once a quorum (or majority) of
the queues have acknowledged the message as stable. Default for all.
"all", "all-stores"
LBM_SRC_TOPIC_ATTR_UMQ_STAB←LE_BEHAVIOR_ALL
Message will be considered stable with the
group once all queues have acknowledged
the message as stable.
"all-active"
LBM_SRC_TOPIC_ATTR_UMQ_STAB←LE_BEHAVIOR_ALL_ACTIVE
Message will be considered stable with
the group once all active queues have acknowledged the message as stable.
44.1 Reference
44.1.63
415
use_transport_thread (receiver)
For LBT-RM, LBT-RU, or TCP-LB transport sessions only. Determines whether UM uses a thread from the
receiver thread pool to process message data or if it uses the context thread, which is the default.
The MTT feature is replaced in 6.11 and beyond by Transport Services Provider (XSP).
For more information on the deprecated MTT feature, see Multi-Transport Threads.
Scope:
receiver
Type:
int
When
Set:
Version:
to
Version:
Can only be set during object initialization.
This option was implemented in LBM 4.1/UME 3.1.
This option was deprecated in UM 6.9
String value
Integer value
Description
"1"
1
UM uses a thread from the receiver thread pool.
"0"
0
UM uses the context thread to process message data. Default for all.
416
Deprecated Options
Chapter 45
Option Categories
45.1
45.2
UM UDP Port Values
Configuration Option
Default Value
mim_destination_port (context)
14401
mim_incoming_destination_port (context)
14401
mim_outgoing_destination_port (context)
14401
resolver_multicast_incoming_port (context)
12965
resolver_multicast_outgoing_port (context)
12965
resolver_multicast_port (context)
12965
resolver_unicast_destination_port (context)
15380
resolver_unicast_port (context)
0 (pick open port)
resolver_unicast_port_high (context)
14406
resolver_unicast_port_low (context)
14402
transport_lbtrm_destination_port (source)
14400
transport_lbtrm_source_port_high (context)
14399
transport_lbtrm_source_port_low (context)
14390
transport_lbtru_maximum_ports (context)
5
transport_lbtru_port (source)
0 (pick open port)
transport_lbtru_port_high (context)
14389
transport_lbtru_port_high (receiver)
14379
transport_lbtru_port_low (context)
14380
transport_lbtru_port_low (receiver)
14360
UM TCP Port Values
418
45.3
45.4
Option Categories
Configuration Option
Default Value
request_tcp_port (context)
0 (use open port)
request_tcp_port_high (context)
14395
request_tcp_port_low (context)
14391
transport_tcp_maximum_ports (context)
10
transport_tcp_port (source)
0 (pick open port)
transport_tcp_port_high (context)
14390
transport_tcp_port_low (context)
14371
ume_primary_store_port (source)
14567
ume_secondary_store_port (source)
14567
ume_tertiary_store_port (source)
14567
UM Multicast Group Values
Configuration Option
Default Value
mim_address (context)
224.10.10.21
mim_incoming_address (context)
224.10.10.21
mim_outgoing_address (context)
224.10.10.21
resolver_multicast_address (context)
224.9.10.11
resolver_multicast_incoming_address (context)
224.9.10.11
resolver_multicast_outgoing_address (context)
224.9.10.11
transport_lbtrm_multicast_address (source)
0.0.0.0 (INADDRANY)
transport_lbtrm_multicast_address_high (context)
224.10.10.14
transport_lbtrm_multicast_address_low (context)
224.10.10.10
UM Timer Interval Values
Configuration Option
Default Value
delivery_control_loss_check_interval (receiver)
0 (disabled)
implicit_batching_interval (source)
200 (0.2 sec)
mim_activity_timeout (context)
60000 (60 sec)
mim_delivery_control_loss_check_interval (context)
0 (disabled)
mim_ignore_interval (context)
500 (0.5 sec)
mim_implicit_batching_interval (context)
200 (0.2 sec)
mim_nak_backoff_interval (context)
200 (0.2 sec)
mim_nak_generation_interval (context)
10000 (10 sec)
45.4 UM Timer Interval Values
419
Configuration Option
Default Value
mim_nak_initial_backoff_interval (context)
50 (0.05 sec)
mim_nak_suppress_interval (context)
1000 (1 sec)
mim_sm_maximum_interval (context)
10000 (10 sec)
mim_sm_minimum_interval (context)
200 (0.2 sec)
mim_src_deletion_timeout (context)
30000 (30 sec)
rcv_sync_cache_timeout (receiver)
2000 (2 sec)
resolver_active_source_interval (context)
1000 (1 sec)
resolver_advertisement_maximum_initial_interval (source)
500 (0.5 sec)
resolver_advertisement_minimum_initial_duration (source)
5000 (5 sec)
resolver_advertisement_minimum_initial_interval (source)
10 (0.01 sec)
resolver_advertisement_minimum_sustain_duration (source)
60 (1 minute)
resolver_advertisement_sustain_interval (source)
1000 (1 sec)
resolver_context_advertisement_interval (context)
10000 (10 sec)
resolver_no_source_linger_timeout (wildcard_receiver)
1000 (1 sec)
resolver_query_interval (context)
100 (0.1 sec)
resolver_query_max_interval (wildcard_receiver)
0 (no query)
resolver_query_maximum_initial_interval (receiver)
200 (0.2 sec)
resolver_query_maximum_interval (wildcard_receiver)
1000 (1 sec)
resolver_query_minimum_duration (wildcard_receiver)
60 (1 minute)
resolver_query_minimum_initial_duration (receiver)
5000 (5 sec)
resolver_query_minimum_initial_interval (receiver)
20 (0.02 sec)
resolver_query_minimum_interval (wildcard_receiver)
50 (0.05 sec)
resolver_query_minimum_sustain_duration (receiver)
60 (1 minute)
resolver_query_sustain_interval (receiver)
1000 (1 sec)
response_tcp_deletion_timeout (context)
20000 (20 sec)
retransmit_request_generation_interval (receiver)
10000 (10 sec)
retransmit_request_interval (receiver)
500 (0.5 sec)
transport_lbtipc_acknowledgement_interval (receiver)
500 (0.5 sec)
transport_lbtipc_activity_timeout (receiver)
60,000 (60 sec)
transport_lbtipc_client_activity_timeout (source)
10,000 (10 sec)
transport_lbtipc_sm_interval (source)
10,000 (10 sec)
transport_lbtrm_activity_timeout (receiver)
60000 (60 sec)
transport_lbtrm_ignore_interval (source)
500 (0.5 sec)
transport_lbtrm_nak_backoff_interval (receiver)
200 (0.2 sec)
transport_lbtrm_nak_generation_interval (receiver)
10000 (10 sec)
transport_lbtrm_nak_initial_backoff_interval (receiver)
50 (0.05 sec)
transport_lbtrm_nak_suppress_interval (receiver)
1000 (1 sec)
transport_lbtrm_preactivity_timeout (receiver)
0 (zero)
transport_lbtrm_rate_interval (context)
100 (0.1 sec)
transport_lbtrm_sm_maximum_interval (source)
10000 (10 sec)
transport_lbtrm_sm_minimum_interval (source)
200 (0.2 sec)
transport_lbtsmx_activity_timeout (receiver)
60,000 (60 sec)
transport_lbtsmx_sm_interval (source)
10,000 (10 sec)
transport_lbtru_acknowledgement_interval (receiver)
500 (0.5 sec)
transport_lbtru_activity_timeout (receiver)
60000 (60 sec)
transport_lbtru_client_activity_timeout (source)
10000 (10 sec)
transport_lbtru_connect_interval (receiver)
100 (0.1 sec)
transport_lbtru_ignore_interval (source)
500 (0.5 sec)
420
45.5
Option Categories
Configuration Option
Default Value
transport_lbtru_nak_backoff_interval (receiver)
200 (0.2 sec)
transport_lbtru_nak_generation_interval (receiver)
10000 (10 sec)
transport_lbtru_nak_suppress_interval (receiver)
1000 (1 sec)
transport_lbtru_rate_interval (context)
100 (0.1 sec)
transport_lbtru_sm_maximum_interval (source)
10000 (10 sec)
transport_lbtru_sm_minimum_interval (source)
200 (0.2 sec)
transport_tcp_activity_timeout (receiver)
0
transport_topic_sequence_number_info_active_threshold (source)
60
transport_topic_sequence_number_info_interval (source)
5000 (5 sec)
ume_ack_batching_interval (context)
100 (0.1 sec)
ume_activity_timeout (receiver)
0 (zero)
ume_activity_timeout (source)
0 (zero)
ume_message_stability_lifetime (source)
1200000 (20 min)
ume_message_stability_timeout (source)
20000 (20 sec)
ume_receiver_liveness_interval (context)
0 (disable)
ume_registration_interval (receiver)
500 (0.5 sec)
ume_registration_interval (source)
500 (0.5 sec)
ume_retransmit_request_generation_interval (receiver)
10000 (10 sec)
ume_retransmit_request_interval (receiver)
500 (0.5 sec)
ume_source_liveness_timeout (context)
0 (disable)
ume_state_lifetime (receiver)
0 (zero)
ume_state_lifetime (source)
0 (zero)
ume_store_activity_timeout (source)
10000 (10 sec)
ume_store_check_interval (source)
500 (0.5 sec)
umq_command_interval (context)
500 (0.5 sec)
umq_delayed_consumption_report_interval (receiver)
0
umq_hold_interval (receiver)
10000 (10 sec)
umq_message_retransmission_interval (context)
500 (0.5 sec)
umq_msg_total_lifetime (context)
0 (zero)
umq_msg_total_lifetime (source)
0 (zero)
umq_queue_activity_timeout (context)
3000 (3.0 sec)
umq_queue_check_interval (context)
500 (0.5 sec)
umq_queue_query_interval (context)
200 (0.2 sec)
umq_retransmit_request_interval (receiver)
500 (0.5 sec)
umq_ulb_check_interval (source)
1000 (1 sec)
umq_ulb_source_activity_timeout (receiver)
10000 (10 sec)
umq_ulb_source_check_interval (receiver)
1000 (1 sec)
Options That May Be Set During Operation
Configuration Option
Default Value
implicit_batching_interval (source)
200 (0.2 seconds)
45.6 Options that Cannot Be Set Via Configuration Files
421
Configuration Option
Default Value
implicit_batching_minimum_length (source)
2048 (8192 for Microsoft Windows)
implicit_batching_type (source)
queue_age_enabled (event_queue)
0
queue_count_enabled (event_queue)
0
queue_delay_warning (event_queue)
0 (not monitored)
queue_enqueue_notification (event_queue)
45.6
queue_service_time_enabled (event_queue)
0
queue_size_warning (event_queue)
0 (not monitored)
resolution_no_source_notification_threshold (receiver)
0 (do not notify)
resolution_number_of_sources_query_threshold (receiver)
10000000 (10 million)
resolver_active_source_interval (context)
1000 (1 second)
resolver_active_threshold (context)
60
resolver_maximum_advertisements (context)
0 (all topics)
resolver_maximum_queries (context)
0 (all topics with no source)
resolver_multicast_ttl (context)
16
resolver_query_interval (context)
100 (0.1 seconds)
resolver_query_max_interval (wildcard_receiver)
0 (do not query)
Options that Cannot Be Set Via Configuration Files
Configuration Option
Default Value
immediate_message_receiver_function (context)
NULL
immediate_message_topic_receiver_function (context)
NULL
mim_unrecoverable_loss_function (context)
NULL
pattern_callback (wildcard_receiver)
NULL
receiver_create_callback (wildcard_receiver)
NULL
receiver_delete_callback (wildcard_receiver)
NULL
resolver_source_notification_function (context)
NULL
resolver_string_hash_function_ex (context)
NULL
source_cost_evaluation_function (context)
NULL
source_event_function (context)
NULL
source_notification_function (receiver)
NULL
ume_force_reclaim_function (source)
NULL
ume_recovery_sequence_number_info_function (receiver)
NULL
ume_registration_extended_function (receiver)
NULL
ume_registration_function (receiver)
NULL
Source Exif Data:
File Type : PDF
File Type Extension : pdf
MIME Type : application/pdf
PDF Version : 1.5
Linearized : No
Page Count : 421
Page Mode : UseOutlines
Author :
Title :
Subject :
Creator : LaTeX with hyperref package
Producer : pdfTeX-1.40.16
Create Date : 2019:03:13 14:14:02-05:00
Modify Date : 2019:03:13 14:14:02-05:00
Trapped : False
PTEX Fullbanner : This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) kpathsea version 6.2.1
EXIF Metadata provided by EXIF.tools