Switching over to a different connection with warm standby and regular failover causes with previ...

...ously received version numbers to be replayed

We're using RFA API to stream market data. It seems that when a switchover occurs, we receive quotes with sequence numbers which were already sent on a previous connection.

I thought that RFA would handle sequence numbers on its own and only send quotes which the API client wasn't yet notified with. Is this a problem from the user standpoint i.e. will it cause us to generate incorrect quote books or are the quotes replayed from a specific checkpoint, with a full refresh before that thus causing quote books to be rebuilt correctly?

Could this be a server configuration problem?

Thank you for help.

Find more posts tagged with

failover

resilience

rfa-api

warm-standby

#technology

Accepted answers

Jirapongse

@nrao

We need XML trace files to verify what the problem is.

If the secondary server sends the update with the same SeqNum as the primary server after failover, it should appear in the XML trace files. Then, we can contact the server team to verify if it is an expected behavior.

The XML trace files are concrete evidences used to investgate this issue.

However, this forum is not a suitable channel to investigate this kind of issue. You can contact the API support team directly via Contact Premium Support to investigate this issue.

You need to have a RDC (Refinitiv Developer Connect) contact in order to access Contact Premium Support.

All comments

Jirapongse

@nrao

Thank you for reaching out to us.

Typically, for performance reasons, RFA will not process the data; it just pass the retrieved data to applications.

When failover happens, an application will retrieve an item's refresh which contains all fields with the latest data. This refresh message is used to synchronize data so the SEQNUM field in the refresh's payload may equal to the SEQNUM field in the previous update's payload.

When you mentioned the sequence numbers, they are sequence numbers in the messages' headers or messages' payload.

For example:

<!-- End Message (Channel IPC descriptor = 564) -->
UpdateMsg
    streamId="5"
    domain="MarketPrice Domain"
    updateTypeNum="2"
    DoNotConflate
  seqNum="40222"
    name="0001.HK"
    serviceId="2114"
    serviceName="API_ELEKTRON_EDGE_TOKYO"
    Payload dataType="FieldList"
        FieldList
            FieldEntry fid="18" name="TRDTIM_1" dataType="Time" value="03:49:27:000:000:000"
            FieldEntry fid="32" name="ACVOL_1" dataType="Real" value="2984479"
            FieldEntry fid="77" name="NUM_MOVES" dataType="Real" value="1887"
            FieldEntry fid="100" name="TURNOVER" dataType="Real" value="115650001"
            FieldEntry fid="178" name="TRDVOL_1" dataType="Real" value="500"
            FieldEntry fid="372" name="IRGPRC" dataType="Real" value="38.850"
            FieldEntry fid="373" name="IRGVOL" dataType="Real" value="500"
            FieldEntry fid="379" name="SALTIM" dataType="Time" value="03:49:27:000:000:000"
            FieldEntry fid="380" name="TNOVER_SC" dataType="Enum" value="1"
            FieldEntry fid="393" name="PRIMACT_1" dataType="Real" value="38.850"
            FieldEntry fid="975" name="ACT_FLAG1" dataType="Rmtes" value=" "
  FieldEntry fid="1021" name="SEQNUM" dataType="Real" value="1887"
            FieldEntry fid="1644" name="TRANVOL_1" dataType="Real" value="500"
            FieldEntry fid="1665" name="GN_TX20_1" dataType="Rmtes" value="03:49          03:47"

seqNum="40222" is the sequence number in the update's header while SEQNUM: 1887 is the sequence number in the update's payload.

However, you may need to enable tracing in the API to verify the retrieved data.

nrao

@Jirapongse Thank you for the quick response. What repeats are sequence numbers inside quote messages MessageModel = 6, ResponseType = Update and what repeats, or rather becomes non-monotonous is this:

SeqNum = 59136 (I'm using fix notation, but it's not fix). So in this example, for a given symbol, we get:

SeqNum = 59136

SeqNum = 59232

*here a switchover occurs*

SeqNum = 59136

SeqNum= 59328

What worries me is that all these messages are updates(or maybe we interpret them incorrectly somehow but it doesn't look like it). Updates can be incremental in nature so I guess I'm missing some kind of refresh for this symbol which would ensure consistency of the quote books.

What I wonder is whether this could cause us to generate incorrect quote books. If you're saying that RFA does not process the data, and all messages we receive from the API are updates, then it looks like there could be a bug here. I guess my question is, whether we should maintain sequence numbers per quote symbol ourselves or whether we should rely on RFA for that. If the update message we get from RFA taker into consideration.

I can ask QA to run this with tracing enabled but I'm wondering how we should process it from the user standpoint. Should we analyse the Sequence Numbers and take that into consideration, or it this the responsibility of the RFA API.

nrao

@Jirapongse Hey. Sorry, one correction here. The SeqNums are obtained using

[code]

if (respMsg.getManifest().getHintMask() & rfa::message::Manifest::SeqFlag)

{

seqNum = respMsg.getManifest().getSeqNum();

}

[/code]

so they actually come from the header, I think.

Jirapongse

@nrao

We need XML trace files to verify what the problem is.

The XML trace files are concrete evidences used to investgate this issue.

However, this forum is not a suitable channel to investigate this kind of issue. You can contact the API support team directly via Contact Premium Support to investigate this issue.

You need to have a RDC (Refinitiv Developer Connect) contact in order to access Contact Premium Support.

EXPLORE OUR SITES