Microsecond and nanosecond precision timstamp support in RFA 7.6 version

LtDoolittle6
LtDoolittle6 Contributor

Is
the microsecond and nanosecond precision timestamp only available in RFA 8?

In
RFA 8.0 README I see

Time and DateTime Microsecond and Nanosecond Support
----------------------------------------------------
This release contains Time and DateTime enhancements to
support microsecond and nanoseconds granularity.
Note: Applications based on RWF Major Version 14 and Minor Version 0 do
not have the ability to recognize microsecond and nanosecond precision time
values. If receiving content encoded with this larger precision,
the older versions of RFA's decoder will result in an exception.
Applications can be coded to handle the exception and continue decoding
the remaining content in the message.

Our application uses the RFA 7.6
version, so will it not be able to get the any microsecond and nanosecond
precision time value and get exception? If our application tries
to call DataBuffer::getAsString(), will we still get an exception ? What
is the recommended way to handle such fields in RFA 7 application?

Tagged:

Best Answer

  • The
    microsecond and nanosecond support in Time and DateTime field currently is
    available only in RFA 8.x version. Once RFA 7.6.x version or older application
    tries to decode the field published with microsecond and nanosecond
    (i.e. via the DataBuffer::getTime(), DataBuffer::getAsString(),
    DataBuffer::isBlank()), RFA will throw an invalid usage exception.

    Below is the example of exception in 7.6.2 vesion.

    Exception Type: InvalidUsageException
    Exception Severity: Error
    Exception Classification: IncorrectAPIUsage
    Exception Status Text: Data decoding failed in DataBuffer::getTime(); Reason: RSSL_RET_INCOMPLETE_DATA

    RFA
    7.x application needs to handle the exception and continue decoding the
    remaining content in the message (i.e. next field entry). This means that application will not be ableto receive any value from the file. We would recommend updating RFA version to 8.x version.

    Anyway, if there is no nanosecond and
    microsecond precision published in the Time and Date Time field, RFA 7.x will
    decode TIME and DATETIME data type properly.

Answers

  • Hi @LtDoolittle6

    My understanding is that in order to convert to string, the API still needs to decode the value before it can convert.

    Therefore, from a programming perspective you will either need to upgrade to v8 API or amend your code handle the exceptions - if your code does not just decode a predetermined set of fields i.e. there is a chance it will attempt to decode one of the newer fields.

    From the perspective of your Market Data team, they should be provided with some workarounds they can implement at the TREP level. e.g. having a dedicated set of ADS servers for legacy API applications - where the ADS filters out / does not send out the newer fields. They should contact their technical account manager or the TREP helpdesk for further guidance.

  • It is may be interesting to note that in order to preserve
    the compatibility of existing application, the microsecond and nanosecond
    precision time values have only been introduced in new fields. These fields have
    an acronym with a suffix of “_NS” (like “ASK_TIM_NS”). This means that applications that do not try to decode these new
    “_NS” fields will not experience the InvalidUsageException.

    Now the question is: How does your application decode the
    fields it receives?

    • If it iterates through the whole field list and tries to
      decode each field whatever its name is, then it will probably
      experience the InvalidUsageException. To fix this issue you will have either to
      change your code to handle the exception (as described above by Veerapath) or
      to upgrade your application to RFA 8 (recommended solution).
    • If your application iterates through the field list but only
      decodes the fields it knows (either because it recognizes them by the acronym or
      by the field id), then there’s no chance your application tries to decode any
      of the new “_NS” fields. In that case, you don’t have to worry about the
      exception and you can keep your RFA version. Obviously, you will not
      benefit from the new microsecond and nanoseconds precision.