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
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛