Best way to listen to EventQueues in RFA?

Ethan Wong

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

Jirapongse

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.

Gurpreet

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.

Nipat Kunvutipongsak

@Ethan Wong

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.

umer.nalla

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.