Bad directory data with multiple clients

Hi.
I'm connecting directly to our Elektron Edge Device, which has two services, ELEKTRON_AD and ELEKTRON_DD. I'm running software that instantiates multiple RFA client objects (derived from rfa::common::Client), using the same Session configuration. I'm using C++ RFA7.6.2.L1, I've also tried 7.6.1.E1, and 8.0.1.L1 (all win-shared, VS2013, windows 7).
The problem is that second and subsequent clients receive incorrect directory information.
To demonstrate the problem, example program "Consumer" (directory \Examples\Consumer in C++ RFA version 7.6.2.L1.win-shared) can be modified to show the problem. Modify Application.cpp, at line 157 insert "::Sleep(15000);". This makes the second and subsequent clients start up after a delay. Note that the problem doesn't manifest without the delay between clients starting up.
When configured with multiple clients, only the first client gets the expected directory data:
ConsumerClient_10 :
/Directory cache (Msg Refresh)
Service: ELEKTRON_AD last action: Add
INFO:
ServiceId: 265
Vendor: Reuters
IsSource: False
Capabilities:
Dictionary
MarketPrice
MarketByOrder
MarketByPrice
MarketMaker
SymbolList
Invalid mmt(11)
Invalid mmt(13)
Invalid mmt(18)
Invalid mmt(19)
Invalid mmt(20)
Invalid mmt(21)
Invalid mmt(23)
Invalid mmt(24)
Invalid mmt(25)
Invalid mmt(26)
Invalid mmt(28)
Invalid mmt(126)
DictionariesProvided:
RWFFld
RWFEnum
DictionariesUsed:
RWFFld
RWFEnum
QoS:
Timeliness: RealTime
Rate: TickByTick
SupportsQosRange: No
SupportsOutOfBandSnapshots: Yes
AcceptingConsumerStatus: No
STATE:
ServiceState: Up (Yes)
AcceptingRequests: Yes
Status:
dataState: Ok
streamState: Open
statusCode: None
statusText: Up
Second and subsequent clients get "bad" directory data:
ConsumerClient_11 :
/Directory cache (Msg Refresh)
Service: UNKNOWN last action: Add
INFO:
ServiceId: 265
Vendor:
IsSource: False
Capabilities:
DictionariesProvided:
DictionariesUsed:
QoS:
Timeliness: RealTime
Rate: TickByTick
SupportsQosRange: No
SupportsOutOfBandSnapshots: Yes
AcceptingConsumerStatus: No
STATE:
ServiceState: Down (No)
AcceptingRequests: No
/End Directory cache (Msg Refresh)
My application configuration, which I would have attached but for whatever reason attachment upload isn't working:
\ConsumerClient_10\session = "Session1"
\ConsumerClient_10\service = "ELEKTRON_AD"
\ConsumerClient_10\itemList = "BHP.AX"
\ConsumerClient_10\msgModelRequestType = "marketPrice"
\ConsumerClient_10\msgModelDefaultDisplay = true
\ConsumerClient_10\userName = "treprt"
\ConsumerClient_10\appId = "256"
\ConsumerClient_10\InstanceId = "<Instance Id>"
\ConsumerClient_10\loadLocalDicts = false
\ConsumerClient_10\fieldDictionaryFilename = "./RDMFieldDictionary"
\ConsumerClient_10\enumDictionaryFilename = "./enumtype.def"
\ConsumerClient_10\directoryReqFilter = "SERVICE_INFO_FILTER | SERVICE_STATE_FILTER"
\ConsumerClient_10\SourceMirroringMode = "0"
\ConsumerClient_10\useEventQueue = true
\ConsumerClient_11\session = "Session1"
\ConsumerClient_11\service = "ELEKTRON_AD"
\ConsumerClient_11\itemList = "CBA.AX"
\ConsumerClient_11\msgModelRequestType = "marketPrice"
\ConsumerClient_11\msgModelDefaultDisplay = true
\ConsumerClient_11\userName = "treprt"
\ConsumerClient_11\appId = "256"
\ConsumerClient_11\InstanceId = "<Instance Id>"
\ConsumerClient_11\loadLocalDicts = false
\ConsumerClient_11\fieldDictionaryFilename = "./RDMFieldDictionary"
\ConsumerClient_11\enumDictionaryFilename = "./enumtype.def"
\ConsumerClient_11\directoryReqFilter = "SERVICE_INFO_FILTER | SERVICE_STATE_FILTER"
\ConsumerClient_11\SourceMirroringMode = "0"
\ConsumerClient_11\useEventQueue = true
\ConsumerClient_12\session = "Session1"
\ConsumerClient_12\service = "ELEKTRON_AD"
\ConsumerClient_12\itemList = "CBA.AX"
\ConsumerClient_12\msgModelRequestType = "marketPrice"
\ConsumerClient_12\msgModelDefaultDisplay = true
\ConsumerClient_12\userName = "treprt"
\ConsumerClient_12\appId = "256"
\ConsumerClient_12\InstanceId = "<Instance Id>"
\ConsumerClient_12\loadLocalDicts = false
\ConsumerClient_12\fieldDictionaryFilename = "./RDMFieldDictionary"
\ConsumerClient_12\enumDictionaryFilename = "./enumtype.def"
\ConsumerClient_12\directoryReqFilter = "SERVICE_INFO_FILTER | SERVICE_STATE_FILTER"
\ConsumerClient_12\SourceMirroringMode = "0"
\ConsumerClient_12\useEventQueue = true
I haven't included my RFA.cfg file, because obviously its contents are unique to my environment.
Notice the service name is "UNKNOWN". If you inspect the contents of the directory message more closely, it seems to contain what looks like "stale" data.
Our organisation has an RHS solution as well, and the problem does not manifest there - it only occurs when directly connecting to the Elektron Edge Device.
Because of the architecture of our application and our deployment environment, all clients need to use the same login/Session.
Is the above a bug in RFA? Is there something fundamentally wrong with my use of RFA here?
Thanks in advance!
Best Answer
-
The way RFA API work is, if you use the same login credentials for multiple Session/OMMConsumer, RFA will not re-send the login and source directory request but it will use the information from RFA internal cache.
However, it seems that getting a group status message from Elektron Edge Device will break RFA internal directory cache.
This issue has been reported to development team.0
Answers
-
Hi Rodney
I'm using both 7.6.2.L1 and 8.0.1.L1 but I was unable to reproduce the problem.
Since the problem occurs only when you connect directly to your Elektron Edge Device, you should try enable tracing and see if there is any unusual messages sent from Elektron Edge Device.
Otherwise, if you have the TR Developer Connect membership, then you should submit a TRDC ticket. The support team should be able to help you investigate.
https://customers.reuters.com/developer/crmcontactus/support.aspx
0 -
Rodney,
The Readme file of the Consumer example has clearly indicated each consumer client must have it's own session and event queue. Your configuration shows all three consumer clients use the same session "Session1". If your connection is DACS enabled, the second and third client will receive login error because you can only login to the server once at a time. I tested the consumer with multiple clients connecting to server with either DACS enabled or disabled and they all worked fine with proper configuration. If you still encounter the same issue after changing your configuration, please turn on trace in the configuration, re-run the application and send the complete output file together with the source files to TRDC as suggested by Warat.
0 -
Thanks. I have enabled tracing, and see no unusual messages. Second and subsequent directory requests don't hit the wire.
As per Steven's reply below, I tried configuring multiple sessions (one per client), each using the same login credentials. I saw the same problem.
Unfortunately I don't have a TRDC membership.
0 -
Could you please attached the trace file?
The way RFA API work is, if you use the same login credentials for multiple Session/OMMConsumer, it will not re-send the login and source directory request. The login and source directory response you get from the second login is from RFA internal cache.
Your issue looks like RFA internal cache corrupt. But since it worked on other providers (including mine), then I suspect that your Elektron Edge Device source directory response sent something special that corrupt the cache.
0 -
Thanks for clarifying! I re-ran the test Consumer app this morning, and I have attached the XML log (zipped).
My rfa.cfg had the following logging enabled, I hope that was sufficient:
\Connections\Connection_RSSL\traceMsgTofile = true
\Connections\Connection_RSSL\traceMsgDomains = "all0 -
We aren't using DACS, all our applications use the same login. Multiple applications logging in concurrently works fine - its when this one applications tries to "log in" multiple times that it causes problems.
An older version of our software (possibly RFA6, probably VS2008) used to work just fine doing just this.
0 -
Thanks @rodney.morris
I managed to reproduce the problem. Please see my answer below.
0 -
Many thanks for your time and effort!
0 -
Update
This issue has been fixed in RFA 8.1.0.L1.
0 -
Confirmed fixed in RFA 8.1.0.L1.
Thank you.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 690 Datastream
- 1.4K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 25 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 279 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 716 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛