Slow reader behavior

Occasionally, a client session's data processing may lag behind real-time data. This can happen due to multiple reasons, such as a spike in messaging volume from the venue, network fluctuations between the client and the server, or an inability of the client application to process messages fast enough to keep up with the venue's message flow.

The live API allows clients to configure different behaviors when this happens via the slow_reader_behavior parameter in the Live constructor. This parameter can be set to the values skip or warn, and defaults to skip when not set. This parameter cannot be changed after the session is authenticated.

Skip

If the slow reader behavior is set to skip, whenever the gateway detects a client falling behind real-time data, an ErrorMsg with error code SKIPPED_RECORDS_AFTER_SLOW_READING will be sent to the client and the session will skip records until caught up with real-time data.

This behavior only applies to subscriptions for the following schemas: MBP-1, MBP-10, BBO-1s, BBO-1m, CMBP-1, CBBO-1s, and CBBO-1m. Subscriptions to other schemas will always use the warn behavior.

Warn

If the slow reader behavior is set to warn, whenever the gateway detects a client falling behind real-time data, a SystemMsg with system code SLOW_READER_WARNING will be sent to the client. The session will not skip any records and will attempt to replay every single record in the subscription.

In some cases, setting warn as the slow reader behavior can lead to increasing lag between the session and real-time data.

Data aged out of retention

A replay can fall behind far enough that the data it was reading is removed, i.e. it now exceeds the supported replay window. Sessions whose effective behavior is skip resume from the earliest retained records. Sessions using warn, either by request or because the schema is incompatible with skipping, receive a fatal ErrorMsg with error code REPLAY_DATA_AGED_OUT naming the earliest available start time.