Imported from previous forum
The FIX Transport 1.1 document has contradictory advice for handling resend requests…
Page 11 in the document…
“It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, … which can result in many resent PossDupFlag=Y messages.”
But on page 24 in the document…
“Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.”
In this second recommendation out of sequence messages should be “ignored” and not stored in a temporary queue.
Ideally it would be good to home in on one of the 2 methods and recommend them or even go as far a mandating them.
Under “normal” circumstances resend request processing tends to occur at logon. Other scenarios generally occur when there are network issues or general code errors.
Clive
Clive - who wrote that piece of crap FIXT.1.1 transport document anyway?
There has been these two approaches. I thought the Implementation and Optimization Working Group came up with a definitive recommendation? If so, we should revise the FIXT.1.1 specification text and put out a text errata.
Same for your other post.
The FIX Transport 1.1 document has contradictory advice for handling resend requests…
Page 11 in the document…
“It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, … which can result in many resent PossDupFlag=Y messages.”
But on page 24 in the document…
“Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.”
In this second recommendation out of sequence messages should be “ignored” and not stored in a temporary queue.
Ideally it would be good to home in on one of the 2 methods and recommend them or even go as far a mandating them.
Under “normal” circumstances resend request processing tends to occur at logon. Other scenarios generally occur when there are network issues or general code errors.
Clive
General recommendation is:
More recent FIX specifications recommend that implementers of FIX engines should send ResendRequests using the “thru infinity” method while continuing to support reception of ResendRequests that use either method.
The IOWG white paper has great advice on how to optimise the resend request process and how to handle erroneous situations. The initial key point being: issue a single resend-request through-inifinity and ignore subsequent messages that arrive out of sequence (so don’t queue).
I agree we should revise the FIXT.1.1 transport document.
Clive
Clive - who wrote that piece of crap FIXT.1.1 transport document anyway?
There has been these two approaches. I thought the Implementation and Optimization Working Group came up with a definitive recommendation? If so, we should revise the FIXT.1.1 specification text and put out a text errata.
Same for your other post.
The FIX Transport 1.1 document has contradictory advice for handling resend requests…
Page 11 in the document…
“It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, … which can result in many resent PossDupFlag=Y messages.”
But on page 24 in the document…
“Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.”
In this second recommendation out of sequence messages should be “ignored” and not stored in a temporary queue.
Ideally it would be good to home in on one of the 2 methods and recommend them or even go as far a mandating them.
Under “normal” circumstances resend request processing tends to occur at logon. Other scenarios generally occur when there are network issues or general code errors.
Clive
Captured as Jira Item #SPEC-355 - we probably should prepare a FIXT.1.1 Errata 2.
Can you please give us the link to IOWG white paper?
Thanks in advance!
General recommendation is:
More recent FIX specifications recommend that implementers of FIX engines should send ResendRequests using the “thru infinity” method while continuing to support reception of ResendRequests that use either method.
The IOWG white paper has great advice on how to optimise the resend request process and how to handle erroneous situations. The initial key point being: issue a single resend-request through-inifinity and ignore subsequent messages that arrive out of sequence (so don’t queue).
I agree we should revise the FIXT.1.1 transport document.
Clive
Clive - who wrote that piece of crap FIXT.1.1 transport document anyway?
There has been these two approaches. I thought the Implementation and Optimization Working Group came up with a definitive recommendation? If so, we should revise the FIXT.1.1 specification text and put out a text errata.
Same for your other post.
The FIX Transport 1.1 document has contradictory advice for handling resend requests…
Page 11 in the document…
“It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, … which can result in many resent PossDupFlag=Y messages.”
But on page 24 in the document…
“Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.”
In this second recommendation out of sequence messages should be “ignored” and not stored in a temporary queue.
Ideally it would be good to home in on one of the 2 methods and recommend them or even go as far a mandating them.
Under “normal” circumstances resend request processing tends to occur at logon. Other scenarios generally occur when there are network issues or general code errors.
Clive
Found one - http://fixprotocol.org/documents/4511/IandOWG_April2009.pdf
Are there more?
Can you please give us the link to IOWG white paper?
Thanks in advance!
General recommendation is:
More recent FIX specifications recommend that implementers of FIX engines should send ResendRequests using the “thru infinity” method while continuing to support reception of ResendRequests that use either method.
The IOWG white paper has great advice on how to optimise the resend request process and how to handle erroneous situations. The initial key point being: issue a single resend-request through-inifinity and ignore subsequent messages that arrive out of sequence (so don’t queue).
I agree we should revise the FIXT.1.1 transport document.
Clive
Clive - who wrote that piece of crap FIXT.1.1 transport document anyway?
There has been these two approaches. I thought the Implementation and Optimization Working Group came up with a definitive recommendation? If so, we should revise the FIXT.1.1 specification text and put out a text errata.
Same for your other post.
The FIX Transport 1.1 document has contradictory advice for handling resend requests…
Page 11 in the document…
“It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, … which can result in many resent PossDupFlag=Y messages.”
But on page 24 in the document…
“Note: it is imperative that the receiving application process messages in sequence order, e.g. if message number 7 is missed and 8-9 received, the application should ignore 8 and 9 and ask for a resend of 7-9, or, preferably, 7-0 (0 represents infinity). This latter approach is strongly recommended to recover from out of sequence conditions as it allows for faster recovery in the presence of certain race conditions when both sides are simultaneously attempting to recover a gap.”
In this second recommendation out of sequence messages should be “ignored” and not stored in a temporary queue.
Ideally it would be good to home in on one of the 2 methods and recommend them or even go as far a mandating them.
Under “normal” circumstances resend request processing tends to occur at logon. Other scenarios generally occur when there are network issues or general code errors.
Clive