Hi
We noticed that we are recving far too many updates from RMDS. We subscribe for Future RIC GCJ8 FID 22
Subscription message we send to RMDS is as below
MESSAGE Msg MsgType: MsgType.REQUEST Msg Model MsgType: MARKET_PRICE Indication Flags: VIEW Hint Flags: HAS_ATTRIB_INFO | HAS_PRIORITY Priority: 1,1 AttribInfo ServiceName: IDN_SELECTFEED Name: GCJ8 NameType: 1 (RIC) Payload: 36 bytes ELEMENT_LIST ELEMENT_ENTRY :ViewType: 1 ELEMENT_ENTRY :ViewData: ARRAY ARRAY_ENTRY: 22
Responses we recd
2018-02-08 11:34:57.130 [EventQueueDispatcher-0] INFO com.test.rfa.ConsumerClient - Fields to Update {22=1315.8000000000002}
2018-02-08 11:34:59.457 [EventQueueDispatcher-0] INFO com.test.rfa.ConsumerClient - Fields to Update {22=1315.8000000000002} 2018-02-08 11:34:59.463 [EventQueueDispatcher-0] INFO com.test.rfa.ConsumerClient - Fields to Update {22=1315.8000000000002}
2018-02-08 11:34:59.464 [EventQueueDispatcher-0] INFO com.test.rfa.ConsumerClient - Fields to Update {22=1315.8000000000002}
Above logs are from the Clients callback method. You would see RMDS keeps distributing the messages even when the values on the FID did change.
Can you pls advice why it is?
Thanks
Hello @prakash.chellappa,
I've tried to compare the subscription result between full updates and partial view update. It seems like there are some other associated BID fields that were updated.
Considering the partial GCJ8 result:
BatchViewItemManager.processEvent: Received Item Event... 2018-02-08 11:29:32.284+0700 MESSAGE Msg Type: MsgType.UPDATE_RESP Msg Model Type: MARKET_PRICE Indication Flags: Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM SeqNum: 44992 RespTypeNum: 1 (QUOTE) Payload: 13 bytes FIELD_LIST FIELD_ENTRY 22/BID: 1312.6 BatchViewItemManager.processEvent: Received Item Event... 2018-02-08 11:29:32.293+0700 MESSAGE Msg Type: MsgType.UPDATE_RESP Msg Model Type: MARKET_PRICE Indication Flags: Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM SeqNum: 45008 RespTypeNum: 1 (QUOTE) Payload: 13 bytes FIELD_LIST FIELD_ENTRY 22/BID: 1312.6
At the SeqNum: 44992 of GCJ8, the full data are as follows:
ItemManager.processEvent: Received Item Event... 2018-02-08 11:29:32.296+0700 MESSAGE Msg Type: MsgType.UPDATE_RESP Msg Model Type: MARKET_PRICE Indication Flags: Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM | HAS_SEQ_NUM SeqNum: 44992 RespTypeNum: 1 (QUOTE) AttribInfo ServiceName: API_ELEKTRON_EPD_RSSL ServiceId: 2115 Name: GCJ8 NameType: 1 (RIC) Payload: 71 bytes FIELD_LIST FIELD_ENTRY 22/BID: 1312.6 FIELD_ENTRY 30/BIDSIZE: 12 FIELD_ENTRY 3855/QUOTIM_MS: 16171898 FIELD_ENTRY 3517/BID_TIME1: 04:29:31 FIELD_ENTRY 4150/BID_TIM_MS: 16171898 FIELD_ENTRY 6579/BID_COND_N: 0E FIELD_ENTRY 6544/NO_BIDORD1: 8 FIELD_ENTRY 1697/SPARE_TS1: 04:29:31 FIELD_ENTRY 118/PRC_QL_CD: OPN (160) FIELD_ENTRY 133/MKT_ST_IND: BBO (16) FIELD_ENTRY 1021/SEQNUM: 29621787 FIELD_ENTRY 3887/SEQNUM_QT: 29621787
And this is the other full tick for SeqNum: 45008 of GCJ8:
ItemManager.processEvent: Received Item Event... 2018-02-08 11:29:32.299+0700 MESSAGE Msg Type: MsgType.UPDATE_RESP Msg Model Type: MARKET_PRICE Indication Flags: Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM | HAS_SEQ_NUM SeqNum: 45008 RespTypeNum: 1 (QUOTE) AttribInfo ServiceName: API_ELEKTRON_EPD_RSSL ServiceId: 2115 Name: GCJ8 NameType: 1 (RIC) Payload: 71 bytes FIELD_LIST FIELD_ENTRY 22/BID: 1312.6 FIELD_ENTRY 30/BIDSIZE: 13 FIELD_ENTRY 3855/QUOTIM_MS: 16171914 FIELD_ENTRY 3517/BID_TIME1: 04:29:31 FIELD_ENTRY 4150/BID_TIM_MS: 16171914 FIELD_ENTRY 6579/BID_COND_N: 0E FIELD_ENTRY 6544/NO_BIDORD1: 9 FIELD_ENTRY 1697/SPARE_TS1: 04:29:31 FIELD_ENTRY 118/PRC_QL_CD: OPN (160) FIELD_ENTRY 133/MKT_ST_IND: BBO (16) FIELD_ENTRY 1021/SEQNUM: 29621790 FIELD_ENTRY 3887/SEQNUM_QT: 29621790
So, you may notice that some other BID aspects such as BIDSIZE, QUOTIME_MS, etc. were changed. However, the application just filters only BID. That's why it can be perceived why the feed sent duplicate BID value updates.
Hope this helps!
Hi
Thanks for the reply.I understand how it works now.
Is there a way to suppress these and get an update only if the BID field changes
Thanks
Unfortunately, it needs to be the application logic to track and compare a value changed. As far as I know, there is no feature or capability to do that in both API and the infrastructure.
Does the SFC model also work the same way? i.e. if related FIDs changes the update is propagated back to the client?
This behavior should be the same across real-time APIs (SFC, RFA, ElektronSDK).
To clarify this, whenever the APIs receive an update message that contains an interesting field, the APIs' underlying layer will pass the field to the application layer regardless whatever its value is because it just checks whether the interesting field exists in the update message or not. It doesn't cover or consider the field's value at all.
The only scenario that APIs process fields values is when the application wants to decode fields value to the desired format.
Hope this helps.