OMMDataBuffer.horizontalPosition() returns -1

CM Wong
CM Wong Explorer
in RFA

Hi,

I am looking at the RIC LP62009689. Its DSPLY_NMLL field is a RMTES_STRING and its OMMDataBuffer.hasPartialUpdates() returns true. When I tried to iterate its partial updates, I got the following result:

(1) Horizontal offset -1, Data 0xEF 0xBE 0x86 0xEF 0xBD 0xAF 0xEF 0xBD 0xBE 0xEF 0xBD 0xB2 0x20 0xE5 0xA4 0x96 0xE5

(2) Horizontal offset 0, Data 0x20 0xE8 0xB3 0xBC 0xE5 0x85 0xA5

The RFA JavaDoc says offset -1 means "full buffer", then how come there is a second partial update whose offset is 0?

Do anyone has any idea how to interpret the result?

Regards,

CM


Tagged:

Best Answer

  • wasin.w
    wasin.w admin
    Answer ✓

    Hello @CM Wong

    Thank you for your confirmation. I have checked the FID 1352 (Field DSPLY_NMLL) from the trace file:


    The API received a blank value FID 1352 from Refresh message on 2020-12-02T04:24:29

    FIELD_ENTRY 1352:


    Then the API received data from Update message on 2020-12-02T19:58:56

    FIELD_ENTRY 1352: efbe86efbdafefbdbeefbdb220e5a496e59bbde6a0aa49647820e8b3bce585a5


    Based on the RMTES/Partial Update definition, it should not be the “Partial Update” because the update message contains an entire new message, not just some part of the position of update characters.


    The Partial Update message should also have the following pattern as shown below:

    image

    Example Partial Update message from FXFX RIC:

    FIELD_ENTRY 220: 1b5b33316020302e373539332f3 35

    Which means: <CSI> n=31 <HPA> data = 0.7593/95 (20 30 2e 37 35 39 33 2f 39 35).


    However, your incoming DSPLY_NMLL message is

    FIELD_ENTRY 220: efbe86efbdafefbdbeefbdb220e5a496e59bbde6a0aa49647820e8b3bce585a5


    The message does not look like Partial Update at all. It does not have any control and infra-field position characters. It looks like the Full update.


    You can find more detail regarding the page-based data and partial update behavior from this article (the article is based on RTSDK Java, but the data concept is the same as RFA).


Answers

  • wasin.w
    wasin.w admin

    Hello @CM Wong

    I have checked the RIC LP62009689 (Nissay Foreign EQ Index). The RIC seems to provide Quote data for consumer, not the Page-based data which application needs to check the partial update.

    Basically, the Page-based data contains text or numbers for over-the-counter traded instruments and emerging markets. The data are delivered through Real-time feed row by row, each row is identified by a unique field. The Page-based data contains field names in the "ROWx_x" pattern (example: ROW64_1, ROW80_1, ROW99_1, etc ). Refinitiv Real-Time can send updates for Page-based data as "partial update" which is an intra-field positioning sequence within the data field so that the minimum number of characters are transmitted to effect a change.

    However, this LP62009689 seems to be the Quote RIC that the application should update an entire field data from the Update message as usual.

    How often the problem occurs in your environment? Can you replicate the issue on demand? If so, could you enable the RFA trace file and share the file when the issue occur?

    You can configure the following RFA Java configurations to enable the XML log file

    <namespace>/Connections/<Connection Name>/ipcTraceFlags = 23
    <namespace>/Connections/<Connection Name>/mountTrace = True
    <namespace>/Connections/<Connection Name>/logFileName=<path to log file>

    ### Example RFA Java Configurations for the trace file ###


    <node name="rsslConnection">
       <map>
          <entry key="connectionType" value="RSSL"/>
          <entry key="serverList" value="localhost"/>
          <entry key="portNumber" value="14002"/>
    <entry key="ipcTraceFlags" value="23"/>
          <entry key="mountTrace" value="True"/>
          <entry key="logFileName" value=".\logs\RSSL_%U.log"/>
       </map>
    </node>

    Additionally, could you please give me the versions of RFA Java and Java SDK that you are using?


  • CM Wong
    CM Wong Explorer

    Hi @wasin.w

    Thanks for your reply. As far as I know, many Japanese instruments do have RMTES string fields with partial updates.

    I am using Java RFA v8.1.0.L1 and JDK 8

    Trace log attached. Please see update at 2020-12-02 13:20:10

    Regards,

    CM

    trace.txt

  • wasin.w
    wasin.w admin

    Hello @CM Wong

    Sorry for the late reply, I have checked the trace file at 2020-12-02 13:20:10 (<date>2020-12-02T13:20:10</date>). The only RMTES string field that was updated is FID 1667 (field GN_TX20_3)

    GN_TX20_3  "GN TXT20 3"          1667  NULL        ALPHANUMERIC       20  RMTES_STRING    20

    Could you please confirm if you encounter the problem with this FID?

  • CM Wong
    CM Wong Explorer

    Hi @wasin.w

    Sorry, I copied the wrong time. The update should be at 2020-12-02 19:58:56, field name is DSPLY_NMLL

    Regards,

    CM


  • CM Wong
    CM Wong Explorer

    Hello @wasin.w

    Thanks for your update.

    If you compare the captured FID raw data with those returned from the JRFA (in my original question), they are very similar:

    (1) Horizontal offset -1, Data 0xEF 0xBE 0x86 0xEF 0xBD 0xAF 0xEF 0xBD 0xBE 0xEF 0xBD 0xB2 0x20 0xE5 0xA4 0x96 0xE5
    (2) Horizontal offset 0, Data 0x20 0xE8 0xB3 0xBC 0xE5 0x85 0xA5
    FIELD_ENTRY 220: efbe86efbdafefbdbeefbdb220e5a496e59bbde6a0aa49647820e8b3bce585a5

    But somehow JRFA divides them into 2 parts and returns them as partial updates.

    My program has no problem processing other partial update fields except this one.

    I will try JRFA 8.2 and see if there is any improvement.

    Regards,

    CM

Categories