RFA Subscription

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

Find more posts tagged with

trep

rfa

rfa-api

Accepted answers

Nipat Kunvutipongsak

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!

All comments

Nipat Kunvutipongsak

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

Hope this helps!

prakash.chellappa

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

Nipat Kunvutipongsak

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.

ganesh.shivshankar

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

Nipat Kunvutipongsak

@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.

EXPLORE OUR SITES