Imported from previous forum
Hello,
When a sequence number mismatch happens, can I assume there must be a message contains “MsgSeqNum too high/low, expecting xxxx but received oooo”? On both initiator and acceptor side?
Can I rely on greping “expecting xxxx” to resync the sequence number?
Thank you,
Wei-Jen
Hi Wei-Jen,
if your side comes with a sequence number lower than expected, then you get silently disconnected or logged out.
In the latter case, some enginescsend a message indicating which sequence number was expected, but you cannot rely on that. Most of the
time, manual action is required or you wait until the increasing sequence number of the Logon message reaches the number expected by the other side. This can take a while…
If your side comes with a sequence number higher than expected, then the other side assumes that it must missed some messages and sends a FIX
ResendRequest asking for the missing messages. This case is handled
automatically by the FIX engine for you and usually occurs if messages are
lost due to e.g. network issues.
Hope this helps, Jörg
When a sequence number mismatch happens, can I assume there must be a message contains “MsgSeqNum too high/low, expecting xxxx but received oooo”? On both initiator and acceptor side?
Can I rely on greping “expecting xxxx” to resync the sequence number?
Thank you,
Wei-Jen
Jörg,
Thanks for replying.
My current issue is that I’m the acceptor, and when the machine crashes and we fail over to a backup machine. Our side will start at 1. The initiator side will keep the number before crash, for example, 10000.
We are looking for a way to fast (and automatically) catch up 10000.
What is the most reliable way to do this? to read tag 34? Currently I parse that “expecting xxxx” text.
Thank you.
Hi Wei-Jen,
if your side comes with a sequence number lower than expected, then you get silently disconnected or logged out.
In the latter case, some enginescsend a message indicating which sequence number was expected, but you cannot rely on that. Most of the
time, manual action is required or you wait until the increasing sequence number of the Logon message reaches the number expected by the other side. This can take a while…If your side comes with a sequence number higher than expected, then the other side assumes that it must missed some messages and sends a FIX
ResendRequest asking for the missing messages. This case is handled
automatically by the FIX engine for you and usually occurs if messages are
lost due to e.g. network issues.Hope this helps, Jörg
When a sequence number mismatch happens, can I assume there must be a message contains “MsgSeqNum too high/low, expecting xxxx but received oooo”? On both initiator and acceptor side?
Can I rely on greping “expecting xxxx” to resync the sequence number?
Thank you,
Wei-Jen
Reading tag 34 would not help, since the sequence numbers are maintained independently for both directions.
Parsing the text field of the Logout message is some sort of heuristics which works if you know that the other side (specific FIX engine) will always send this value.
For failover scenarios, it would be good to keep the session state in a shared, high-available database. Or is the session state not important?
How about any ExecutionReport message to be sent to the other side at the time the machine crashes. Are they lost?
Cheers, Jörg
My current issue is that I’m the acceptor, and when the machine crashes and we fail over to a backup machine. Our side will start at 1. The initiator side will keep the number before crash, for example, 10000.
We are looking for a way to fast (and automatically) catch up 10000.
What is the most reliable way to do this? to read tag 34? Currently I parse that “expecting xxxx” text.Thank you.
Hi Wei-Jen,
if your side comes with a sequence number lower than expected, then you get silently disconnected or logged out.
In the latter case, some enginescsend a message indicating which sequence number was expected, but you cannot rely on that. Most of the
time, manual action is required or you wait until the increasing sequence number of the Logon message reaches the number expected by the other side. This can take a while…If your side comes with a sequence number higher than expected, then the other side assumes that it must missed some messages and sends a FIX
ResendRequest asking for the missing messages. This case is handled
automatically by the FIX engine for you and usually occurs if messages are
lost due to e.g. network issues.Hope this helps, Jörg
When a sequence number mismatch happens, can I assume there must be a message contains “MsgSeqNum too high/low, expecting xxxx but received oooo”? On both initiator and acceptor side?
Can I rely on greping “expecting xxxx” to resync the sequence number?
Thank you,
Wei-Jen
Jörg and Xavier,
Thanks for the suggestions. Very helpful.
I’ll test and figure which approach is the best for our systems.
Wei-Jen
Reading tag 34 would not help, since the sequence numbers are maintained independently for both directions.
Parsing the text field of the Logout message is some sort of heuristics which works if you know that the other side (specific FIX engine) will always send this value.
For failover scenarios, it would be good to keep the session state in a shared, high-available database. Or is the session state not important?
How about any ExecutionReport message to be sent to the other side at the time the machine crashes. Are they lost?Cheers, Jörg
My current issue is that I’m the acceptor, and when the machine crashes and we fail over to a backup machine. Our side will start at 1. The initiator side will keep the number before crash, for example, 10000.
We are looking for a way to fast (and automatically) catch up 10000.
What is the most reliable way to do this? to read tag 34? Currently I parse that “expecting xxxx” text.Thank you.
Hi Wei-Jen,
I can suggest two solutions (depending on the counterpart behaviour):
- in the logon message, read the field NextExpectedMsgSeqNum (789) to initialize your outgoing sequence number;
- in your logon message, populate ResetSeqNumFlag=Y to force the counterpart to reset its sequence numbers.
Note that messages may have been lost during the crash and that they won’t never be retrieved with these solutions. So a manual check may be necessary in addition.
Regards,
Xavier.
Jörg,
Thanks for replying.
My current issue is that I’m the acceptor, and when the machine crashes and we fail over to a backup machine. Our side will start at 1. The initiator side will keep the number before crash, for example, 10000.
We are looking for a way to fast (and automatically) catch up 10000.
What is the most reliable way to do this? to read tag 34? Currently I parse that “expecting xxxx” text.Thank you.
Hi Wei-Jen,
if your side comes with a sequence number lower than expected, then you get silently disconnected or logged out.
In the latter case, some enginescsend a message indicating which sequence number was expected, but you cannot rely on that. Most of the
time, manual action is required or you wait until the increasing sequence number of the Logon message reaches the number expected by the other side. This can take a while…If your side comes with a sequence number higher than expected, then the other side assumes that it must missed some messages and sends a FIX
ResendRequest asking for the missing messages. This case is handled
automatically by the FIX engine for you and usually occurs if messages are
lost due to e.g. network issues.Hope this helps, Jörg
When a sequence number mismatch happens, can I assume there must be a message contains “MsgSeqNum too high/low, expecting xxxx but received oooo”? On both initiator and acceptor side?
Can I rely on greping “expecting xxxx” to resync the sequence number?
Thank you,
Wei-Jen