Empty Data packet received from reuters
On 16th June and 2nd July, we received empty data from reuters.
In Data.h, class RFA_DATA_API Data has public member -
/** Indicate if value of data is blank (i.e., empty).
Typically, a display application depicts blank.
\return indicates if data is blank
*/
virtual bool isBlank() const;
The following code was triggered -
if (data.isBlank())
{
.... Something....
}
Data type was FieldListEnum as the following line was printed. <84> should be 132 in decimal.-
2020-07-02 07:46:37.690086 [14228:00007FC708F38700]<ReutersRfa.RFAWrapper(RFA)>[ERR]: Invalid data type received:<84>
Is it possible for reuters to send empty data?
Hi @tss
Are you able to advise which RIC you were consuming and which field was being processed when the above isBlank check was triggered?
It is indeed possible for a blank field to be sent out by the server and thereby to be received by your application.
A Blank field would indicate there is no value available for that particular field at that point in time. The Blank field is there to differentiate from say a 0 value which could be a valid price or quantity in the context of a particular instrument.
A field that previously contained a non blank value could be updated with a blank if the data source / provider decides to blank that value for whatever reason - e.g. for example if I subscribe to say an LSE equity instrument outside of trading hours, the TRDPRC_1 field would be blanked as there is no current trade activity for that instrument.
Hi @umer
We are not entirely sure but we have a theory that it might be either JD.O or NTES.O.
getPayload() was called on RespMsg type object and then isBlank() was called. getDataType gave us <84> meaning it was FieldListEnum type. This code is generic for all messages.
But as you said, it is possible to get blank data and it also says in the comments on the enum -
/// FieldList (a data format type) contains zero or more FieldEntries.
FieldListEnum = 132,
It was just weird that we hit this empty condition for the first time in several years.
Hi @tss
The problem I think here is that you are attempting to getPayload() even though the isBlank() is true for the Payload.
The whole point of the isBlank is to indicate an empty payload - and therefore you would not be expected to extract a blank Payload.
If you refer to the examples that come with the RFA API you will note that when processing any responses or any payload / Data instances there is a check like:
if(respMsg.getHintMask() & RespMsg::PayloadFlag && respMsg.getPayload().isBlank())
{
cout<<endl<<"Warning: RDMConsumerClient::processRDMMarketDataResp() received Response message with empty payload"<<endl;
return;
}
OR
if ( ! data.isBlank() )
{
//decode data
}
If you do wish to understand why you occasionally get an empty payload, the best approach, for now, would be to improve the log output to indicate the instrument name and the exact time when the isBlank() check returns true, so if/when this happens again we can raise a ticket with the Elektron Content team so they can hopefully explain why a blank message is being received for that instrument at that point in time.
H i@tss,
You are welcome.
Once you do capture the details of blank data instances, you can raise a Content type ticket for the Elektron Rrealtime product -at My.Refinitiv
They can investigate Elektron content issues and hopefully will be able to explain the blank data instances.
Hi @
Just fyi, we had payload check before isBlank check -
// Check for data payload
if (!(respMsg.getHintMask() & RespMsg::PayloadFlag))
{
return;
}
So, extracting empty payload wasn't the problem. It's just we logged an error when we triggered isBlank() condition. Btw, if isBlank() is true do we still expect any field/FID to exist for parsing instrument name?
In theory, it is possible to get a blank field list. I have modified the provider to publish this update.
<updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="3" containerType="RSSL_DT_FIELD_LIST" flags="0x0" updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" dataSize="0"> <dataBody> </dataBody> </updateMsg>
Then, I added the code in the consumer to print the data type of data when the data is blank.
if (data.isBlank()) {
printf("### Data is blank: 0x%x, %d\n", data.getDataType(), data.getDataType());
}
The consumer prints this message when decoding the update message with no payload.
2020 Jul 3 13:42:22.096 ST GMT+07:00 1AE4 33C4 611 TRACE <- Received MMT_MARKET_PRICE Update. ### Data is blank: 0x84, 132
However, the server shouldn't send the kind of update to the application.
To verify the problem, you need to print the raw hex data of the response message.
The code looks like:
void Decoder::printHexString(const unsigned char* data, int len) {
char hexmap[] = { '0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
std::string s(len * 2, ' ');
for (int i = 0; i < len; ++i) {
s[2 * i] = hexmap[(data[i] & 0xF0) >> 4];
s[2 * i + 1] = hexmap[data[i] & 0x0F];
}
printf("\n%s\n", s.c_str());
}
Then, call the printHexString method with the encoded buffer inside the response message.
_pDecoder->printHexString(respMsg.getEncodedBuffer().c_buf(), respMsg.getEncodedBuffer().capacity());
With this information, we can verify the data retrieved by the application.