Setting Up Feed Engine

Feed Engine concept encapsulates network-related aspects to let Handler focus on market data processing. It also provides advanced facilities on utilizing system resources used by the Handler to achieve best performance and latency characteristics.

Previously, all Handler instances were isolated between each other and thus system resources were allocated exactly for particular instance needs. That caused certain inefficiency in terms of resources utilization. For example, each Handler used from one to two threads to manage incoming market data processing. As a result, number of threads used by multiple Handler instances was multiplied by number of those instances and significantly exceeded effective amount of resources needed to solve market data processing task.

To make things more efficient, concept of Feed Engine was involved. Since recent release Feed Engine machinery used by Handler to receive and process market data. Single instance of Feed Engine can be shared across multiple Handler instances.

Using Feed Engine

Feed Engine concept is represented by OnixS::EuroTLX::MarketData::GTP::FeedEngine class. Feed Engine events are reported through instance of OnixS::EuroTLX::MarketData::GTP::FeedEngineListener class, associated with the Feed Engine instance at constructing stage.

Following code sample depicts primary aspects of using Feed Engine with two Handler instances:

// STEP 1: is to set configuration parameters.
FeedEngineSettings feedEngineSettings;

feedEngineSettings.threadsCount(NUMBER_OF_WORKING_THREADS);

// STEP 2: is to construct shared feed engine.
FeedEngine feedEngine(feedEngineSettings);

// STEP 3: is to bind feed engine to Handler instances.
handler1.bindFeedEngine(feedEngine);
handler2.bindFeedEngine(feedEngine);

Note

Market data processing is done inside of working threads managed by Feed Engine. Size of internal thread pool is defined by OnixS::EuroTLX::MarketData::GTP::FeedEngineSettings::threadCount parameter.

Feed Engine Events

All Feed engine events are encapsulated into OnixS::EuroTLX::MarketData::GTP::FeedEngineListener class interface. OnixS::EuroTLX::MarketData::GTP::FeedEngine class accepts instance of listener upon construction.

Following table uncovers Feed Engine events:

Event>	Description
OnixS::EuroTLX::MarketData::GTP::FeedEngineListener::onFeedEngineThreadBegin	Invoked by Feed Engine's working thread before entering master processing loop. Event callback is invoked in context of working thread allowing subscriber to perform thread-specific turning like setting affinity or priority for the thread.
OnixS::EuroTLX::MarketData::GTP::FeedEngineListener::onFeedEngineThreadEnd	Invoked by Feed Engine when 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.
OnixS::EuroTLX::MarketData::GTP::FeedEngineListener::onFeedEngineThreadIdle	Invoked by Feed Engine when working thread is idle. At active phase, Feed Engine working thread is running market data processing loop. Working thread may wait for incoming market data using appropriate I/O operation. If there were no incoming data detected for a certain time interval (defined by OnixS::EuroTLX::MarketData::GTP::FeedEngineSettings::dataWaitTime parameter), working thread raises given event with OnixS::EuroTLX::MarketData::GTP::FeedEngineThreadIdleReasons::DataWaitTimeout as a reason of idle state. It may happens that thread misses entering waiting for incoming data because other threads already doing that for all active feeds and there are no other tasks like processing already received market data are available. In such case working threads spins for a certain time (defined by OnixS::EuroTLX::MarketData::GTP::FeedEngineSettings::redundancySpinTime parameter value) while waiting for any pending tasks to be executed. If no pending tasks were found, working thread enters idle state with OnixS::EuroTLX::MarketData::GTP::FeedEngineThreadIdleReasons::Redundant reason. 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 buffer used for incoming data. Warning 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 a lot of factors including number of binded Handler instances, system capacity, number of allocated working threads, clock resolution and other factors.