exceed RWF len

I am using the EMA to develop an application posting data to contribution channel. During the test, I got an error saying the encoded data length exceeds RWF length for Fid HST_CLOSE.

HST_CLOSE "HISTORIC CLOSE" 21 NULL PRICE 17 REAL64 7

Questions:

1. In the RDM dictionary, that fid has RWF len = 7. How should I interpret the len so that I can avoid the error?

2. The DeniedBySource code means the whole message will be denied by the source, right?

3. For the field length (e.g. 17 for fid HST_CLOSE), does it mean the field should have no more than 17 digits in it? Does the decimal point counted in the length?

The value sent out in PostId=9, HST_CLOSE=29979.9

[WARN] 2020-11-22 07:18:02.032896 EST (1610610432):Application::PostMsg Error: AckId: 9, NackCode: DeniedBySource

[WARN] 2020-11-22 07:18:02.032948 EST (1610610432):Application::PostMsg Error: AckId: 9, Text: Encoded data length exceeds RWF length Fid Id [21] [Failed to apply update. Cache build failed]

Find more posts tagged with

elektron

rdm

elektron-sdk

refinitiv-realtime

Accepted answers

Mike Slade

Hi @moragodkrit.chumsri_1,

Another example is the following:

addRealFromDouble(22,100000000000000.9, ExponentNeg1Enum)

[WARN] 2020-12-07 10:58:54.354297 EST (3345233664):Application::PostMsg Error: AckId: 74106, Text: Encoded data length exceeds RWF length Fid Id [21] [Failed to apply update. Cache build failed]

In this example we cannot use a better hint to represent the value.

The value can be represented as a Real using the EMA API, why is it rejected when contributing?

All comments

moragodkrit.chumsri_1

@ye.li

Are you using EMA C++ and posting the message to the RCC backend?

The value you are posting should not exceed the length of REAL64.

Can you share the snippet of codes you used to create a posting message?
And please turn on RSSL Tracing logs to see the actual message EMA sends and receives from the server.

To enable the tracing, please add the XmlTraceToFile parameter for the Channel that you wish to enable XML Trace for. The file will be in "emaLog_<pid>.log" format.

e.g.

<Channel><Name value="Channel_1"/><ChannelType value="ChannelType::RSSL_SOCKET"/>   ...   <XmlTraceToFile value="1"/> </Channel>

ye.li

@moragodkrit.chumsri_1

Yes, I am using EMA C++ to post into the Contribution Channel.

Here is the code i use. The upstream data is in a different price type. Price precision will tell us how many digits after the decimal point we need to keep. we then map it to the corresponding OmmReal Exponent Enum.

mamaPricePrecision pp = mPrice.getPrecision();
if( _precisionMap.find(pp) != _precisionMap.end() )
{
fList.addRealFromDouble( it->getOutputTag(), mPrice.getValue(), _precisionMap[pp] );
std::ostringstream px;
px << mPrice.getValue();
_builders[ind]->append(rField, px.str());
}

moragodkrit.chumsri_1

@ye.li

I can't find the message "Encoded data length exceeds RWF length" from EMA source codes so that I believe that it comes from the infra backend; in this case, it should be the RCC or Contribution Channel. The problem seems to relate to the double value and exponent enum you set in the post message. Therefore I need to see the RSSL Trace log generated by the app when you found the issue. It should help us verify what data the application publishes to the RCC at the time problem occurs.

I also did a quick test with the RCC example we provided on the Dev Portal.

I change the codes to use .addRealFromDouble to send the Real64 data with the sample double vale 29979.9 and below are my snippet codes.

.addRealFromDouble(22, 29979.9, OmmReal::ExponentNeg1Enum)

I test the app, and it can post data to the server without the issue. And below is the raw data EMA send to the server.

0D = 13 = ExponentNeg1Enum

and 049317 = 299799.

Do you have an application log contains the value you pass to the addRealFromDouble function?

We can compare it with the raw data from the RSSL Trace. What I can help is to verify the data which send from the app. If it's the correct value, that should be the problem on the RCC server-side, and you might need to contact the support team who takes care of the Contribution Channel server to further investigate the issue.

Mike Slade

Hi,

The following is the TRACE log we get when sending out HST_CLOSE.

[Message] feed=refinitivsource=PB-NAMR-DEVsymbol=MSTEST001.PUBHSTCLSDATE=04 DEC 2020HST_CLOSE=29979.9TRDPRC_1=12345publish_time=2020-12-04 09:58:03.475806 ESTcontrib_sym=TEST0009=JPMLmapSource=EMEA_EDG_INDEX_CHAIN_REUTERShash=15222191812757905843PostID=290796
<!-- Outgoing Message (Channel IPC descriptor = 15) -->
<!-- Time: 9:58:03:476 -->
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
<genericMsg domainType="RSSL_DMT_SYSTEM" streamId="4" containerType="RSSL_DT_MSG" flags="0x19 (RSSL_GNMF_HAS_EXTENDED_HEADER|RSSL_GNMF_HAS_SEQ_NUM|RSSL_GNMF_MESSAGE_COMPLETE)" seqNum="290797" dataSize="79">
    <extendedHeader data="0100"/>
    <dataBody>
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
        <postMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="6" containerType="RSSL_DT_MSG" flags="0x62 (RSSL_PSMF_HAS_POST_ID|RSSL_PSMF_POST_COMPLETE|RSSL_PSMF_ACK)" postId="290796" postUserId="0" postUserAddr="0.0.0.0" dataSize="57">
            <dataBody>
<!-- rwfMajorVer="14" rwfMinorVer="1" -->
                <updateMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="6" containerType="RSSL_DT_FIELD_LIST" flags="0x8 (RSSL_UPMF_HAS_MSG_KEY)" updateType="0 (RDM_UPD_EVENT_TYPE_UNSPECIFIED)" dataSize="29">
                    <key  flags="0x2 (RSSL_MKF_HAS_NAME)"  name="TEST0009=JPML"/>
                    <dataBody>
                        <fieldList flags="0x8 (RSSL_FLF_HAS_STANDARD_DATA)">
                            <fieldEntry fieldId="79" data="040C 07E4"/>
<fieldEntry fieldId="21" data="0401 10AA 64E6 2600"/>
                            <fieldEntry fieldId="6" data="0B00 BC5E A9"/>
                        </fieldList>
                    </dataBody>
                </updateMsg>
            </dataBody>
        </postMsg>
    </dataBody>
</genericMsg>
<!-- End Message (Channel IPC descriptor = 15) -->

This results in the following application log:

[WARN] 2020-12-04 09:58:03.531388 EST (3143907072):Application::PostMsg Error: AckId: 290796, Text: Encoded data length exceeds RWF length Fid Id [21] [Failed to apply update. Cache build failed]

Code (substituting tag,value,and hint variables):

addRealFromDouble( 21, 29979.9, OmmReal::ExponentNeg10Enum);

moragodkrit.chumsri_1

@ye.li

It looks like the problem comes from the MagnitudeType you set in the addRealFromDouble function. It should be ExponentNeg1Enum rather than ExponentNeg10Enum.

Not sure why you set it to ExponentNeg10Enum in this case?

Mike Slade

Hi @moragodkrit.chumsri_1,

Another example is the following:

addRealFromDouble(22,100000000000000.9, ExponentNeg1Enum)

[WARN] 2020-12-07 10:58:54.354297 EST (3345233664):Application::PostMsg Error: AckId: 74106, Text: Encoded data length exceeds RWF length Fid Id [21] [Failed to apply update. Cache build failed]

In this example we cannot use a better hint to represent the value.

The value can be represented as a Real using the EMA API, why is it rejected when contributing?

moragodkrit.chumsri_1

@Mike Slade

The value you set in EMA seems to not over 8 bytes and still covered by the Real data type. I think it should be the problem from the caching feature on the infra side. I also try the value, and it looks like the status text was generated by the infra. Basically, EMA provides a method for the user to set value and its magnitude type and then pass it to the back end, so it does not know a limitation on the specific back end.

I would suggest you contact the RCC team directly to verify the issue on the infra side and confirm its cause.

You can open a new support ticket via https://my.refinitiv.com/content/mytr/en/productsupport.html

And select the following product

Mike Slade

Hi @zoya faberov,

We discovered that on the RCC side the dictionary specifies an RWF length of 7 for HST_CLOSE and some other REAL fields. The value above is rejected for being over that length.

We are making changes on our side to make sure we set an appropriate hint when contributing REALs.

Thanks,

Mike

EXPLORE OUR SITES