Observed overflow in the RFA Query

edc-notifications

Hi Refinitiv,

We are currently investigating a latency issue being observed by our mutual client north side of our feed handler application. As per our client's TREP Application Development, they observed overflow in the RFA Query, suggesting that we should increase the RFA thread or even segregate it into multiple TCP connections. Would you be able to help on the following queries:

1) Can you please confirm how to increase the RFA thread? Is it how we initialize the RFA API and Sessions?

2) Can we have multiple sessions in RFA config? Would you be able to confirm if adding a second Connection in the RFA.cfg will introduce 2 different TCP connections? For example: \Sessions\Session1\connectionList = "Connection_RSSL,Connection_RSSL_123" \Sessions\Session1\OMMPerfMode = "Latency"

\Connections\Connection_RSSL\connectionType = "RSSL"

\Connections\Connection_RSSL\rsslPort = "14002"

\Connections\Connection_RSSL\serverList = "192.168.220.39" \Connections\Connection_RSSL_123\connectionType = "RSSL" \Connections\Connection_RSSL_123\rsslPort = "14003"

\Connections\Connection_RSSL_123\serverList = "192.168.220.40"

RFA version - rfa8.1

Jirapongse

@edc-notifications

I assume that currently, the application is running in this Single Threaded With an Event Queue model.

There are a total of two threads in this model. The main application thread that is started by the OS is used to send requests and to dispatch events in an event queue. The second thread is used by RFA for adapter and Session Layer processing.

The overflow happens when there are a lot of events in the event queue waiting to be dispatched.

You need to modify the application code to solve this issue. There are two solutions.

1. Multiple event queues

The above picture uses two event queues. Each event queue will be dispatched by its own application thread in order to distribute workload among event queues and increase the application’s performance.

2. Horizontal Scaling

You need to modify the code to acquire multiple sessions. Please refer to this thread for more information.

For more information, please refer to section 17.3 Threading Models in the RFA developers guide.

Next, please see the answers to your questions.

1) Can you please confirm how to increase the RFA thread? Is it how we initialize the RFA API and Sessions?

Each session will have one or two RFA threads depending on the threadModel configuration.

• If set to Single, RFA will optimize the threading model to minimize latency. For response messages, no queue is used by session and adapter; RSSL response messages go directly to clients or clients’ queue.
• If set to Dual, the adapter thread and associated queues will exist for maximizing the throughput of RFA.

However, this configuration can't solve the overflow issue.

You can also increase the number of RFA threads by using horizontal scaling.

2) Can we have multiple sessions in RFA config? Would you be able to confirm if adding a second Connection in the RFA.cfg will introduce 2 different TCP connections?

Yes, you can have multiple sessions configurations in RFA config but the application needs to use them by calling the Session::acquire method.

Yes, adding a second connection in the connectionList will create two TCP connections. However, the number of threads and event queues are still the same.