Describes how to create several EMDI handlers explicitly without using a handler manager.
Applications can create EmdiHandler instances directly instead of using EmdiHandlerManager. This approach is useful when the application needs explicit control over handler settings, listener registration, filters, logging names or lifetime of each handler instance.
Start with RdiHandler and wait until it has processed the full reference data snapshot. The RDI handler provides EMDI interface descriptors through findEmdiDescriptors. The descriptor list contains the technical feed configuration and filters needed to create market data handlers for the requested products.
For each descriptor returned by findEmdiDescriptors, create an EmdiHandlerSettings instance, configure it with the descriptor data, and construct the handler from it. The remaining descriptor data is then applied directly on the handler:
Bind every handler to a FeedEngine instance with EmdiHandler::bindFeedEngine, register the required listeners, and then start the handlers. The handlers may share one feed engine and thread pool, or the application may allocate separate feed engines when it needs independent threading and resource allocation.
Using multiple feed engines lets the application group handlers and serve each group with a dedicated FeedEngineThreadPool. Configure each pool with FeedEngineThreadPoolSettings, including threadCount and threadAffinity, to distribute different handler groups across CPU cores. This allows the application to balance CPU load explicitly instead of letting all handlers compete for the same feed engine threads.
The same pattern applies to other market data handlers. For MdiHandler, use findMdiDescriptors and create handlers with MdiHandlerSettings. For EobiHandler, use findEobiDescriptors and create handlers with EobiHandlerSettings. In both cases, copy the feed descriptors from the RDI descriptor, apply the descriptor filters supported by the handler, register the required listeners, bind a feed engine and start each handler explicitly.
Stop all EMDI handlers before destroying them. The RDI handler can be stopped after the reference data snapshot has been cached if the application does not need live reference data updates.
The Advanced Sample demonstrates this workflow.