RE: [Quickfix-users] Crash scenarios in QuickFix
Brought to you by:
orenmnero
Menu
▾
▴
RE: [Quickfix-users] Crash scenarios in QuickFix
|
From: <OM...@th...> - 2002-09-04 13:30:35
|
Yeah, I was just thinking about that. I think that a good argument to keep
them separate is if someone wants to make some sort of administrative tool
that uses the MessageStore interface to modify their databases/files. In
this case I think that it would be useful to keep them separate.
Their are a couple of ways to handle making the change. You can either
submit it as a request on the list (which you just did). In which case you
can wait for it to appear in a future release. OR, you can be more
proactive! You can make the change to your codebase and submit it to the
list. That way you will have what you need immediately, anybody else who
wants that change can use it in the meantime, and we can incorporate the
change into a future release.
--oren
"Stancescu
Constantin" To: <OM...@th...>
<Constantin.Stances cc: <qui...@li...>,
cu...@sw...> <qui...@li...>
Subject: RE: [Quickfix-users] Crash scenarios in QuickFix
09/04/2002 07:50 AM
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
"Stancescu Constantin"
<Con...@sw...> To:
<qui...@li...>
Sent by: cc:
"Stancescu Constantin" <Con...@sw...>
qui...@li... Subject:
[Quickfix-users] Crash scenarios in QuickFix
ceforge.net
09/04/2002 05:12 AM
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=sourceforge1&refcode1=vs3390
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users
|
