See also Off-Transport Recovery (OTR) for general information on OTR.
Reference <-
otr_message_caching_threshold (receiver) <-
- Number of messages in the Delivery Controller's Order Map above which UM will trigger OTR to try to recover the messages.
- This option only applies for receivers that are enabled for Off-Transport Recovery (OTR). See Delivery Controller for a description of the Order Map.
- The purpose for this option is to speed up recovery in the presence of loss. The delivery controller normally delays for otr_request_initial_delay (receiver) before initiating OTR. This is to give the transport layer time to recover the lost datagram through its more efficient protocol. However, if the number of datagrams waiting for recovery grows too large, it might indicate that the transport layer is unable to recover the datagrams. In this case, it can be helpful to bypass the normal OTR initial delay and immediately initiate OTR.
- For environments that are subject to severe loss events, and has expanded the source's transport transmission windows to accommodate, this option should typically be increased above its default to prevent premature OTR.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | messages |
| Default value: | 10000 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UM 6.0 |
otr_request_initial_delay (receiver) <-
- The length of time a receiver waits before initiating OTR to recover lost datagrams.
- Note that unlike transport-level NAKing, this option is not specific to each lost datagram. Rather the Delivery Controller is either "in" OTR mode or it is not. This delay time controls the entry into OTR mode. Once that happens, the OTR feature will request individual datagrams according to its internal algorithms.
- See Off-Transport Recovery (OTR).
- Some conditions can initiate OTR without delay, like the Delivery Controller's Order Map growing too large (see otr_message_caching_threshold (receiver)). Another case is when the ume_application_outstanding_maximum (receiver) option is set to a non-zero value, then a burst of live messages arriving faster than the application can consume them will put the Delivery Controller into OTR mode. In these cases, OTR can begin prior to the configured initial delay time.
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 2000 (2 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UM 5.3 |
otr_request_log_alert_cooldown (receiver) <-
- Each OTR request generates a log message, subject to log message throttling. 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).
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | seconds |
| Default value: | 300 (5 minutes) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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.
- 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).
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | milliseconds |
| Default value: | 10000 (10 seconds) |
| When to Set: | Can only be set during object initialization. |
| Version: | 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: | 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 |
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).
| 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 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 (not recommended).
- See Off-Transport Recovery (OTR).
| Scope: | receiver |
| Type: | lbm_ulong_t |
| Units: | messages |
| Default value: | 200 |
| When to Set: | Can only be set during object initialization. |
| Version: | This option was implemented in UM 5.2 |
use_otr (receiver) <-
- Flag indicating if the receiver can use OTR or not.
- See Off-Transport Recovery (OTR).
- Warning
- The persistent Store uses a UM receiver to receive messages from a persistent source. However, the Store's receiver is NOT considered a "persistent" receiver, and therefore will not use OTR by the default setting. To achieve a high level of guarantee, Informatica recommends persistence users to set "use_otr" to 1 in the Store's LBM configuration.
| Scope: | receiver |
| Type: | int |
| When to Set: | Can only be set during object initialization. |
| Version: | 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. |