When is a message FINAL

pratik.p.mehta
pratik.p.mehta Explorer
in Refinitiv Data Platform

What flags or statuses should we use to identify a final message for a given stream id?

Currently, my application uses

public boolean isFinal() {

Msg msg = decodeMsg();

return msg.isFinalMsg() || msg.msgClass() == MsgClasses.ACK;

}

Is this logic correct or we need to look for other markers in response

The application maintains a map of stream ids to their corresponding messages

Whenever the message is marked as final using isFinal() as shown above, we remove it from the map

However, what is noticed is we still get updates for those stream ids

What is the right approach?

Tagged:

Best Answer

  • umer.nalla
    umer.nalla LSEG
    Answer ✓

    Hi @pratik.p.mehta

    As you may have noted in the developer guide, the isFinalMsg() is the mechanism for confirming if a message is the final Msg on that Stream and no further messages should be received.

    Therefore, if you are observing instances where you continue to receive further messages on a stream after the isFinalMsg(), then you need to trace all incoming and outgoing messages on the channel when running your app - to a file. This XML trace can then be used to confirm if indeed you are receiving additional messages AFTER the final message. If this is the case, you would need to raise a ticket with our Premium support system and attach the trace file, so that it can be investigated offline.

    For an example of how to capture all message to a trace file, I recommend you refer to the Consumer example which traces the message to an XML file when a -x parameter is provided on the command line..

    In terms of the AckMsg / CloseMsg comment in the - when you as a Consumer send a CloseMsg to explicitly close a stream, you can optionally specify a flag indicating that you want to receive an AckMsg to confirm if the CloseMsg was accepted - this is not the same as the final Msg you receive on a Stream.

Answers

  • umer.nalla
    umer.nalla LSEG

    Hi @pratik.p.mehta

    Can you please clarify why you are treating an AckMsg as Final?

    One possible explanation for what you are observing:

    You open a stream for an item in order to perform OnStream posting, you perform an OnStream post using its stream id. After which you can expect to get an AckMsg which does NOT have isFinalMsg() set. Upon receipt of that AckMsg, (based on your above code snippet) if you then remove the corresponding stream id from your Map, the stream will still be open and you could get further updates on that stream.

  • pratik.p.mehta
    pratik.p.mehta Explorer

    Hi Umer, we don't post anything into TREP, we only consume

    Also, from the documentation, it says for ACK Message: A provider uses AckMsg to inform a consumer of success or failure for a specific PostMsg or
    CloseMsg. This is the reason why the logic accounts for Ack

    Not sure what is the best way to consider a message as closed

  • pratik.p.mehta
    pratik.p.mehta Explorer

    Thank you for the explanation - where can we all such detailed documentation?

    Could you share any links?

Categories