When receiving an RSSL_MC_UPDATE for a symbol list, the RsslMap is empty

When requesting a Symbol List with RSSL_RQMF_STREAMING set in the flags, after the initial REFRESH message, UPDATEs will arrive, generally with some number of symbols that have either been added or removed from the symbol list.

Frequently an UPDATE will arrive where there is nothing in the RsslMap in the UPDATE message.

Dumping out the message looks like this:
RsslMsgBase:
- msgClass: RSSL_MC_UPDATE (4)

- domainType: RSSL_DMT_SYMBOL_LIST (10)

- containerType: RSSL_DT_MAP (137)
encDataBody: - 8 bytes:
00000000 08 10 00 41 47 D0 00 00
encMsgBuffer: - 23 bytes:
00000000 00 0D 04 0A 00 00 0A 0D 10 09 00 00 00 00 00 08
00000010 10 00 41 47 D0 00 00

Should I just ignore this, or have I missed something in the documentation/examples?
Is the empty map a heartbeat?
Or does it indicate something else?

Find more posts tagged with

symbology

elektron

rssl

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

Accepted answers

Joe.Ferraro

Having just had this occur and matching the timestamp in my trace to find the correct XML file containing the data for the event that had an empty RsslMap, I see the following:

<!-- End Message (Channel IPC descriptor = 19) -->
<!-- Incoming Message (Channel IPC descriptor = 19) -->
<!-- Time: 12:49:11:355 -->
<!-- rwfMajorVer="14" rwfMinorVer="0" -->
<updateMsg domainType="RSSL_DMT_SYMBOL_LIST" 
           streamId="100" 
           containerType="RSSL_DT_MAP" 
           flags="0x18 (RSSL_UPMF_HAS_MSG_KEY|RSSL_UPMF_HAS_SEQ_NUM)" 
           updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" 
           seqNum="0" 
           dataSize="8">
    <key  flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)"  serviceId="257" name="XXX_XXX_XX" nameType="1"/>
    <dataBody>
        <map flags="0x8 (RSSL_MPF_HAS_TOTAL_COUNT_HINT)" countHint="84299" 
             keyPrimitiveType="RSSL_DT_BUFFER" containerType="RSSL_DT_NO_DATA" >
        </map>
    </dataBody>
</updateMsg>

Unlike most of the messages, there are no fieldList nor fieldEntry in the dataBody

Seeing the XML now, I suspect the sole purpose of this message with the empty map is to provide the countHint field.

So, in this case, I'm likely answering my own question: the message, while containing no fields, simply contains a value in RsslMap.totalHintCount.

Therefore, the answer to the above question is most likely "it indicates something else"

All comments

veerapath.rungruengrayubkul

Hi @Joe.Ferraro,

Could you provide the RIC name and service name you are using?

Also, it would be helpful, if you can provide the RSSL tracing in XML format for the update message. You may either enable the XML tracing in your application or use the rsslConsumer example with "-x" option.

XML tracing is configurable through rsslIoctl by using RSSL_TRACE for the RsslIoctlCodes. For more information, please see XML Tracing in ETA Developers Guide document.

Joe.Ferraro

I doesn't happen every time; it's sporadic.

I'm not using A RIC; I don't thinka RIC would generate an RSSL_MC_UPDATE while processing a message callback with domainType: RSSL_DMT_SYMBOL_LIST

I will attempt to gather an XML trace by either modifying my application to generate one, or by using rsslConsumer with a modified symbol list decoder that will print when the condition occurs

Joe.Ferraro

I have modified my application to create an XML trace as detailed in both the developers guide and the sample code referenced above.

I'm just waiting the receipt of an empty RsslMap in a SymbolList Update message.

I've reproduced the condition once so far, generating 90 16M files of collected data.

What should I do with it?

@sunil.mahale
@Olivier DAVANT
@veerapath.rungruengrayubkul

Joe.Ferraro

Having just had this occur and matching the timestamp in my trace to find the correct XML file containing the data for the event that had an empty RsslMap, I see the following:

<!-- End Message (Channel IPC descriptor = 19) -->
<!-- Incoming Message (Channel IPC descriptor = 19) -->
<!-- Time: 12:49:11:355 -->
<!-- rwfMajorVer="14" rwfMinorVer="0" -->
<updateMsg domainType="RSSL_DMT_SYMBOL_LIST" 
           streamId="100" 
           containerType="RSSL_DT_MAP" 
           flags="0x18 (RSSL_UPMF_HAS_MSG_KEY|RSSL_UPMF_HAS_SEQ_NUM)" 
           updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" 
           seqNum="0" 
           dataSize="8">
    <key  flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)"  serviceId="257" name="XXX_XXX_XX" nameType="1"/>
    <dataBody>
        <map flags="0x8 (RSSL_MPF_HAS_TOTAL_COUNT_HINT)" countHint="84299" 
             keyPrimitiveType="RSSL_DT_BUFFER" containerType="RSSL_DT_NO_DATA" >
        </map>
    </dataBody>
</updateMsg>

Unlike most of the messages, there are no fieldList nor fieldEntry in the dataBody

Seeing the XML now, I suspect the sole purpose of this message with the empty map is to provide the countHint field.

So, in this case, I'm likely answering my own question: the message, while containing no fields, simply contains a value in RsslMap.totalHintCount.

Therefore, the answer to the above question is most likely "it indicates something else"

veerapath.rungruengrayubkul

@Joe.Ferraro

Your assumption seems make sense. However, the number of countHint is too huge.

Since there is no information about this behavior in documents, the simple way is to ask provider who sent this message for meaning and validation. Is the provider TR's feed?

EXPLORE OUR SITES