is there a bug for RFAJ, it misses out volume field (fid 32) in resp_update event

Hi,

I am testing OMM Feed (java implementation) with RIC ".GDAXI". in Response-Update event, I never receive FID 32 (volume). in our C++ implementation, FID 32 is received after decoding message payload. I am wondering if I overlooked something in RFAJ API.

here are some output during test

...

--------------------------------------------------------

timestamp=2017-06-29T10:56:35.117
msg type=UPDATE_RESP
18=[08:56]
100=[680645]
996=[100.00]
997=[30]
6=[12656.90]
56=[0.08]
11=[9.63]
379=[10:56:35]
1067=[10:56:35]
77=[6842]
1021=[1029639290]
---------------------------------------------------
timestamp=2017-06-29T10:56:36.103
msg type=UPDATE_RESP
100=[680668]
996=[100.00]
997=[30]
6=[12656.95]
998=[23]
11=[9.68]
1067=[10:56:36]
77=[6843]
14=[1]
18=[08:56]
56=[0.08]
379=[10:56:36]
1021=[1029654500]

...

please advise, many thanks.

best regards

fengwei

Find more posts tagged with

trep

rfa

rfa-api

Accepted answers

umer.nalla

Hi @fengwei

The RFA APIs are content 'agnostic' and just deliver the payload as received on the wire from the server / provider.

When I consume .GDAXI using RFA Java v8 example QuickStartConsumer I do get FID 32 in an Update. However, I see one Update which only contains FID 32 and then another Update which contains the other FIDs

ItemManager.processEvent: Received Event... MESSAGE
	Msg Type: MsgType.UPDATE_RESP 	Msg Model Type: MARKET_PRICE
	Indication Flags: Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 26848	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 32/ACVOL_1: 32733312
ItemManager.processEvent: Received Event...MESSAGE
	Msg Type: MsgType.UPDATE_RESP	Msg Model Type: MARKET_PRICE
	Indication Flags: 	Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 26864	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 83 bytes
		FIELD_LIST
			FIELD_ENTRY 6/TRDPRC_1: 12608.71
			FIELD_ENTRY 11/NETCHNG_1: -38.56
			FIELD_ENTRY 14/PRCTCK_1: þ (2)
			FIELD_ENTRY 18/TRDTIM_1: 10:12
			FIELD_ENTRY 56/PCTCHNG: -0.30
			FIELD_ENTRY 77/NUM_MOVES: 11399
			FIELD_ENTRY 100/TURNOVER: 978253
			FIELD_ENTRY 379/SALTIM: 12:12:32
			FIELD_ENTRY 975/ACT_FLAG1:  
			FIELD_ENTRY 996/GEN_VAL1: 100.00
			FIELD_ENTRY 997/GEN_VAL2: 30
			FIELD_ENTRY 998/GEN_VAL3: 27
			FIELD_ENTRY 1021/SEQNUM: 1048575580
			FIELD_ENTRY 1067/EXCHTIM: 12:12:32
ItemManager.processEvent: Received Event...MESSAGE
	Msg Type: MsgType.UPDATE_RESP	Msg Model Type: MARKET_PRICE
	Indication Flags: 	Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 26880	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 32/ACVOL_1: 32733721
... and so on

If, however, I consume a different RIC e.g. VOD.L , then I receive FID32 within the same Update message as the other FIDs.

If I use a different API e.g. Elektron Message API C++ version with .GDAXI - I see the same behaviour ie. FID 32 arrive in its own update.

Therefore, this appears to be specific to the particular RIC and not API related.

Please double check that your Update handler is in fact receiving FID 32 in a separate update message.

If you continue to have problems, then please enable the low level trace by setting ipcTraceFlag = 7 in your Consumer Connection in your RFA config (i.e. where you specify the portNumber, connectionType, serverList etc)

This should generate an RFA_RSSL.log file in your working directory - please view that file to confirm if FID 32 is being delivered e.g.

RSSL Client Message RECEIVE: 26
---DATA TRACE---
MESSAGE
	Msg Type: MsgType.UPDATE_RESP 	Msg Model Type: MARKET_PRICE
	Indication Flags: 	Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 49568 	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 32: 0e020c614c

If not, please use one of our example applications such as QuickStartConsumer to recreate the scenario and then raise a ticket with our support team via Contact Us and include details like the exact API version you are using and the above log file.

Or if you do confirm that you are receiving FID 32 in a separate Update and wish to understand why, please contact our Data Content helpdesk (using the same link please) - who should be able to investigate the source of this behaviour.

All comments

umer.nalla

Hi @fengwei

The RFA APIs are content 'agnostic' and just deliver the payload as received on the wire from the server / provider.

ItemManager.processEvent: Received Event... MESSAGE
	Msg Type: MsgType.UPDATE_RESP 	Msg Model Type: MARKET_PRICE
	Indication Flags: Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 26848	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 32/ACVOL_1: 32733312
ItemManager.processEvent: Received Event...MESSAGE
	Msg Type: MsgType.UPDATE_RESP	Msg Model Type: MARKET_PRICE
	Indication Flags: 	Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 26864	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 83 bytes
		FIELD_LIST
			FIELD_ENTRY 6/TRDPRC_1: 12608.71
			FIELD_ENTRY 11/NETCHNG_1: -38.56
			FIELD_ENTRY 14/PRCTCK_1: þ (2)
			FIELD_ENTRY 18/TRDTIM_1: 10:12
			FIELD_ENTRY 56/PCTCHNG: -0.30
			FIELD_ENTRY 77/NUM_MOVES: 11399
			FIELD_ENTRY 100/TURNOVER: 978253
			FIELD_ENTRY 379/SALTIM: 12:12:32
			FIELD_ENTRY 975/ACT_FLAG1:  
			FIELD_ENTRY 996/GEN_VAL1: 100.00
			FIELD_ENTRY 997/GEN_VAL2: 30
			FIELD_ENTRY 998/GEN_VAL3: 27
			FIELD_ENTRY 1021/SEQNUM: 1048575580
			FIELD_ENTRY 1067/EXCHTIM: 12:12:32
ItemManager.processEvent: Received Event...MESSAGE
	Msg Type: MsgType.UPDATE_RESP	Msg Model Type: MARKET_PRICE
	Indication Flags: 	Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 26880	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 32/ACVOL_1: 32733721
... and so on

If, however, I consume a different RIC e.g. VOD.L , then I receive FID32 within the same Update message as the other FIDs.

If I use a different API e.g. Elektron Message API C++ version with .GDAXI - I see the same behaviour ie. FID 32 arrive in its own update.

Therefore, this appears to be specific to the particular RIC and not API related.

Please double check that your Update handler is in fact receiving FID 32 in a separate update message.

This should generate an RFA_RSSL.log file in your working directory - please view that file to confirm if FID 32 is being delivered e.g.

RSSL Client Message RECEIVE: 26
---DATA TRACE---
MESSAGE
	Msg Type: MsgType.UPDATE_RESP 	Msg Model Type: MARKET_PRICE
	Indication Flags: 	Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
	SeqNum: 49568 	RespTypeNum: 0 (UNSPECIFIED)
	Payload: 11 bytes
		FIELD_LIST
			FIELD_ENTRY 32: 0e020c614c

fengwei

thanks a lot. I always expect them to come together ... in this case, there is a bug in my implementation.

umer.nalla

Hi @fengwei

I suspect this behaviour could be specific to Index records (from some Exchanges ?)

For example I just tested with .FTSE and I observed the following:

ItemManager.processEvent: Received Event...
	Msg Type: MsgType.UPDATE_RESP	Msg Model Type: MARKET_PRICE
		FIELD_LIST
			FIELD_ENTRY 32/ACVOL_1: 245266853
			FIELD_ENTRY 100/TURNOVER: 1406.89
			FIELD_ENTRY 178/TRDVOL_1: 298004
ItemManager.processEvent: Received Event...
	Msg Type: MsgType.UPDATE_RESP	Msg Model Type: MARKET_PRICE
		FIELD_LIST
			FIELD_ENTRY 6/TRDPRC_1: 7400.67
			FIELD_ENTRY 11/NETCHNG_1: 12.87
			FIELD_ENTRY 14/PRCTCK_1: þ (2)
			FIELD_ENTRY 18/TRDTIM_1: 10:46
			FIELD_ENTRY 56/PCTCHNG: 0.17
			FIELD_ENTRY 77/NUM_MOVES: 42138
			FIELD_ENTRY 379/SALTIM: 10:46:01
			FIELD_ENTRY 996/GEN_VAL1: 6170.25
ItemManager.processEvent: Received Event...
MESSAGE
	Msg Type: MsgType.UPDATE_RESP	Msg Model Type: MARKET_PRICE
		FIELD_LIST
			FIELD_ENTRY 32/ACVOL_1: 245267003
			FIELD_ENTRY 100/TURNOVER: 1406.90
			FIELD_ENTRY 178/TRDVOL_1: 298121
ItemManager.processEvent: Received Event...


and so on...

So, as you can see, I am receiving a separate Update message for ACVOL (and a few additional FIDs)

If you need further information on this behaviour please contact the Data Helpdesk uising the Link above.

fengwei

got it. thank you very much.

umer.nalla

Update - explanation of above behaviour from Content expert...

This is quite common actually. We often get a pulsed summary update from venues (and/or our value-add system if the venue doesn’t send) as it often gets generated after the trade has occurred.
In this case it seems we get a separate update from Deutsche Boerse after the index value is sent out.

EXPLORE OUR SITES