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.
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.
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".
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.
Reference <-
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 |
| Type: | int |
| When to Set: | Can only be set during object initialization. |
| Version: | 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. |
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 receiver event.
- The receiver does not necessarily stop querying after the delivery of this notification. A value of 0 indicates no notifications will be sent.
- Attention
- This feature leverages UDP-based Topic Resolution queries. It won't work properly if UDP TR queries are disabled (for example, if resolution_number_of_sources_query_threshold (receiver) is set to 0), or if resolver_disable_udp_topic_resolution (context) is set to 1 (enables TCP-only Topic Resolution). If the "no source notification" feature is enabled and UDP queries are disabled, the notification might be delivered prematurely, or not at all.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | Number of queries |
| Default value: | 0 (do not notify) |
| When to Set: | 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.
- Attention
- Do not set this option to 0. It results in no topic resolution queries being generated, which interferes with the operation of resolution_no_source_notification_threshold (receiver), and potentially interferes with DRO operation (see Interest and Topic Resolution).
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | Number of sources |
| Default value: | 10000000 (10 million) |
| When to Set: | 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 |
| Default value: | 500 (0.5 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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.
| Scope: | source |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 5000 (5 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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: | milliseconds |
| Default value: | 10 (0.01 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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.
| Scope: | source |
| Type: | lbm_ulong_t |
| Units: | seconds |
| Default value: | 60 (1 minute) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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 TIRs 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 to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.2/UME 3.2/UMQ 2.1 |
| 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).
|
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.
| Scope: | source |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 1000 (1 second) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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 and can avoid receivers attempting to join "stale" sources, but can also increase network load.
- Informatica recommends against disabling the resolver cache. The same advantages can be obtained by using TCP-based Topic Resolution, or by enabling resolver_send_final_advertisements (source) with UDP-based Topic Resolution.
- Warning
- The resolver cache must be enabled if wildcard receivers and/or if resolver_service (context) is used.
| Scope: | context |
| Type: | int |
| When to Set: | 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.
| Scope: | context |
| Type: | lbm_uint64_t |
| Units: | milliseconds |
| Default value: | 60000 (60 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UM 6.0 |
resolver_context_name_query_duration (context) <-
- Maximum period of time UM sends context name queries.
- 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.
| Scope: | context |
| Type: | lbm_uint64_t |
| Units: | milliseconds |
| Default value: | 0 (query for as long as unresolved) |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UM 6.0 |
resolver_context_name_query_maximum_interval (context) <-
- The longest interval between sending context name queries.
- This option has an effective minimum of 100 ms. See UDP-Based Resolver Operation Options.
- A value of 0 disables context name queries.
| Scope: | context |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 1000 (1 second) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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 persistent source using named Stores and the second query sent.
- This option has an effective minimum of 100 ms. See UDP-Based Resolver Operation Options.
- A value of 0 disables context name queries.
| Scope: | context |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 100 (0.1 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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.
- All components in the UM network, both applications and UM daemons, should have the same setting for this option.
| Scope: | context |
| Type: | lbm_uint_t |
| Units: | bytes |
| Default value: | 8192 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 3.6/UME 3.0. |
resolver_disable_udp_topic_resolution (context) <-
- Used to disabled UDP-based Topic Resolution.
- This is typically only used when TCP-based Topic Resolution is enabled.
- When enabled, no UPD based Topic Resolution traffic will be generated nor will any UDP based Topic Resolution traffic be processed.
- Note that since UDP Topic Resolution queries are not generated, the resolution_no_source_notification_threshold (receiver) feature is incompatible with this setting.
| Scope: | context |
| Type: | int |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UM 6.14 |
| Value | Description |
| 1 | Disables UDP based Topic Resolution.
|
| 0 | Normal UDP based Topic Resolution is used. Default for all. |
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: | 0 |
| When to Set: | Can only be set during object initialization. |
| Version: | 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 DROs, 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 DRO 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. |
| "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 DRO within this timeout value in seconds. Use the following formula: 3 * {propagation-interval}/1000 + {maximum expected duration of DRO outage} where "propagation-interval" is an attribute value of the DRO configuration element <route-info>, 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 DROs 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 DROs.
|
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: | 1000000 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.0 |
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.
| Scope: | context |
| Type: | lbm_ulong_t |
| Units: | advertisements |
| Default value: | 1000 |
| When to Set: | Can only be set during object initialization. |
| Version: | 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: | advertisements |
| Default value: | 1000 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.0 |
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.
| Scope: | context |
| Type: | lbm_uint64_t |
| Units: | bits per second |
| Default value: | 1000000 |
| When to Set: | Can only be set during object initialization. |
| Version: | 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.
- This option has an effective minimum of 20 ms. See UDP-Based Resolver Operation Options.
- A value of 0 disables the initial phase of querying. Informatica recommends against disabling all queries; see Disabling Aspects of Topic Resolution.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 200 (0.2 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.0 |
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.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 5000 (5 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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.
- This option has an effective minimum of 20 ms. See UDP-Based Resolver Operation Options.
- A value of 0 disables the initial phase of querying. Informatica recommends against disabling all queries; see Disabling Aspects of Topic Resolution.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 20 (0.02 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.0 |
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.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | seconds |
| Default value: | 60 (1 minute) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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.
- This option has an effective minimum of 100 ms. See UDP-Based Resolver Operation Options.
- A value of 0 disables the sustaining phase of querying. Informatica recommends against disabling all queries; see Disabling Aspects of Topic Resolution.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 1000 (1 second) |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.0 |
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.
| Scope: | context |
| Type: | size_t |
| Units: | map entries |
| Default value: | 131111 |
| When to Set: | Can only be set during object initialization. |
resolver_send_final_advertisements (source) <-
- Controls whether or not a source sends "final advertisements" when deleted.
- This option applies to UDP-based Topic Resolution only. TCP-based Topic Resolution uses a different mechanism for informing the SRS of source deletion.
- A final advertisement is an topic resolution 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 the Transport Session are deleted and the transport session is disposed. At that point, each receiver to a source on that transport session will 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. (This is the default behavior for TCP-based Topic Resolution.)
- 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 option does not affect the UDP-based Topic Resolution phases you have configured.
| Scope: | source |
| Type: | lbm_uint_t |
| When to Set: | Can only be set during object initialization. |
| Version: | 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 to Set: | Can only be set during object initialization. |
| Version: | 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 option does not affect the topic resolution phases you have configured, which execute as expected.
|
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: | 131111 |
| When to Set: | Can only be set during object initialization. |
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 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. The other choices are retained for backwards compatibility.
| Scope: | context |
| Type: | lbm_str_hash_func_t |
| Default value: | NULL |
| When to Set: | Can only be set during object initialization. |
| String value | Integer value | Description |
| "murmur2" | n.a. | The best hash function included with UM. Credit to Austin Appleby. We do not know of any use cases where a different choice is better. Default for all. |
| "classic" | n.a. | Retained for backwards compatibility.
|
| "djb2" | n.a. | The Dan Bernstein algorithm from comp.lang.c. Retained for backwards compatibility.
|
| "sdbm" | n.a. | sdbm database library (used in Berkeley DB). Retained for backwards compatibility.
|
resolver_string_hash_function_ex (context) <-
- The hash function to use for hashing topic name strings for source and receiver topics.
- 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.
| Scope: | context |
| Type: | lbm_str_hash_func_ex_t |
| Default value: | NULL |
| When to Set: | Can only be set during object initialization. |
| Config File: | 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: | 1000000 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.0 |
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.
| Scope: | context |
| Type: | lbm_ulong_t |
| Units: | advertisements |
| Default value: | 0 |
| When to Set: | Can only be set during object initialization. |
| Version: | 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: | advertisements |
| Default value: | 0 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in LBM 4.0 |
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.
| Scope: | context |
| Type: | lbm_uint64_t |
| Units: | bits per second |
| Default value: | 1000000 |
| When to Set: | Can only be set during object initialization. |
| Version: | 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: | milliseconds |
| Default value: | 1000 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UMS 5.0 |
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.
| Scope: | context |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 200 |
| When to Set: | Can only be set during object initialization. |
| Version: | 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 option only applies to the unicast resolver.
| Scope: | context |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 200 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UMS 5.0 |
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 |
| Type: | lbm_uint16_t |
| When to Set: | Can only be set during object initialization. |
-
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 to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UM 6.7.1 |
| 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. |
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: | milliseconds |
| Default value: | 500 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UMS 5.0 |