Java ETA Reactor Programming model for managing RCC Channel A & B hosts

Paul.Wuethrich2

What is the recommended reactor-to-refinitiv host model when building a client side contributor for RCC via the Java-based ETA/Reactor API:

1. Create a single reactor and invoke connect for each channel even though channel A & B are on different Refinitiv hosts?

2. Create a reactor for each channel since they're connecting to different hosts?

The reason for the question is that we're trying to understand some run-time session management issues whereby:

-If we see start to see latency related problems our application is able to seamlessly switch from sending data from one channel (host A) to another channel (host

-However, if we run into session management issues whereby we receive either a CLOSED_RECOVER stream state (value = 3) or a CLOSED stream state (value = 4); it seems like we are NEVER able to switch flow from one channel to another and the entire reactor has to be shutdown and recreated. Is this expected or are missing something in our implementation of the API?

Jirapongse

@Paul.Wuethrich2

I found that ETA Reactor will not recover CLOSED and CLOSED_RECOVER streams. Therefore, the application itself needs to recover the streams.

However, ETA Reactor with the watchlist feature can recover CLOSED_RECOVER streams.

If you are an RDC named user, you can contact the RDC support team directly via Contact Premium support to investigate the issue.

Jirapongse

@Paul.Wuethrich2

From the question, I assume that the application would like to connect to host A and Host B simultaneously.

Both methods are valid. An application can leverage multiple Reactor instances to scale across multiple cores and distribute their ReactorChannels as needed

I think we need to focus on the CLOSED_RECOVER stream state (value = 3) or a CLOSED stream state (value = 4). Is it the closed stream state for a login or tunnel stream?

Paul.Wuethrich2

Thanks for the reply.

The intermittent CLOSED_RECOVER & CLOSED status messages occurring as part of contributing updates via the active tunnel stream at a steady rate.