question

Upvotes
Accepted
pratik.p.mehta avatar image
2 ●3 ●5 ●8

When is a message FINAL

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?

elektron-sdkrfardp-apirefinitiv-data-platform
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

4 Answers

Upvote
Accepted
umer.nalla avatar image
25k ●87 ●11 ●23

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
umer.nalla avatar image
25k ●87 ●11 ●23

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
pratik.p.mehta avatar image
2 ●3 ●5 ●8

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

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
pratik.p.mehta avatar image
2 ●3 ●5 ●8

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

Could you share any links?

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.