Source Directory Messages and Item Status

We have a consumer program (UPA) that subscribes to Source Directory information as well as making individual item subscriptions.
Current functionality is to set status for all items to Stale when receiving a Source Directory Update for the relevant service saying that service is DOWN.
Items status is returned to OK again when receiving a REFRESH message with that status, but we have seen that those are not always received.
Is it correct to assume that receipt of any RSSL_MC_UPDATE type message for an item means that status is now OK?
This problem is only occurring for a specific type of failure/recovery scenario where an ADH is restarted (fails over to buddy). In that case, on our TREP we see extra Source Directory messages approx. one minute after the initial failure/recovery which inform us that the service is down, even though it really isn't. Can you explain this behaviour on TREP and advise on how it might be remedied?
Best Answer
-
Thanks for your reply Jirapongse.
In fact, after a bit of further investigation we found that the root cause of our issue here was misinterpreting Source Directory messages. The program was making the assumption that all Source Directory messages contain service state info, when in fact many do not. This was causing it to misinterpret some Source Directory updates as indicating a service down state change when there was no state change, just an update to other info.
0
Answers
-
I have done a quick test on EMA API in order to verify how EMA API handles service up and down messages.
When EMA API receives a service down message, it fan-outs the Open/Suspect status messages to all subscribed items of that service.
<updateMsg domainType="RSSL_DMT_SOURCE" streamId="2" containerType="RSSL_DT_MAP" flags="0x80 (RSSL_UPMF_DO_NOT_CONFLATE)" updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" dataSize="72"> <dataBody> <map flags="0x0" countHint="0" keyPrimitiveType="RSSL_DT_UINT" containerType="RSSL_DT_FILTER_LIST" > <mapEntry flags="0x0" action="RSSL_MPEA_UPDATE_ENTRY" key="4916" > <filterList containerType="RSSL_DT_ELEMENT_LIST" countHint="0" flags="0x0"> <filterEntry id="2" action="RSSL_FTEA_SET_ENTRY" flags="0x0" containerType="RSSL_DT_ELEMENT_LIST"> <elementList flags="0x8 (RSSL_ELF_HAS_STANDARD_DATA)"> <elementEntry name="ServiceState" dataType="RSSL_DT_UINT" data="0"/> <elementEntry name="AcceptingRequests" dataType="RSSL_DT_UINT" data="1"/> <elementEntry name="Status" dataType="RSSL_DT_STATE" dataState="RSSL_DATA_SUSPECT" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="" /> </elementList> </filterEntry> </filterList> </mapEntry> </map> </dataBody> </updateMsg> <!-- End Message (Channel IPC descriptor = 272) --> StatusMsg streamId="5" domain="MarketPrice Domain" state="Open / Suspect / None / ''" name="1TUU8" serviceId="4916" serviceName="DIRECT_FEED" StatusMsgEnd
The items are back to Open/Ok state after receiving the refresh messages with Open/OK state.
<refreshMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="4" containerType="RSSL_DT_FIELD_LIST" flags="0x1D8" groupId="1" seqNum="0" qosDynamic="0" qosRate="1" qosTimeliness="1" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="Item Refresh Completed" dataSize="64"> <key flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)" serviceId="4916" name="1TUU8" nameType="1"/> <dataBody> <fieldList flags="0x8 (RSSL_FLF_HAS_STANDARD_DATA)"> ... </fieldList> </dataBody> </refreshMsg> <!-- End Message (Channel IPC descriptor = 272) --> RefreshMsg streamId="5" domain="MarketPrice Domain" RefreshComplete ClearCache state="Open / Ok / None / 'Item Refresh Completed'" itemGroup="00 01" qos="RealTime/TickByTick" seqNum="0" name="1TUU8" nameType="1" serviceId="4916" serviceName="DIRECT_FEED" Payload dataType="FieldList" FieldList ... FieldListEnd PayloadEnd RefreshMsgEnd
The update message can't be used to indicate the status of the item. In your scenario, please enable RSSL tracing in UPA. You would like to verify the messages sent and received by the application.
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
- 684 Datastream
- 1.4K DSS
- 615 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 248 ETA
- 554 WebSocket API
- 37 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 642 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
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 192 TREP Infrastructure
- 228 TRKD
- 915 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 89 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛