This is current expected RFA Java behaviour that it sends the request to available service which is greatest QoS that RFA have at that time. The problem occurs when RFA receives a data request while it has not process the real-time service information in the directory response yet. RFA have only delay service in the list so it sends the request to the delay service.
The solution is the application requests directory explicitly. Then, send the data request after it receives the first directory response in the processEvent(..). This will make sure that RFA has processed all services in the directory response completely so the real-time service will be the first in the list that RFA will select to send the data request to.

Hi @owen.hynes,

I think you need to define QoS ( Quality of Service) per service, as

Raltime for IDN_RDF and UnspecifiedDelayedTimeliness for IDN_DELAY.

You do not need serviceList defined in connection.

When you get the item refresh, print out the attributes, you should see:

"Qos: (RT, TbT)"

Realtime = "RT".

Please let us know how this worked for you,

-Zoya

Hi @owen.hynes

From my understanding of what you are trying to achieve, your config looks a bit over complicated to me.

\Connections\Connection_RealTimeDelay\connectionType = "RSSL"
\Connections\Connection_RealTimeDelay\rsslPort       = "14002"
\Connections\Connection_RealTimeDelay\serverList     = "p2ps1 p2ps2"
\Sessions\Session_RTDelay\connectionList       = "Connection_RealTimeDelay"
\Sessions\Session_RTDelay\serviceGroupList = "IDN_FEED"
\ServiceGroups\IDN_FEED\serviceList = "IDN_RDF,IDN_DELAY"

\ConsumerClient_1\session = "Session_RTDelay"
\ConsumerClient_1\service = "IDN_FEED"

In the above I have combined the Concrete services IDN_RDF and IDN_DELAY into a ServiceGroup providing data from a single consumer facing service 'IDN_FEED'

I have not been able to actually test the above config, but what should happen is that the API requests your instrument - behind the scenes - from IDN_RDF and if the request is rejected (because you are not permissioned to realtime for that instrument), it then requests the same instrument from IDN_DELAY.

Note that you may get a StatusMsg for the realtime instrument that you are not permissioned for - with a StreamState:Open.
If however, the instrument is invalid (and therefore rejected by IDN_DELAY as well) then you would expect a StreamState:Closed in the StatusMsg

Thanks for the replies.

Following extensive testing (using different configurations including the ones mentioed above) and troubleshooting on our side we seem to have narrowed down the problem.

We have 4 servers in our production environment. The issue seems to be isolated to 2 of these servers. We use a Big IP URL to connect in round robin fashion to each server. So it may be a configuration issue on one of the ADS servers.

Using a sample RFA client application, we discovered differences in the ordering of the services returned when the RFA client connects to the various production ADS’s

When connecting to bosXXX and bosXXX (these servers always seem to return realtime information correctly) the available QoS listed by the IDN_FEED service group is:

Service: IDN_FEED

QoS:

Timeliness: RealTime

Rate: Numeric Rate (500)

Timeliness: UnspecifiedDelayedTimeliness

Rate: Numeric Rate (500)

statusText: IDN_RDF (Up), IDN_DELAY (Up) <-- IDN_RDF (realtime)

is shown first

But when connecting to mmkXXX and mmkXXX (these servers randomly return delayed or realtime information), the available QoS listed by the IDN_FEED service group is:

Service: IDN_FEED

QoS:

Timeliness: UnspecifiedDelayedTimeliness

Rate: Numeric Rate (500)

Timeliness: RealTime Rate: Numeric

Rate (500) s

tatusText: IDN_DELAY (Up), IDN_RDF (Up) <-- IDN_DELAY is shown first

We suspect the ordering difference of the services, in response to RFA client requests, might be leading into some of the issues we are seeing. Can you verify if these ordering differences are expected, or if there are bugs with the RFA client?