Setting Up Feed Engine

Data receiving.

The Feed Engine abstractions encapsulate data receiving aspects to let the handler focus on market data processing. It also provides advanced services for using system resources to achieve the best performance and latency characteristics.

Using the Feed Engine

The Feed Engine logic pushes received market data to the linked Handler instances.

The SocketFeedEngine is the default implementation of the Feed Engine for receiving live network data. It uses standard socket API.

The following code sample shows how to construct an instance of the Feed Engine, link it with the handler instance, and run the Feed Engine logic to let the handler process incoming market data and other events.

    // STEP 1: is to construct a shared feed engine.
    SocketFeedEngine feedEngine;
 
    // STEP 2: is to construct a thread pool for feed engine. The pool will run threads to execute feed engine
    // tasks, such as receiving and processing market data messages, and dispatching them to handlers.
    FeedEngineThreadPoolSettings feedEngineThreadPoolSettings;
    FeedEngineThreadPool pool(feedEngineThreadPoolSettings, &feedEngine);
 
    // STEP 3: is to bind feed engine to Handler instances.
    handler1.bindFeedEngine(feedEngine);
    handler2.bindFeedEngine(feedEngine);

The SDK offers the FeedEngineThreadPool service that cyclically invokes the FeedEngine::process method of the associated FeedEngine instance from a set of threads. This service manages a thread pool. When a class instance is created, it creates working threads.

All events exposed by the service are encapsulated into the FeedEngineThreadPoolListener class. Subscribing to events is done during the service construction.

Feed Engine Events

All Feed engine events are encapsulated into FeedEngineThreadPoolListener class interface. FeedEngineThreadPool class accepts instance of listener upon construction.

The following list uncovers Feed Engine events:

• FeedEngineThreadPoolListener::onFeedEngineThreadBegin is invoked before entering master processing loop. Event callback is invoked in context of working thread allowing a subscriber to perform thread-specific turning like setting affinity or priority for the thread.
• FeedEngineThreadPoolListener::onFeedEngineThreadEnd is invoked when a working thread is about to end. Event callback is invoked in context of working thread allowing subscriber to perform thread-specific cleanup like deleting data stored in thread local storage.
• FeedEngineThreadPoolListener::onFeedEngineThreadIdle is invoked when a working thread is idle. At an active phase, Feed Engine working thread is running market data processing loop. A working thread may wait for incoming market data using appropriate I/O operation. Event callback also exposes parameter-variable whose value represents time interval working thread is suggested to spend sleeping to reduce races between working threads for executing pending tasks (data reception, data processing, etc.) and thus reduce load onto CPU. Value of parameter can be modified inside the callback body.

Note

It's not recommended to change sleep time interval when working thread entered idle state after waiting for incoming data to avoid overflow of a buffer used for incoming data.

Attention

There's no predictability in firing given event by Feed Engine. Each working thread may wait for incoming data or receive incoming data or process data previously received by that or any other threads. Availability of active tasks to be executed by working threads depends on many factors including a number of Handler instances bound, system capacity, a number of allocated working threads, clock resolution and other factors.

The Feed Engine Lifetime

Any market data handler does not manage the lifetime of the binding FeedEngine instance. Therefore, keeping the instance of FeedEngine valid while it's bound to a handler instance is fully user responsibility.