Guaranteed Delivery and Persistent Subscribe Pattern

Guaranteed delivery (GD) and persistent subscribe pattern (PSP) are delivery mechanisms that support high availability.

GD and PSP ensure that data continues to be processed when:

The ESP Server fails.
The destination (third-party server) fails.
The destination (third-party server) does not respond for a period of time.

SAP recommends that you use guaranteed delivery rather than persistent subscribe pattern if possible. GD uses CPU and memory resources more efficiently and is more flexible from a development standpoint because it does not force you to decide how many subscribers will be supported when you set it up. However, you might prefer PSP if:

You need to guarantee delivery of data from a delta stream.
You do not want the guaranteed delivery store to be a log store for performance reasons. Using a memory store allows recovery when the client restarts, but not when the project restarts.

Guaranteed Delivery

Guaranteed delivery (GD) uses log stores to ensure that a GD subscriber registered with a GD stream or window receives all the data processed by that stream or window even if the client is not connected when the data is produced. GD is supported on streams and windows (not on delta streams) and each GD stream or window requires a log store.

You can specify GD support for a window in Studio or in the CCL. (See the SAP Event Stream Processor: Studio Users Guide for Studio details or the SAP Event Stream Processor: CCL Reference for CCL details.) A GD window supports multiple GD subscribers as well as both GD and non-GD subscriptions. To use GD:

Assign a log store to every stream and window in the project that cannot be recovered by an upstream provider.
Do at least one of the following:
- Enable GD on any bindings for the project.
- Enable GD on project adapters that support it.
- Use the C++ SDK, the Java SDK, or the .NET SDK to configure publishers sending data to your project to retransmit any data for which they do not receive a commit confirmation.
- Use the C++ SDK, the Java SDK, or the .NET SDK to set up GD subscriptions for client applications. For more information, see the instructions on subscribing with guaranteed delivery in the SAP Event Stream Processor: SDK Guide.

SAP Event Stream Processor projects that have at least one GD-enabled stream or window provide information on GD in two metadata streams:

_ESP_Streams - tells you whether GD is enabled for the stream or window
_ESP_GD_Sessions - lists active and inactive GD sessions, identifies the sequence number of the last event committed for each stream or window a GD session subscribes to and the last update time for an entry, and identifies the user associated with this session (that is, the user who initiated the subscription).

For details on these metadata streams, see the SAP Event Stream Processor: Configuration and Administration Guide.

You can subscribe to the metadata streams using the C++ SDK, the Java SDK, or the .NET SDK. You can also monitor the streams yourself using streamingsubscribe (see the SAP Event Stream Processor: Utilities Guide) or the Studio Server view. Event Stream Processor stores data from the _ESP_GD_Sessions metadata stream in a special metadata log store so it will be available after a crash.

Consistent recovery mode ensures that if the server restarts, it recovers the state of all streams and windows in a project to the last successful checkpoint state—provided you have followed the rules related to assigning streams and windows to log stores. Consistent recovery is achieved by checkpointing all log stores atomically. If any checkpoints fail (which happens, for example, when the server shuts downs in the middle of a checkpoint or there is not enough space in the log stores), Event Stream Processor rolls all the log stores back to the last successful checkpointed state. See the SAP Event Stream Processor: Developer Guide for more information on consistent recovery.

Use the Auto Checkpoint project option to set the number of input transactions that trigger a checkpoint. More frequent checkpoints reduce the risk of data loss; less frequent checkpoints reduce the burden on system resources and may improve performance. Note that the frequency N you set with this option only ensures that a checkpoint happens at least every N transactions. Checkpoints might happen at other times if the system decides that it is necessary or if a publisher issues a commit when the server is running in consistent recovery mode.

Note SAP does not recommend using consistent recovery mode in projects where active-active HA mode is also enabled. Because ESP is nondeterministic, enabling consistent recovery mode on the instances of an active-active project cannot be guaranteed to produce the same data in the primary and secondary instances if there is a failure.

Persistent Subscribe Pattern

You set up PSP for each subscriber individually. Enabling PSP on a data stream or window creates two new elements:

A log window (a Flex operator with a log store)
A truncate window (also called the control window)

The data stream or window on which PSP is enabled and the truncate window plug into the log window. The PSP-enabled stream or window delivers data to the log window. The log window generates a sequence number, takes the opcode from the data, and places them at the beginning of each row of data. The log window sends this data to the output adapter that is attached to it. The adapter, taking advantage of guaranteed processing features on the subscribing system (where the data will be consumed), determines when to notify the truncate window that rows marked for deletion have been processed by the subscriber. When it receives this notification, the truncate window informs the log window that the data that has been processed and the log window removes the data from its log store.

Figure 1: Per-Subscriber PSP Overview

PSP Overview

Input adapters support persistent subscribe pattern (PSP) using facilities provided by the data source. Output adapters use PSP directly.

The WebSphereMQ Input and Output adapter, all JMS Input and Output adapters, and the TIBCO Rendezvous adapter all support PSP. These adapters have specific PSP and GD parameters that are unique to them. Examples for enabling PSP in one of the JMS CSV Output adapters and the WebSphere Output adapter are located in <STREAMING_HOME>/examples/ccl/JmsOutBoundAdapterWithGDSupport and <STREAMING_HOME>/examples/ccl/WsmqOutBoundAdapterWithGDSupport respectively.