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.
| 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.”
- Shared Memory Transports and One-to-Many Non-Blocking Send
Shared memory transports buffer message data from one-to-many send calls in the shared memory segment itself, rather than in a backlog buffer in process memory. - Blocking Send and Inline Mode
Programs that use inline event queues must ensure that callbacks return promptly and do not include operations that might block. If a program with inline event queues sends messages from within a callback, administrators must ensure that those outbound transports specify only non-blocking send. In this situation, blocking send could cause the send call within the callback to block the inline dispatch thread (even though the programmer expected the send call to return immediately).