RE: [Quickfix-users] What is correct behavior if sender has error sending msg?
Brought to you by:
orenmnero
From: Brendan B. B. <br...@ka...> - 2003-07-11 22:57:54
|
Oren, Thanks for the reply. Comments below. > -----Original Message----- > From: Oren Miller [mailto:ore...@ya...] > m_state.set( msgSeqNum, messageString ); > m_state.incrNextSenderMsgSeqNum(); > > This is ok whether or not the send is succesful, > because the message will be resent sometime in the > future. When send returns true, it actually isn't This is done when an attempt to send another msg occurs or in the background? > terribly informative since it really could be > logically false. It is true if we send on the socket > and it returns false we know it failed, but if it > returns true, at best we think it likely succeeded but > maybe not. This is because we don't know if the > counterparty processed it and is as good as not sent. > So the success of any particular send doesn't really > matter in the context of post processing. > > In fact, some people have pointed out recently > (rightfully) that storage should be done *before* we > even attempt to send. And if we store and increment > before sending, then the irrelevancy of that return > value becomes more clear. > > Did you experience a particular problem with this? Yes, but now that I'm trying to reproduce it, I can't <grrrr> :-(. What I was seeing were 'gaps' in the message store e.g. 8=FIX.4.1^A9=60^A35=2^A34=100^A49=CLYN7^A52=20030711-20:08:00^A56=SLK^A7=87^ A16=91^A10=165^A 8=FIX.4.1^A9=60^A35=2^A34=101^A49=CLYN7^A52=20030711-20:08:00^A56=SLK^A7=87^ A16=92^A10=167^A 8=FIX.4.1^A9=60^A35=2^A34=103^A49=CLYN7^A52=20030711-20:08:00^A56=SLK^A7=87^ A16=94^A10=171^A 8=FIX.4.1^A9=60^A35=2^A34=104^A49=CLYN7^A52=20030711-20:08:00^A56=SLK^A7=87^ A16=95^A10=173^A which would cause the target to issue a resend request. Since it couldn't be honored the target wouldn't allow further processing (I'm pretty sure that the Sender didn't issue a Sequence Reset in this case either). Next time I can reproduce I'll debug further. Regards, Brendan |