We are using the realtime C++ SDK to handle market data. For reproducibility we log the "raw" (getAsHex()) bytes of each message.
We have observed that sometimes, especially when connecting after market open, we get refinitiv::ema::access::StatusMsg messages for whom if we call getAsHex() on, we get an empty EmaBuffer.
Is this expected? How might we serialise such messages in a binary format? Under what circumstances might messages have empty hex buffers?
I could replicate a status message with zero length.
StatusMsg streamId="5" domain="MarketPrice Domain" state="Open / Suspect / None / 'Service for this item was lost.'" name="JPY=" serviceName="ELEKTRON_DD" StatusMsgEnd Length:0
It is a status message generated by the API (not from the server) to inform the status of an item stream.
For example, if the connection has been disconnected, the API will generate this status message to indicate that the stream is Open/Suspect. This means that the stream is still open but the data is stale and the API will recover the stream on behalf of the application.
Thanks for reaching out to us.
I am unable to replicate the issue. I can display the heximal raw data properly with the following code.
void AppClient::onStatusMsg( const StatusMsg& statusMsg, const OmmConsumerEvent& )
{
cout << statusMsg << endl; // defaults to statusMsg.toString()
EmaBuffer buffer = statusMsg.getAsHex();
cout << "Length:" << buffer.length() << endl;
cout << buffer.asRawHexString()<<endl;
}
The output is:
StatusMsg streamId="5" domain="MarketPrice Domain" state="Closed / Suspect / Not found / '***The record could not be found'" name="INVALID.TEST" nameType="1" serviceId="10004" serviceName="ELEKTRON_DD" StatusMsgEnd Length:65 003f 0306 0000 0004 2800 2201 202a 2a2a 5468 6520 7265 636f 7264 2063 6f75 6c64 206e 6f74 2062 6520 666f 756e 6480 1207 fe27 140c 494e 5641 4c49 442e 5445 5354 01
You may need to check the length of the buffer.
Moreover, each message must not be used outside the callback methods, such as AppClient::onStatusMsg.
To use the messages outside the callback methods, you need to copy the messages by using copy constructors.
I hope that this information is of help.
Hi @Jirapongse - thanks for your reply. I have also been unable to reproduce the original issue. Our code is simple and literally logs out the data and size of each message from within the callback, and on the day before I filed this issue we had some zero-sized, empty messages. I haven't been able to reproduce since, but I have put in some defensive code and log statements so if it happens again we'll know what the messages were.
I'll reopen this issue if and when we get more information.
Thanks, Matt
Thank you @Jirapongse - I was scouring the source looking for evidence of a non-received status msg being sent, but couldn't find one. We'll take appropriate action here.
Thank you.
