Thread: [Quickfix-developers] FIX message replay by a quickfix acceptor
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Andrew F. <af...@ra...> - 2005-12-13 21:55:01
|
Hello all, been looking through the online docs and list archives but haven't found anything yet so here goes - In the system i've inherited (environment is C++ on 64bit Linux), there is an "Order Matcher" (OM) which sometimes routes orders out to the outside world via a Quickfix Initiator (QI). OM and QI communicate via messaging, ie. NOT via Quickfix. Here's my task: when OM recovers from a crash, it must query QI for all events which occurred since it crashed at XX:XX time. Broadly, the options i've considered are A) QA itself responds to OM's query, or B) a separate process responds to OM's query. 1. If OM were a quickfix Initiator and QI were a quickfix Acceptor, i realize this would be a regular recovery reconnect. Given that QI acts as a sort of "Acceptor", as an Initiator object does it have access to the same replay functionality? 2. Further to option B), given that QI continuously writes to its FIX logs, would there be any problem with a secondary process reading the file? Basically i'm asking what type of file locking is the quickfix Initiator using? Any help greatly appreciated. thank you, Andrew Freese af...@ra... |
|
From: Dale W. <wil...@oc...> - 2005-12-13 22:08:04
|
Hi Andrew,
Andrew Freese wrote:
> Hello all, been looking through the online docs and list archives but
> haven't found anything yet so here goes -
>
> In the system i've inherited (environment is C++ on 64bit Linux),
> there is an "Order Matcher" (OM) which sometimes routes orders out to
> the outside world via a Quickfix Initiator (QI). OM and QI
> communicate via messaging, ie. NOT via Quickfix.
>
> Here's my task: when OM recovers from a crash, it must query QI for
> all events which occurred since it crashed at XX:XX time.
> Broadly, the options i've considered are A) QA itself responds to OM's
> query, or B) a separate process responds to OM's query.
>
>
> 1. If OM were a quickfix Initiator and QI were a quickfix Acceptor, i
> realize this would be a regular recovery reconnect. Given that QI
> acts as a sort of "Acceptor", as an Initiator object does it have
> access to the same replay functionality?
>
> 2. Further to option B), given that QI continuously writes to its FIX
> logs, would there be any problem with a secondary process reading the
> file? Basically i'm asking what type of file locking is the quickfix
> Initiator using?
Assuming you can identify the point in time at which the OM crashed and
express that in terms of the FIX sequence numbers that were in use at
the time of the crash, you can retrieve the FIX messages within the QI
(that would be option A) using code similar to:
std::vector< std::string > msgs;
session_->getStore()->get(startNum, endNum, msgs);
Then for each entry in msgs you can reconstitute a QuickFIX message
like so:
FIX::Message original(msgs[nEntry], session_->getDataDictionary());
That leaves the task of translating the FIX messages into something
meaningful to the OM, but you probably already have code to do that.
I'll leave the question of sharing the file for others to answer.
HTH,
Dale
>
>
> Any help greatly appreciated.
>
>
> thank you,
>
> Andrew Freese
> af...@ra...
>
--
-----------------------------------------------------
Dale Wilson, Senior Software Engineer
Object Computing, Inc. (OCI)
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------
|
|
From: Dale W. <wil...@oc...> - 2005-12-13 22:12:21
|
Of course right after I sent the message I realized that I'd told you how to find messages you had SENT. That's different from finding messages that arrived during the downtime which is probably what you had in mind. Oh well. To make up for my confusion, I'll point out that is fairly easy to provide a custom logger so if you don't like the file locking technique FIX uses you can roll your own relatively easily. Dale Dale Wilson wrote: > Hi Andrew, > > Andrew Freese wrote: > >> Hello all, been looking through the online docs and list archives but >> haven't found anything yet so here goes - >> >> In the system i've inherited (environment is C++ on 64bit Linux), >> there is an "Order Matcher" (OM) which sometimes routes orders out to >> the outside world via a Quickfix Initiator (QI). OM and QI >> communicate via messaging, ie. NOT via Quickfix. >> >> Here's my task: when OM recovers from a crash, it must query QI for >> all events which occurred since it crashed at XX:XX time. > > >> Broadly, the options i've considered are A) QA itself responds to >> OM's query, or B) a separate process responds to OM's query. >> >> >> 1. If OM were a quickfix Initiator and QI were a quickfix Acceptor, >> i realize this would be a regular recovery reconnect. Given that QI >> acts as a sort of "Acceptor", as an Initiator object does it have >> access to the same replay functionality? >> >> 2. Further to option B), given that QI continuously writes to its >> FIX logs, would there be any problem with a secondary process reading >> the file? Basically i'm asking what type of file locking is the >> quickfix Initiator using? > > > Assuming you can identify the point in time at which the OM crashed > and express that in terms of the FIX sequence numbers that were in use > at the time of the crash, you can retrieve the FIX messages within the > QI (that would be option A) using code similar to: > > std::vector< std::string > msgs; > session_->getStore()->get(startNum, endNum, msgs); > Then for each entry in msgs you can reconstitute a QuickFIX > message like so: > FIX::Message original(msgs[nEntry], session_->getDataDictionary()); > > That leaves the task of translating the FIX messages into something > meaningful to the OM, but you probably already have code to do that. > > I'll leave the question of sharing the file for others to answer. > > HTH, > > Dale > > >> >> >> Any help greatly appreciated. >> >> >> thank you, >> >> Andrew Freese >> af...@ra... >> > > >-- >----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ >---------------------------------------------------- > -- ----------------------------------------------------- Dale Wilson, Senior Software Engineer Object Computing, Inc. (OCI) http://www.ociweb.com/ http://www.theaceorb.com/ ---------------------------------------------------- |
|
From: Oren M. <or...@qu...> - 2005-12-13 22:33:46
|
Right you are! --oren Dale Wilson wrote: > Of course right after I sent the message I realized that I'd told you > how to find messages you had SENT. That's different from finding > messages that arrived during the downtime which is probably what you > had in mind. > > Oh well. > > To make up for my confusion, I'll point out that is fairly easy to > provide a custom logger so if you don't like the file locking > technique FIX uses you can roll your own relatively easily. > > Dale > > > Dale Wilson wrote: > >> Hi Andrew, >> >> Andrew Freese wrote: >> >>> Hello all, been looking through the online docs and list archives >>> but haven't found anything yet so here goes - >>> >>> In the system i've inherited (environment is C++ on 64bit Linux), >>> there is an "Order Matcher" (OM) which sometimes routes orders out >>> to the outside world via a Quickfix Initiator (QI). OM and QI >>> communicate via messaging, ie. NOT via Quickfix. >>> >>> Here's my task: when OM recovers from a crash, it must query QI for >>> all events which occurred since it crashed at XX:XX time. >> >> >>> Broadly, the options i've considered are A) QA itself responds to >>> OM's query, or B) a separate process responds to OM's query. >>> >>> >>> 1. If OM were a quickfix Initiator and QI were a quickfix Acceptor, >>> i realize this would be a regular recovery reconnect. Given that QI >>> acts as a sort of "Acceptor", as an Initiator object does it have >>> access to the same replay functionality? >>> >>> 2. Further to option B), given that QI continuously writes to its >>> FIX logs, would there be any problem with a secondary process >>> reading the file? Basically i'm asking what type of file locking is >>> the quickfix Initiator using? >> >> >> Assuming you can identify the point in time at which the OM crashed >> and express that in terms of the FIX sequence numbers that were in >> use at the time of the crash, you can retrieve the FIX messages >> within the QI (that would be option A) using code similar to: >> >> std::vector< std::string > msgs; >> session_->getStore()->get(startNum, endNum, msgs); >> Then for each entry in msgs you can reconstitute a QuickFIX >> message like so: >> FIX::Message original(msgs[nEntry], session_->getDataDictionary()); >> >> That leaves the task of translating the FIX messages into something >> meaningful to the OM, but you probably already have code to do that. >> >> I'll leave the question of sharing the file for others to answer. >> >> HTH, >> >> Dale >> >> >>> >>> >>> Any help greatly appreciated. >>> >>> >>> thank you, >>> >>> Andrew Freese >>> af...@ra... >>> >> >> >>-- >>----------------------------------------------------- >> Dale Wilson, Senior Software Engineer >> Object Computing, Inc. (OCI) >> http://www.ociweb.com/ http://www.theaceorb.com/ >>---------------------------------------------------- >> > > >-- >----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ >---------------------------------------------------- > |
|
From: Oren M. <or...@qu...> - 2005-12-13 22:29:38
|
The sessions store however only keeps track of outgoing messages. During the time that the OM is down, I would guess that no messages are going out, but some messages might be coming in as orders are executed. These messages do not get recorded in the store. So the short answer is no, the initiator cannot replay the messages you would probably be interested in. They would go into the log, but the log is not designed for retrieval. Can you read this file? I think so, as long as you did it read only. A better option might be to create your own instance of a FileStore (no reason you can't make use of this class), and use it to store messages that come in through the fromApp method. This would give you replay functionality for incoming messages. --oren Dale Wilson wrote: > Hi Andrew, > > Andrew Freese wrote: > >> Hello all, been looking through the online docs and list archives but >> haven't found anything yet so here goes - >> >> In the system i've inherited (environment is C++ on 64bit Linux), >> there is an "Order Matcher" (OM) which sometimes routes orders out to >> the outside world via a Quickfix Initiator (QI). OM and QI >> communicate via messaging, ie. NOT via Quickfix. >> >> Here's my task: when OM recovers from a crash, it must query QI for >> all events which occurred since it crashed at XX:XX time. > > >> Broadly, the options i've considered are A) QA itself responds to >> OM's query, or B) a separate process responds to OM's query. >> >> >> 1. If OM were a quickfix Initiator and QI were a quickfix Acceptor, >> i realize this would be a regular recovery reconnect. Given that QI >> acts as a sort of "Acceptor", as an Initiator object does it have >> access to the same replay functionality? >> >> 2. Further to option B), given that QI continuously writes to its >> FIX logs, would there be any problem with a secondary process reading >> the file? Basically i'm asking what type of file locking is the >> quickfix Initiator using? > > > Assuming you can identify the point in time at which the OM crashed > and express that in terms of the FIX sequence numbers that were in use > at the time of the crash, you can retrieve the FIX messages within the > QI (that would be option A) using code similar to: > > std::vector< std::string > msgs; > session_->getStore()->get(startNum, endNum, msgs); > Then for each entry in msgs you can reconstitute a QuickFIX > message like so: > FIX::Message original(msgs[nEntry], session_->getDataDictionary()); > > That leaves the task of translating the FIX messages into something > meaningful to the OM, but you probably already have code to do that. > > I'll leave the question of sharing the file for others to answer. > > HTH, > > Dale > > >> >> >> Any help greatly appreciated. >> >> >> thank you, >> >> Andrew Freese >> af...@ra... >> > > >-- >----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ >---------------------------------------------------- > |
