Force.com Streaming API Developer Guide

Getting Started with Force.com Streaming API
Introducing Streaming API
Push Technology
Bayeux Protocol, CometD, and Long Polling
Streaming API Terms
How the Client Connects
Message Reliability
Message Durability
Quick Start Using Workbench
Code Examples
Using Streaming API
Generic Streaming
Reference
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Message Reliability

As of API version 37.0, Streaming API provides reliable message delivery by enabling you to replay past events. In API version 36.0 and earlier, clients might not receive all messages in some situations.

In API version 37.0 and later, Streaming API stores events for 24 hours, enabling you to replay past events. With durable streaming, messages aren’t lost when a client is disconnected or isn’t subscribed. When the client subscribes again, it can fetch past events that are within the 24-hour retention period. The ability to replay past events provides reliable message delivery.

In API version 36.0 and earlier, Streaming API doesn’t guarantee reliable delivery of notifications. When not using durable streaming, streaming servers don’t maintain client state nor keep track of what’s delivered. The client might not receive messages for several reasons, including:
  • When a client first subscribes or reconnects, it might not receive messages that were processed while it wasn’t subscribed to the channel.
  • When a client disconnects and starts a new handshake, it could be working with a different application server, so it receives only new messages from that point on.
  • Some events are dropped when the system is being heavily used.
  • If an application server is stopped, all messages being processed but not yet sent are lost. Clients connected to that application server are disconnected. To receive notifications, the client must reconnect and subscribe to the topic channel.

Message Delivery Considerations

Note the following for all API versions.

Multiple Notifications Within the Same Apex Transaction
If multiple PushTopic notifications are sent for the same record within the same Apex transaction, only the last notification is sent. The earlier notifications are suppressed. For example, suppose a PushTopic is set up for the creation and update of Contact records, and the PushTopic query selects fieldA. If a contact is inserted and then an Apex trigger updates fieldA, only the notification for the update is sent. No notification is sent for the contact creation.