question

Upvotes
Accepted
45 1 3 6

RFA Subscription

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

treprfarfa-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
Accepted
1.9k 6 9 16

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!

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

Upvotes
45 1 3 6

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

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.

Upvotes
1 1 0 5

Does the SFC model also work the same way? i.e. if related FIDs changes the update is propagated back to the client?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

@ganesh.shivshankar,

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.

Click below to post an Idea Post Idea