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
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.
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.
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.
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.
