RE: [Quickfix-users] What is correct behavior if sender has error sending msg?

[Oren M. <ore...@ya...>]

Well gaps in the message store are perfectly normal.  QF only stores messages that can be resent (i.e., application messages).  So messages like heartbeats for instance do not get stored.  You should check your log file to verify that the message gap is caused by some administrative message, which is expected behavior. Message gaps in the filestore won't cause a problem because QF will just insert SequenceReset/Gap Fill messages during a resend.

"Brendan B. Boerner" <br...@ka...> wrote: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 :-(.

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





---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!