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?
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.
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.
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
Thank you for the explanation - where can we all such detailed documentation?
Could you share any links?