We submit events via Refinitiv Real-Time SDK v3.7.1.0 directly to the Refinitiv endpoints (EMA, TunnelStreamRequest, OmmConsumerClient).
In most cases we submit events and get Ok ACK similar to this (according to xml trace output)
<!-- Outgoing Reactor message -->
<!-- java.nio.channels.SocketChannel[connected local=/11.11.11.11:55888 remote=contrib1-emea1.platform.refinitiv.com/99.81.199.166:443] -->
<!-- Tue Nov 14 09:31:00 EST 2023 -->
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<GENERIC domainType="SYSTEM" streamId="3" containerType="MSG" flags="0x19 (HAS_EXTENDED_HEADER|HAS_SEQ_NUM|MESSAGE_COMPLETE)" seqNum="32" dataSize="65">
<extendedHeader data="0100"/>
<dataBody>
<POST domainType="MARKET_PRICE" streamId="5" containerType="MSG" flags="0x62 (HAS_POST_ID|POST_COMPLETE|ACK)" postId="31" postUserId="0" postUserAddr="0.0.0.0" dataSize="43">
<dataBody>
<UPDATE domainType="MARKET_PRICE" streamId="5" containerType="FIELD_LIST" flags="0x08 (HAS_MSG_KEY)" updateType="0" dataSize="21">
<key flags="0x02 (HAS_NAME)" name=".SOMERIC"/>
<dataBody>
<fieldList flags="0x08 (HAS_STANDARD_DATA)">
<fieldEntry fieldId="6" data="0C17 53"/>
<fieldEntry fieldId="16" data="0E0B 07E7"/>
<fieldEntry fieldId="18" data="0E1F"/>
</fieldList>
</dataBody>
</UPDATE>
</dataBody>
</POST>
</dataBody>
</GENERIC>
<!-- Incoming Reactor message -->
<!-- java.nio.channels.SocketChannel[connected local=/11.11.11.11:55888 remote=contrib1-emea1.platform.refinitiv.com/99.81.199.166:443] -->
<!-- Tue Nov 14 09:31:00 EST 2023 -->
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<GENERIC domainType="SYSTEM" streamId="3" containerType="MSG" flags="0x19 (HAS_EXTENDED_HEADER|HAS_SEQ_NUM|MESSAGE_COMPLETE)" seqNum="29" dataSize="14">
<extendedHeader data="0100"/>
<dataBody>
<ACK domainType="MARKET_PRICE" streamId="5" containerType="NO_DATA" flags="0x00" ackId="31" dataSize="0">
<dataBody></dataBody>
</ACK>
</dataBody>
</GENERIC>
However, in some cases which happens usually on a daily basis we get ACK errors to the similar submitted messages, for example
<!-- Outgoing Reactor message -->
<!-- java.nio.channels.SocketChannel[connected local=/11.11.11.11:55888 remote=contrib1-emea1.platform.refinitiv.com/99.81.199.166:443] -->
<!-- Fri Nov 17 19:35:00 EST 2023 -->
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<GENERIC domainType="SYSTEM" streamId="3" containerType="MSG" flags="0x19 (HAS_EXTENDED_HEADER|HAS_SEQ_NUM|MESSAGE_COMPLETE)" seqNum="43881" dataSize="65">
<extendedHeader data="0100"/>
<dataBody>
<POST domainType="MARKET_PRICE" streamId="5" containerType="MSG" flags="0x62 (HAS_POST_ID|POST_COMPLETE|ACK)" postId="43880" postUserId="0" postUserAddr="0.0.0.0" dataSize="43">
<dataBody>
<UPDATE domainType="MARKET_PRICE" streamId="5" containerType="FIELD_LIST" flags="0x08 (HAS_MSG_KEY)" updateType="0" dataSize="21">
<key flags="0x02 (HAS_NAME)" name=".SOMERIC"/>
<dataBody>
<fieldList flags="0x08 (HAS_STANDARD_DATA)">
<fieldEntry fieldId="6" data="0C16 90"/>
<fieldEntry fieldId="16" data="120B 07E7"/>
<fieldEntry fieldId="18" data="0023"/>
</fieldList>
</dataBody>
</UPDATE>
</dataBody>
</POST>
</dataBody>
</GENERIC>
<!-- java.nio.channels.SocketChannel[connected local=/11.11.11.11:55888 remote=contrib1-emea1.platform.refinitiv.com/99.81.199.166:443] -->
<!-- Fri Nov 17 19:35:05 EST 2023 -->
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<GENERIC domainType="SYSTEM" streamId="3" containerType="MSG" flags="0x19 (HAS_EXTENDED_HEADER|HAS_SEQ_NUM|MESSAGE_COMPLETE)" seqNum="43883" dataSize="31">
<extendedHeader data="0100"/>
<dataBody>
<ACK domainType="MARKET_PRICE" streamId="5" containerType="NO_DATA" flags="0x22 (HAS_TEXT|HAS_NAK_CODE)" ackId="43880" nakCode="INVALID_CONTENT" text="Invalid content" dataSize="0">
<dataBody></dataBody>
</ACK>
</dataBody>
</GENERIC>
As it can be seen we send messages with the identical format/structure but sometimes get
nakCode="INVALID_CONTENT" text="Invalid content"
as ACK message.
We are not able to identify the cause of INVALID_CONTENT ACK error messages as from our point of view the outgoing message format is the same and valid.
Any help to get the reason of the problem is highly appreciated.
