Setting Up Feed Engine

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 OnixS::B3::MarketData::UMDF::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 bind feed engine to Handler instances.
handler1.bindFeedEngine(feedEngine);
handler2.bindFeedEngine(feedEngine);

The SDK offers the OnixS::B3::MarketData::UMDF::FeedEngineThreadPool service that cyclically invokes the OnixS::B3::MarketData::UMDF::FeedEngine::process method of the associated OnixS::B3::MarketData::UMDF::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 OnixS::B3::MarketData::UMDF::FeedEngineThreadPoolListener class. Subscribing to events is done during the service construction.

Feed Engine Events

All Feed engine events are encapsulated into OnixS::B3::MarketData::UMDF::FeedEngineThreadPoolListener class interface. OnixS::B3::MarketData::UMDF::FeedEngineThreadPool class accepts the instance of the listener upon construction.

The following table uncovers Feed Engine events:

Event>	Description
OnixS::B3::MarketData::UMDF::FeedEngineThreadPoolListener::onFeedEngineThreadBegin	It is invoked by Feed Engine Pool's working thread before entering the master processing loop. Event callback is invoked in the context of a working thread allowing a subscriber to perform thread-specific turning like setting affinity or priority for the thread.
OnixS::B3::MarketData::UMDF::FeedEngineThreadPoolListener::onFeedEngineThreadEnd	It is invoked by the Feed Engine Pool when a working thread is about to end. Event callback is invoked in the context of a working thread allowing a subscriber to perform thread-specific cleanup like deleting data stored in thread local storage.
OnixS::B3::MarketData::UMDF::FeedEngineThreadPoolListener::onFeedEngineThreadIdle	It is invoked by the Feed Engine Pool when a working thread is idle. At an active phase, the Feed Engine working thread is running a market data processing loop. A working thread may wait for incoming market data using appropriate I/O operation. Event callback also exposes a parameter-variable whose value represents the time interval the 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. The value of a parameter can be modified inside the callback body. Note It's not recommended to change sleep time interval when working thread entered an idle state after waiting for incoming data to avoid overflow of a buffer used for incoming data. Warning There's no predictability in firing a 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 the number of Handler instances bound, system capacity, the number of allocated working threads, clock resolution, and other factors.