Issue using service groups to return realtime or delayed data depending on user access
I am using the RFA Java API 8 (8.0.1.E2) to retrieve snapshot realtime and delayed quotes. The behavior I require is for the ADS to return real time quote if a user is authorized for realtime, if the user is not authorized then return delayed quote.
According to the documentation (https://docs-developers.thomsonreuters.com/1493738996143/4730/Docs/WebDocs/wwhelp/wwhimpl/js/html/wwhelp.htm#href=RFA%20Java%20Developers%20Guide/RFAJ_DeveloperGuide.1.112.html) I should be able to use a service group to achieve this behavior and I have designed my solution around this assumption. However I have seen lately that the response from the service group is randomly realtime and delayed. So a user who is set up in dacs for both realtime and delayed for a specific exchange randomly gets realtime quotes and delayed quotes. Is there something missing in my configuration for this? Or is it a missing configuration on the ADS?
Configuration:
_System.EventQueue.batchingEnabled=false
_System.EventQueue.batchsize=100
_System.EventQueue.flushTimerInterval=10
_System.Services.IDN_DELAY.feedName=IDN_DELAY
_System.Services.IDN_RDF.feedName=IDN_RDF
_System.ServiceGroups.ServiceGroupRealtimeDelayed.serviceList=IDN_RDF,IDN_DELAY
fimt.Sessions.rmds.connectionList=fimt::RSSLConnection
fimt.Sessions.rmds.serviceGroupList=ServiceGroupRealtimeDelayed
fimt.Connections.RSSLConnection.connectionType=RSSL
fimt.Connections.RSSLConnection.serverList=*****
fimt.Connections.RSSLConnection.portNumber=*****
fimt.Connections.RSSLConnection.disableDownloadConnectionConfig=true
fimt.Connections.RSSLConnection.logFileName=none
fimt.Connections.RSSLConnection.serviceList=IDN_RDF,IDN_DELAY
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?