Send: Blocking versus Non-Blocking

Administrators determine the behavior of send calls when a transport bus is full. Program developers may advise administrators concerning the correct behavior.

Send calls in an application program place outbound messages on a bus, which is external to the program process. A transport mediates this I/O operation. Under normal circumstances, the I/O operation completes quickly, and the send call returns.

If the bus is full, that is, it cannot accept any more messages, then two behaviors are possible. Administrators select one of these two behaviors, and configure it in the transport definition.

Blocking and Non-Blocking Send
Behavior Description
Blocking Send When the bus is full, the send call blocks, and does not return until it has placed all the outbound message data on the bus.
Non-Blocking Send (Default Behavior) When the bus is full, the transport buffers outbound messages in a backlog buffer in process memory until the bus can accept them. The send call returns.

When the bus can accept more messages, the transport automatically moves them from its backlog buffer to the bus.

If the backlog buffer overflows, the transport discards the oldest messages in the buffer to make room for new messages. The discarded messages do not arrive at slow receivers. The base library reports dataloss advisories to slow receivers.

Use TIBCO FTL Endpoint Coordination Form to document the correct behavior.

To configure this behavior in a transport definition, see “Transport Definition Reference.”