RE: [Quickfix-users] Crash scenarios in QuickFix

[Stancescu C. <Con...@sw...>]

It is OK to get rid of the increment method for the sender as long
as we are sure that nobody, in the future will have the idea of =
separating them !
About setting the Message into storage before sending, what and by whom =
should be done
in order to have this change made ?

-- constantin


-----Original Message-----
From: OM...@th... [mailto:OM...@th...]
Sent: Mittwoch, 4. September 2002 14:37
To: Stancescu Constantin
Cc: Stancescu Constantin; qui...@li...;
qui...@li...
Subject: Re: [Quickfix-users] Crash scenarios in QuickFix



Stencescu,

I definately agree with your proposals.  The first one, setting the =
Message
into storage before sending, makes a lot of sense.   I also agree with =
your
second assesment about making the storage and incrementing of the =
sequence
number more easily transactional.  In fact, looking at the code, set and
incrNextSenderMsgSeqNum are only called once and they are together.  =
This
being the case, I would propose that instead of creating a new =
incrAndSet
method, just get rid of the incr method and make it the implied behavior =
of
the set call.  What do you think?

--oren



                                                                         =
                                                                         =
  =20
                      "Stancescu Constantin"                             =
                                                                         =
  =20
                      <Con...@sw...>         To:       =
<qui...@li...>                                   =
    =20
                      Sent by:                               cc:       =
"Stancescu Constantin" <Con...@sw...>                    =
    =20
                      qui...@li...ur        Subject:  =
[Quickfix-users] Crash scenarios in QuickFix                             =
    =20
                      ceforge.net                                        =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20
                      09/04/2002 05:12 AM                                =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20
                                                                         =
                                                                         =
  =20




Hi,

I am Constantin Stancescu from SWX (Suisse Exchange) I am currently
implemented the FIX support for our trading system, based on QuickFix,
the Windows C++ version.
I have a couple of intersting subjects, this is the first of them:

As I understand the sender algorithm ( in Session.cpp Session::sendRaw)
is :

1. send()
2. m_pStore->set()                                                 //
includes disk flush
3. m_pStore->incrNextSenderMsgSeqNum()           // includes disk flush

If the application crashes after 1 (send) but before 3
(incrNextSenderMsgSeqNum)
we may have the following situation(I forced and tested it) :
- The receiver receives the message, so he will now expect n+1 as next
message.
- The sender, when restarting, will come with n < n + 1 and the logon
attempt is
rejected and we have to completely reset the session.

A couple of observations about coping with this situation:

- In this situation the send call from the user layer will never return.
Our application is written in such a way that in this case the business
message will be send again with possResend flag set, even if a new FIX
session is created with the same party. Is it reasonable to assume that
all(most) party applications will have this kind of behaviour ?

- A slight change may reduce the probability of trouble; the order
of action in Session::sendRaw should by:
             1.m_pStore->incrNextSenderMsgSeqNum()           // includes
disk flush
             2.m_pStore->set()
                                     // includes disk flush
             3.send()
             - If the application crashes after 2. but before 3., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender has all he =
needs
and we are OK.
             - If the application crashes after 1. but before 2., at
restart
             the sender will present a sequence number n+1 when the
receiver expects n.
             The receiver will ask for resend, the sender does not have =
the
message, we
             are in trouble. In our application we provide our own =
message
store implementation
             using an MSSQL database instead of FileStore.
             Step 1(incrNextSenderMsgSeqNum) and and 2(set) are part of =
the
same transaction
             so we can not crash between 1 and 2. In order to do this we
have to wait for the second
             call before commiting, it will be nicer to have just one
MessageStore call, say incrAndSet !!

What do you think about my proposal ?
Any others opininons or tips ?

Regards,
Constantin





-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users