Issue using service groups to return realtime or delayed data depending on user access

Options
owen.hynes
owen.hynes Newcomer
in RFA

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 Java Developers Guide/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

Tagged:

Best Answer

  • pimchaya.wongrukun01
    pimchaya.wongrukun01 LSEG
    Answer ✓

    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.

Answers

  • zoya faberov
    zoya faberov ✭✭✭✭✭

    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

  • umer.nalla
    umer.nalla LSEG

    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

  • owen.hynes
    owen.hynes Newcomer

    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?

Categories