@jan.skalicky

• Are you using the same custom dictionary file on both the Application and the TREP server side? I'm not sure that there is a problem with the type of data in the dictionary on the TREP server or not.
• What kind of data type did you use to publish the fid on the NI Provider side? Is this opaque data as Umer said?

From the tracing log, it looks like you are using field ID 1 and from our data dictionary it is PROD_PERM and data type is UINT64. But data you are publishing is not the UInt64 so I'm not sure how the ADH caching this kind of data after you stop the NI Provider. I guess that the data you receive from the trace file end with 25328 come from the Provider which still active so the TREP just fan out the message from the provider to the consumer app. It could be the reason that there is no problem when you test it when the Provider still active.

But after the provider stops, and then you start the consumer again, the TREP sends multiple refresh messages with a blank field list to the consumer instead.

<!-- Incoming Message from '<host>:14002' on 'localhost' interface -->

<!-- Time: 13:31:44:405 -->

<!-- rwfMajorVer="14" rwfMinorVer="1" -->

<refreshMsg domainType="128" streamId="3" containerType="RSSL_DT_FIELD_LIST" flags="0x10A8 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_HAS_QOS|RSSL_RFMF_HAS_PART_NUM)" groupId="42" partNum="12" qosDynamic="0" qosRate="1" qosTimeliness="1" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="" dataSize="3">

<key flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)" serviceId="772" name="Px.Groups" nameType="1"/>

<dataBody>

<fieldList flags="0x8 (RSSL_FLF_HAS_STANDARD_DATA)">

</fieldList>

</dataBody>

</refreshMsg>

<!-- Incoming Message from '<host>:14002' on 'localhost' interface -->

<!-- Time: 13:31:44:405 -->

<!-- rwfMajorVer="14" rwfMinorVer="1" -->

<refreshMsg domainType="128" streamId="3" containerType="RSSL_DT_FIELD_LIST" flags="0x10A8 (RSSL_RFMF_HAS_MSG_KEY|RSSL_RFMF_SOLICITED|RSSL_RFMF_HAS_QOS|RSSL_RFMF_HAS_PART_NUM)" groupId="42" partNum="13" qosDynamic="0" qosRate="1" qosTimeliness="1" dataState="RSSL_DATA_OK" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="" dataSize="3">

<key flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)" serviceId="772" name="Px.Groups" nameType="1"/>

<dataBody>

<fieldList flags="0x8 (RSSL_FLF_HAS_STANDARD_DATA)">

</fieldList>

</dataBody>

</refreshMsg>

The blank field list from the above sample traces is the outgoing message from the TREP server. Therefore, the problem seems to relate to the data caching mechanism on the TREP side. I would suggest you contact the Refinitiv TREP support team to help you verify the setup and you can provide the RSSL trace log to the team to investigate the issue further.

Hi @jan.skalicky

Can you confirm if you are Posting data to TREP or implementing a Provider application to send the data? If a provider, then is it interactive or non-interactive?

Also, the data you are sending what form is it - a simple FieldList or a more complex Reuters Domain model - if so which domain? Or are you sending an opaque Buffer?

Please provide more details on exactly what you are doing, the connection type, the payload etc so that we can assist you better.

How are you confirming the data is being trimmed? How do you consume the data?

Also, if you can confirm which version of TREP so that we can check for any know TREP issues.

Hi @jan.skalicky

Thanks for updating the original post with the additional information.

Are you publishing the data using a Custom Domain Model specified in the RespMsg and then consuming the data by specifying the Custom Domain in your ReqMsg too?

Unless one of my colleagues has a quick answer, I suspect this would require a more detailed investigation (and I will be out of the office for most of next week). In view of this, I would recommend you create a Support Ticket - so that you can work with Developer support to verify your Provider code and ensure the encoding of the message is correct etc.

You can also enable the RSSL Trace for your Provider and Consumer to confirm what exact payload is being transmitted by the Provider to TREP and likewise what payload is being received by the Consumer from TREP. See this post on how to enable the Trace

@jan.skalicky

You may also turn on the RSSL Trace log on both Provider and Consumer side so you can compare the raw data that sent and receive by API.

You can find the instruction to turn on the trace file from this post.