Configuration Guide
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.

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 for the topic.
The receiver does not stop querying after the delivery of this notification. A value of 0 indicates no notifications will be sent.
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.
A value of zero results in no topic resolution queries being generated. See also Disabling Aspects of 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, but can increase network load. Informatica recommends against disabling the resolver cache.
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.
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.
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 UMP source using named stores and the second query sent.
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.
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.
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: 8192
When to Set: Can only be set during object initialization.
Version: This option was implemented in LBM 3.6/UME 3.0.


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 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.
"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 "<route-info>" 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.


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.
A value of 0 disables the initial phase of querying.
See also 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.
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: 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.
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: 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" 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.
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 setting does not affect the topic resolution phases you have configured, which execute as expected.


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:
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
Type: lbm_resolver_service_entry_t
When to Set: Can only be set during object initialization.
Version: 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: 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, 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: NULL
When to Set: 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.


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 setting 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.

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.


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