sink_driven_src sends streamId 0 when changing item groupId

Martin J

When running sink_driven_src in interactive mode, I can use the 'item_group' command to change the groupId to which a given stream belongs:

Enter Command (help): item_group
Enter Item Name: RYA.I
Enter Group: 99

As you'd expect, this results in an unsolicited status message containing the new groupId -- but it seems that the message has a streamId of 0:

<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<statusMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="0" containerType="RSSL_DT_NO_DATA" flags="0x38 (RSSL_STMF_HAS_MSG_KEY|RSSL_STMF_HAS_GROUP_ID|RSSL_STMF_HAS_STATE)" groupId="99" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="All is well." dataSize="0">
<key flags="0x3 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME)" serviceId="1" name="RYA.I"/>
<dataBody>
</dataBody>
</statusMsg>

The streamId is a required field, according to the user guide, and the message seems incomplete without this information. (It does include a MsgKey containing serviceId and instrument name, so it's not totally unusable; but this requires a more complicated and expensive search to find the affected stream.)

Could you please confirm that this is a bug in sink_driven_src (in version: trep3.2.1.L1.B1 (ssl 6dfee57)), and that a real ADS or other provider will in fact always send the streamId to which the change of groupId applies? Thanks in advance...

Jirapongse

Yes, stream ID of the status message when using item_group is zero.

However, if I run TREP to connect to sink_driven_src and request data from ADS, the consumer can get the status message with the correct stream ID.

Therefore, please try to use sink_driven_src through TREP instead of directly connecting to sink_driven_src.

For more information, please directly contact ADH support team via Contact Us to verify the behavior.

Martin J

That's a workaround, I guess. Please consider this a bug report for the sink_driven_src, then, and forward it to the appropriate group for repair.