Best way to listen to EventQueues in RFA?

The RFA documentation and examples states to use the EventQueue.dispatch within a loop to keep listening to events. If for example, you were just sending a login request (ie kill when successful) or an adhoc market data request (so just getting a snapshot price and then closing the stream), what is the best way to control the dispatch?
I wouldn't think you would want to listen forever like a subscription but you can't not put it in a loop
Best Answer
-
Refer to RFA Java Developer Guides, RFA supports the following threading models.
1. Callback Model
The Callback Model is used when no event queue is used. RFA will perform callbacks into the application-provided
processEvent() callback for each message received. The application/client code is run by the same thread of execution
as the Session Layer component. This model offers the lowest latency because no queues are used.2. Client Model
The Client Model is used when an event queue is utilised. The application/client code has its own thread of execution.
Messages are retrieved from the event queue by client calls to EventQueue::dispatch(). Typically, client code is
structured in a “dispatch loop,” which is centered around calls to dispatch() to check the event queue for any incoming
messages. This model uses multiple threads and is generally used for high throughput situations.3. Notification Client Model
The notification client model is a variant of the client model. The application has its own thread of execution. However, the
client is notified by a callback from the Session Layer when there is a message to be retrieved from the event queue. This
type of client is less RFA-centric than the Client Model described earlier. It is generally assumed the application is focused
on non-RFA activities and needs to be notified when a message is available to be read. This is considered the
lowest performing RFA configuration.For more information, please refer to section 14.4 Threading Models in RFA Java Developer Guide.
Their usages depend on the design of the application. If the application demands for high throughput, the client model must be used. Then, the application can assign a thread to regularly call EventQueue::dispatch() in order to retrieve the events.
0
Answers
-
Market data server might have multiple responses even for scenarios where application is expecting a single response.
Application can start an event dispatch in a separate thread with "Dispatchable.INFINITE_WAIT" parameter so that blocking thread does not consume any resources.
0 -
You also can create another thread to handle the EventQueue.dispatch() task only, if you think that dispatching events is not the application's main task.
0 -
Hi @Ethan Wong
Another point worth noting; for a Login, you need to continue dispatching messages as long as your app remains connected to the server. This is so that you can continue to receive messages e.g. if you are logged off the server or if the connection goes down etc.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 690 Datastream
- 1.4K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 25 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 279 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 716 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛