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

[Brendan B. B. <br...@ka...>]

Oren,

My example was a poor choice as it illustrated gaps in heartbeats
which as you correctly note it's ok to have gaps for which I offer my
apologies.

The problem manifests when gaps occur when an App message,
specifically a NewOrderSingle, isn't logged.

My recollection is that the client wasn't issuing a SequenceReset in
this case either although I'll need to doublecheck that.

Regards,
Brendan


  -----Original Message-----
  From: qui...@li...
[mailto:qui...@li...]On Behalf Of Oren
Miller
  Sent: Sunday, July 13, 2003 12:00 PM
  To: br...@ka...; Quickfix-Users
  Subject: RE: [Quickfix-users] What is correct behavior if sender has
error sending msg?


  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!