> Configuring Transports for Rendezvous
> Transports mediate the flow of messages between EMS and TIBCO Rendezvous.
> timemsd connects to Rendezvous daemons in the same way as any other Rendezvous client would. Transport definitions (in the file transports.conf) configure the behavior of these connections. You must properly configure these transports.
> How Rendezvous Messages are Imported
> The EMS server connects to the Rendezvous daemon as any other Rendezvous client would. Messages received from the Rendezvous daemon are stored in Rendezvous queues, then are dispatched to callbacks. The EMS server creates JMS message copies of the Rendezvous messages, and begins processing them as EMS messages. Transports determine how messages are imported.
> Rendezvous messages that are imported through a transport are held in queues specific to that transport. Each transports is associated with a different Rendezvous queue, which holds as many Rendezvous messages as necessary. The number of pending messages in the queue will grow if the rate of incoming Rendezvous messages is greater than the rate at which the EMS server is able to process the corresponding EMS messages.
> Depending on the import delivery mode defined for the transport, the EMS messages will be persisted on disk, which increases the likelihood of backlog in the Rendezvous queues, and which in turn results in a EMS process memory growth. This memory growth is not accounted for in any of the EMS server statistics.
> Queue Limit Policies
> In order to limit the number of pending messages in Rendezvous queues, a transport property allows you to set a queue limit policy, as you would for TIBCO Rendezvous client applications. When the queue limit for the transport is reached, the Rendezvous library discards a set number of messages. The default policy is TIBRVQUEUE_DISCARD_NONE, which means that no message is ever discarded. Setting TIBRVQUEUE_DISCARD_FIRST or TIBRVQUEUE_DISCARD_LAST allows you to specify the maximum number of Rendezvous messages that can be pending in the queue before the discard policy that you have selected is applied. When the limit is reached, the number of messages discarded is based on the discard amount value.
> When the limit is reached, Rendezvous messages are discarded, and so are not imported as EMS messages, regardless of the EMS import delivery mode. As stated above, a Rendezvous message becomes a EMS message only after it has been dispatched from the Rendezvous queue. If a queue limit is exceeded, reliable Rendezvous messages are lost.
> Rendezvous certified messages are not lost, but the message flow is interrupted. The redelivery of the missed messages is handled automatically by the Rendezvous libraries, and can not be controlled by the EMS server.
> Reaching a queue limit also generates a Rendezvous advisory that is logged (see RVADV log and console trace in the TIBCO Rendezvous documentation), indicating which transport reached its queue limit. This advisory goes into an independent, non limited, Rendezvous queue. If lots of advisories are generated, this internal queue may also grow, signalling that the limit policy is not appropriate for your environment.
> Take care when setting a queue limit policy. In a controlled environment where the risk of Rendezvous producers overwhelming the EMS server is low, there is no need to set a queue limit policy.
> Transport Definitions
> transports.conf contains zero or more transport definitions. Each definition begins with the name of a transport, surrounded by square brackets. Subsequent lines set the parameters of the transport.

> Table 52 Rendezvous: Transport Parameters
> Parameter | Description
> type | Required. For Rendezvous transports, the value must be either tibrv or tibrvcm.
> Rendezvous Parameters Use these properties for either tibrv or tibrvcm transports. The syntax and semantics of these parameters are identical to the corresponding parameters in Rendezvous clients. For full details, see the Rendezvous documentation set.
> service | When absent, the default value is 7500.
> network | When absent, the default value is the host computer’s primary network.
> daemon | When absent, the default value is an rvd process on the local host computer. When transporting messages between EMS and Rendezvous, the rvd process must be configured to run on the same host as the EMS daemon (tibemsd). To connect to a non-default daemon, supply hostname:protocol:port. You may omit any of the three parts. The default hostname is the local host computer. The default protocol is tcp. The default port is 7500.
> Rendezvous Certified Messaging (RVCM) Parameters Use these properties only for tibrvcm transports. The syntax and semantics of these parameters are identical to the corresponding parameters in Rendezvous CM clients. For full details, see the Rendezvous documentation set.
> cm_name | The name of the correspondent RVCM listener transport.
> rv_tport | Required. Each RVCM transport depends in turn upon an ordinary Rendezvous transport. Set this parameter to the name of a Rendezvous transport (type tibrv) defined in the EMS configuration file transports.conf.
> ledger_file | Name for file-based ledger.
> sync_ledger | true or false. If true, operations that update the ledger do not return until changes are written to the storage medium.
> request_old | true or false. If true, this transport server requests unacknowledged messages sent from other RVCM senders while this transport was unavailable.
> default_ttl | This parameter sets default CM time limit (in seconds) for all CM messages exported on this transport.
> explicit_config_only | true or false. If true, tibemsd allows RVCM listeners to register for certified delivery only if they are configured in advance with the EMS server (either in tibrvcm.conf or using the create rvcmlistener command). That is, tibemsd ignores registration requests from non-configured listeners. If false (the default), tibemsd allows any RVCM listener to register.
> EMS Parameters Use these properties for either tibrv or tibrvcm transports.
> topic_import_dm queue_import_dm | EMS sending clients can set the JMSDeliveryMode header field for each message. However, Rendezvous clients cannot set this header. Instead, these two parameters determine the delivery modes for all topic messages and queue messages that tibemsd imports on this transport. TIBEMS_PERSISTENT | TIBEMS_NON_PERSISTENT | TIBEMS_RELIABLE When absent, the default is TIBEMS_NON_PERSISTENT.
> export_headers | When true, tibemsd includes JMS header fields in exported messages. When false, tibemsd suppresses JMS header fields in exported messages. When absent, the default value is true.
> export_properties | When true, tibemsd includes JMS properties in exported messages. When false, tibemsd suppresses JMS properties in exported messages. When absent, the default value is true.
> rv_queue_policy | Set the queue limit policy for the Rendezvous queue used by the transport to hold incoming Rendezvous messages. This parameter has three parts: policy:max_msgs:qty_discard where policy is one of the queue limit policies described below, max_msgs is the maximum number of messages permitted in the queue before discard, and qty_discard is the number of messages that the EMS server discards when max_msgs is reached. The queue limit policies are:
> ● | TIBRVQUEUE_DISCARD_NONE — do not discard messages. Use this policy when the queue has no limit on the number of messages it can contain.
> ● | TIBRVQUEUE_DISCARD_FIRST — discard the first message in the queue. The first message in the queue is the oldest message, which if not discarded would be the next message dispatched from the queue.
> ● | TIBRVQUEUE_DISCARD_LAST — discard the last message in the queue. The last message is the most recent message received into the queue.
> For example, the following would cause the Rendezvous library to discard the 100 oldest messages in the queue when the total number of messages in the queue reached 10,000: rv_queue_policy=TIBRVQUEUE_DISCARD_FIRST:10000:100 If the rv_queue_policy is not present, the default queue limit policy is TIBRVQUEUE_DISCARD_NONE.
> temp_destination_timeout | Specifies the amount of time the server is to keep the temporary destination (created for the RV inbox) after its last use of the destination. This is useful for a multi-server configuration. For example, in a configuration in which rv-requester -> serverA -> serverB -> rv-responder, setting temp_destination_timeout=60 on serverB specifies that serverB is to hold the temporary destination for 60 seconds.

> Example
> These examples from transports.conf illustrate the syntax of transport definitions.
> [RV01]
> type = tibrv
> topic_import_dm = TIBEMS_RELIABLE
> queue_import_dm = TIBEMS_PERSISTENT
> service = 7780
> network = lan0
> daemon = tcp:host5:7885
> [RV02]
> type = tibrv
> service = 7890
> network = lan0
> daemon = tcp:host5:7995
> temp_destination_timeout = 60
> [RVCM01]
> type = tibrvcm
> export_headers = true
> export_properties = true
> rv_tport = RV02
> cm_name = RVCMTrans1
> ledger_file = ledgerFile.store
> sync_ledger = true
> request_old = true
> default_ttl = 600
> In the following two examples, RVCM03 is an RVCM transport which does not define a queue limit policy, but references the RV transport RV03, which does have a queue limit policy. If Rendezvous messages are published to a subject that in EMS has the destination property import=RVCM03, no Rendezvous message will ever be discarded because each transport uses its own queue. Only messages that are imported directly through the RV03 transport will potentially be discarded, should the queue limit of 10000 messages be reached.
> [RV03]
> type = tibrv
> service = 7890
> network = lan0
> daemon = tcp:host5:7995
> rv_queue_policy = TIBRVQUEUE_DISCARD_LAST:10000:100
> [RVCM03]
> type = tibrvcm
> rv_tport = RV03
> cm_name = RVCMTrans2
> ledger_file = ledgerFile2.store
> sync_ledger = true
> request_old = true
> default_ttl = 600

Copyright © TIBCO Software Inc. All Rights Reserved.