Publisher Mode

When an endpoint uses a persistence store, its publisher send calls communicate outbound messages to the store, as well as to the endpoint’s regular transports. Depending upon application requirements, the publisher send call can also wait for the store to confirm that it has received and stored each message. Different sequences of these subtask elements produce different qualities of service.

Administrators must select the publisher mode that best suits the application’s needs.

Persistence Store Publisher Modes

Publisher Mode	JSON Attributte	Description
Store - Send	store_send_noconfirm	Highest throughput. Minimal message latency. More robust delivery than regular reliability. Send the message to the store. Do not wait for confirmation. Send the message on the endpoint’s transports. There is no back pressure from the persistence service to the producer application. As a result the producer must ensure that it does not send faster than the persistence services can replicated data on the network (or write it to disk, if disk persistence is enabled). Data can be lost if the connection between the producer and the persistence services is broken for any reason while the producer is sending. This includes network failures and restarts or upgrades of the persistence services.
Store - Confirm - Send	store_confirm_send	Guarantees delivery in exchange for lower throughput and higher message latency. If the send call succeeds, then the store guarantees that the appropriate durable subscribers will eventually receive the message. Conversely, if the store operation fails, the send call also fails, and subscribers do not receive the message through direct transports, nor from the store. The exact behavior depends on the send policy. See . Send the message to the store. Wait for the cluster to confirm storage. Send the message on the endpoint’s transports. There is back pressure from the persistence service to the producer application. The producer will automatically be throttled to a sustainable data rate.

Publisher Mode and Send Policy (Administrators)

Administrators set the publisher's mode when configuring a store. The publisher mode is either store_confirm_send, which offers maximum delivery assurance, or store_send_noconfirm, which offers minimal delivery assurance.

Applications may set the publisher's send policy when creating a publisher object. In addition, administrators may set a default send policy in the realm configuration. For the publisher send policy realm properties, see the following web API topics:

• Realm Definition and Properties

• GET realm/properties

• POST realm/properties

The send policy may be inline or non-inline. In general inline send offers better latency, while non-inline send offers better throughput.

When the publisher mode is store_send_noconfirm, the send call returns immediately, regardless of the send policy. The application is not notified as to whether the message was persisted or lost. In this case, the non-inline send policy may offer somewhat improved throughput in exchange for higher latency.

When the publisher mode is store_confirm_send, the FTL library will attempt to persist the message for the publisher's retry duration. The retry duration can be set by the application. Administrators may set a default value in the realm configuration. See the Realm Properties Details Panel, sectionRealm Properties Details Panel.

If the publisher mode is store_confirm_send, and the send policy is inline, then the send call will block until the message is persisted, or the retry duration has elapsed. If the FTL library could not ensure that the message was persisted, an exception is raised by the send call. This is a synchronous send call, where performance is tied directly to the latency to the persistence service. It may be necessary to use the batched send call (tibPublisher_SendMessages), or multiple publishers in parallel, to achieve acceptable performance.

If the publisher mode is store_confirm_send, and the send policy is non-inline, the send call may return immediately, provided that the maximum batch count has not yet been reached. The application may set the maximum batch count. See the Development guide, Publisher Mode and Send Policy.

When the send policy is non-inline, the FTL library attempts to persist the message in the background for the publisher's retry duration. If the latency to the persistence service is large, a non-inline send may offer a substantial improvement in throughput compared to inline send. However, failures are signaled to the application asynchronously, and handling failures may require a more sophisticated application.

If using a non-inline send, it is critical that the application flushes or closes the publisher before exiting. If the application merely exits, the send call may not be complete, and the message may be lost.