quickfix-developers Mailing List for QuickFIX (Page 7)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <daw...@ya...> - 2016-11-08 03:28:15
|
Yes understood. You're a hardcore FIX guy haha. I'm new to this. Agreed - the FIX messages are fine. The columns got me confused. I wonder if that is a bug or intentional(?). ----- Original Message ----- >From: Grant Birchmeier <gbi...@co...> >To: daw...@ya... >Cc: "qui...@li..." <qui...@li...> >Date: 2016/11/8, Tue 12:21 >Subject: Re: [Quickfix-developers] MySql Log - sender and target comp ids wrong for incoming messages > > >Oh, I see -- you're looking at the sendercompid/targetcompid columns in your DB table. I didn't even look at those; because I instinctively ignore anything that is not raw FIX. My eyes went directly to the raw messages in the column on the right. (Always look at raw FIX messaging first!) > > >In that raw message column, you can see that tags 49 and 56 are set exactly as they ought to be. > > >The DB logging implementation appears to be setting the sender/target compid columns to match the client that is being logged, no matter whether the message is going in or out. (I've never used the DB logger myself.) > > > > > > >On Mon, Nov 7, 2016 at 6:13 PM, <daw...@ya...> wrote: > >Hi Grant, Thanks for your response. Maybe I misunderstood how this should work. The logging here is enabled on the client app but it's capturing messages going both ways. So looking at the attached pic the first entry in the messages_log table entry is the client login request to the executor:- >> >> >>id: 1 >>sendercompid: CLIENT_A >>targetcompid: EXECUTOR >>text: >>8=FIX.4.49=8235=A34=149= CLIENT_A52=20161107-14:31:50. 87256=EXECUTOR98=0108=6000554= pass10=197 >> >>That's what I would expect to see. Then the 2nd entry is the response from the executor. >> >> >>id: 2 >>sendercompid: CLIENT_A >>targetcompid: EXECUTOR >>text: >>8=FIX.4.49=7335=A34=149= EXECUTOR52=20161107-14:31:50. 91356=CLIENT_A98=0108=600010= 046 >>In this case shouldn't the sendercompid field show 'EXECUTOR' and the targetcompid field show 'CLIENT_A' as per the fix message? Or because the logging is enabled on the client side sendercompid will always be CLIENT_A and targetcompid will always be EXECUTOR? >> >>Thanks, >>Dermot >> >> >>Original Message ----- ----- From:Grant Birchmeier <Gbirchmeierattoconnamara.Com> To:Dawntrader001attoyahoo.Co.Jp Cc:"Quickfix-developersattolists. Sourceforge.Net" <Quickfix-Developers Atto Lists.Sourceforge.Net> Date:2016/11/8, Tue 06:44 Subject:Re: [Quickfix-Developers] MySql Log - Sender And Target Comp Ids Wrong For Incoming Messages >>> >>> >>> >>> >>> >>> >>> >>>I'm not sure what you are asking. There's nothing wrong with your log. >>> >>> >>> >>> >>>Mon On, Nov 7, 2016 At 9:33 AM AM, < Dawntrader001attoyahoo.Co.Jp>Wrote: >>> >>>Documentation QuickFIX: Http://Www.Quickfixengine.Org/ Quickfix / doc / Html / >>>> >>>> >>>> >>>>Pic attached this time ... >>>> >>>> >>>> >>>> >>>>Hi Guys, I Just Enabled MySql Logs And Tested With A Simple Log In And Log Out (Please See The Pic In Link). For Incoming Messages The Sendercompid Shows The Client App And The Targetcompid Shows The Executor App So Basically Sender And Target Are The same for all messages. Any Ideas? >>>>Thanks, >>>>Dermot >>>>------------------------------ -------------------- ------------------ ---------- >>>>Developer Access Program For Intel Xeon Phi Processors >>>>Access To Intel Xeon Phi Processor-Based Developer Platforms. >>>>With One Year . Of Intel Parallel Studio XE >>>>. Training And Support From Colfax >>>>. Order Your Platform Today Http://Sdm.Link/xeonphi >>>>______________________________ _________________ >>>>Quickfix-Developers Mailing List Quickfix-Developers Atto Lists sourceforge.net. https: //Lists.Sourceforge. net / lists / listinfo / quickfix- developers >>>> >>>> >>>> >>> >>> >>> >>>- >>> >>>Grant Birchmeier >>> >>>Connamara Systems, LLC >>> >>>Made-To-Measure Trading Solutions. >>>Exactly what you need. No more. No less. >>> >>>http://connamara.com >>> >>> >>> > > > >-- > >Grant Birchmeier > >Connamara Systems, LLC > >Made-To-Measure Trading Solutions. >Exactly what you need. No more. No less. > >http://connamara.com > > > |
|
From: Grant B. <gbi...@co...> - 2016-11-08 03:21:37
|
Oh, I see -- you're looking at the sendercompid/targetcompid columns in your DB table. I didn't even look at those; because I instinctively ignore anything that is not raw FIX. My eyes went directly to the raw messages in the column on the right. (Always look at raw FIX messaging first!) In that raw message column, you can see that tags 49 and 56 are set exactly as they ought to be. The DB logging implementation appears to be setting the sender/target compid columns to match the client that is being logged, no matter whether the message is going in or out. (I've never used the DB logger myself.) On Mon, Nov 7, 2016 at 6:13 PM, <daw...@ya...> wrote: > Hi Grant, Thanks for your response. Maybe I misunderstood how this should > work. The logging here is enabled on the client app but it's capturing > messages going both ways. So looking at the attached pic the first entry in > the messages_log table entry is the client login request to the executor:- > > id: 1 > sendercompid: CLIENT_A > targetcompid: EXECUTOR > text: > 8=FIX.4.49=8235=A34=149=CLIENT_A52=20161107-14:31:50. > 87256=EXECUTOR98=0108=6000554=pass10=197 > > That's what I would expect to see. Then the 2nd entry is the response from > the executor. > > id: 2 > sendercompid: CLIENT_A > targetcompid: EXECUTOR > text: > 8=FIX.4.49=7335=A34=149=EXECUTOR52=20161107-14:31:50. > 91356=CLIENT_A98=0108=600010=046 > In this case shouldn't the sendercompid field show 'EXECUTOR' and the > targetcompid field show 'CLIENT_A' as per the fix message? Or because the > logging is enabled on the client side sendercompid will always be CLIENT_A > and targetcompid will always be EXECUTOR? > > Thanks, > Dermot > > Original Message ----- ----- *From:* Grant Birchmeier > <Gbirchmeierattoconnamara.Com> *To:* Dawntrader001attoyahoo.Co.Jp *Cc:* " > Quickfix-developersattolists.Sourceforge.Net" <Quickfix-Developers Atto > Lists.Sourceforge.Net> *Date:* 2016/11/8, Tue 06:44 *Subject:* Re: > [Quickfix-Developers] MySql Log - Sender And Target Comp Ids Wrong For > Incoming Messages > > > > > > > I'm not sure what you are asking. There's nothing wrong with your log. > > > Mon On, Nov 7, 2016 At 9:33 AM AM, < Dawntrader001attoyahoo.Co.Jp > <daw...@ya...> > Wrote: > > Documentation QuickFIX: Http://Www.Quickfixengine.Org/ Quickfix / doc / > Html / <http://www.quickfixengine.org/quickfix/doc/html/> > > > Pic attached this time ... > > > Hi Guys, I Just Enabled MySql Logs And Tested With A Simple Log In And Log > Out (Please See The Pic In Link). For Incoming Messages The Sendercompid > Shows The Client App And The Targetcompid Shows The Executor App So > Basically Sender And Target Are The same for all messages. Any Ideas? > Thanks, > Dermot > > ------------------------------ -------------------- ------------------ > ---------- > Developer Access Program For Intel Xeon Phi Processors > Access To Intel Xeon Phi Processor-Based Developer Platforms. > With One Year . Of Intel Parallel Studio XE > . Training And Support From Colfax > . Order Your Platform Today Http://Sdm.Link/xeonphi > <http://sdm.link/xeonphi> > ______________________________ _________________ > Quickfix-Developers Mailing List Quickfix-Developers Atto Lists > sourceforge.net. <Qui...@li...>https: > //Lists.Sourceforge. net / lists / listinfo / quickfix- developers > <https://lists.sourceforge.net/lists/listinfo/quickfix-developers> > <Qui...@li...> > <https://lists.sourceforge.net/lists/listinfo/quickfix-developers> > > > > > - > Grant Birchmeier > *Connamara Systems, LLC* > *Made-To-Measure Trading Solutions.* > Exactly what you need. No more. No less. > http://connamara.com > > > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com |
|
From: <daw...@ya...> - 2016-11-08 00:14:06
|
Hi Grant, Thanks for your response. Maybe I misunderstood how this should work. The logging here is enabled on the client app but it's capturing messages going both ways. So looking at the attached pic the first entry in the messages_log table entry is the client login request to the executor:- id: 1 sendercompid: CLIENT_A targetcompid: EXECUTOR text: 8=FIX.4.49=8235=A34=149=CLIENT_A52=20161107-14:31:50.87256=EXECUTOR98=0108=6000554=pass10=197 That's what I would expect to see. Then the 2nd entry is the response from the executor. id: 2 sendercompid: CLIENT_A targetcompid: EXECUTOR text: 8=FIX.4.49=7335=A34=149=EXECUTOR52=20161107-14:31:50.91356=CLIENT_A98=0108=600010=046 In this case shouldn't the sendercompid field show 'EXECUTOR' and the targetcompid field show 'CLIENT_A' as per the fix message? Or because the logging is enabled on the client side sendercompid will always be CLIENT_A and targetcompid will always be EXECUTOR? Thanks, Dermot Original Message ----- ----- From:Grant Birchmeier <Gbirchmeierattoconnamara.Com> To:Dawntrader001attoyahoo.Co.Jp Cc:"Quickfix-developersattolists.Sourceforge.Net" <Quickfix-Developers Atto Lists.Sourceforge.Net> Date:2016/11/8, Tue 06:44 Subject:Re: [Quickfix-Developers] MySql Log - Sender And Target Comp Ids Wrong For Incoming Messages > > > > > > > >I'm not sure what you are asking. There's nothing wrong with your log. > > > > >Mon On, Nov 7, 2016 At 9:33 AM AM, < Dawntrader001attoyahoo.Co.Jp>Wrote: > >Documentation QuickFIX: Http://Www.Quickfixengine.Org/ Quickfix / doc / Html / >> >> >> >>Pic attached this time ... >> >> >> >> >>Hi Guys, I Just Enabled MySql Logs And Tested With A Simple Log In And Log Out (Please See The Pic In Link). For Incoming Messages The Sendercompid Shows The Client App And The Targetcompid Shows The Executor App So Basically Sender And Target Are The same for all messages. Any Ideas? >>Thanks, >>Dermot >>------------------------------ -------------------- ------------------ ---------- >>Developer Access Program For Intel Xeon Phi Processors >>Access To Intel Xeon Phi Processor-Based Developer Platforms. >>With One Year . Of Intel Parallel Studio XE >>. Training And Support From Colfax >>. Order Your Platform Today Http://Sdm.Link/xeonphi >>______________________________ _________________ >>Quickfix-Developers Mailing List Quickfix-Developers Atto Lists sourceforge.net. https: //Lists.Sourceforge. net / lists / listinfo / quickfix- developers >> >> >> > > > >- > >Grant Birchmeier > >Connamara Systems, LLC > >Made-To-Measure Trading Solutions. >Exactly what you need. No more. No less. > >http://connamara.com > > > |
|
From: Grant B. <gbi...@co...> - 2016-11-07 22:15:35
|
I'm not sure what you are asking. There's nothing wrong with your log. On Mon, Nov 7, 2016 at 9:33 AM, <daw...@ya...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > > Pic attached this time ... > > > Hi Guys, I Just Enabled MySql Logs And Tested With A Simple Log In And Log > Out (Please See The Pic In Link). For Incoming Messages The Sendercompid > Shows The Client App And The Targetcompid Shows The Executor App So > Basically Sender And Target Are The same for all messages. Any Ideas? > Thanks, > Dermot > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com |
|
From: Dale W. <wi...@oc...> - 2016-11-07 16:50:36
|
Did you enable logging on the executor or on the client? Based on your description of what you are seeing I'll assume the logging is being done by the executor. You say: > for incoming message the SenderCompID shows the client app. -- That is correct, The client app sent the message that is incoming to the executor. > and TargetCompID shows the executor App --- That is correct. Messages sent to the executor will use the executor's TargetCompID In other words, what is the problem? What were you expecting to see? Dale On Mon, Nov 7, 2016 at 9:27 AM, <daw...@ya...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > > Hi Guys, I just enabled MySql logs and tested with a simple log in and log > out (please see the pic in link). For incoming messages the Sendercompid > shows the client app and the Targetcompid shows the executor app so > basically sender and target are the same for all messages. Any Ideas? > Thanks, > Dermot > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- Dale Wilson Principal Software Engineer Object Computing, Inc. |
|
From: <daw...@ya...> - 2016-11-07 15:34:10
|
Pic attached this time ... Hi Guys, I Just Enabled MySql Logs And Tested With A Simple Log In And Log Out (Please See The Pic In Link). For Incoming Messages The Sendercompid Shows The Client App And The Targetcompid Shows The Executor App So Basically Sender And Target Are The same for all messages. Any Ideas? Thanks, Dermot |
|
From: <daw...@ya...> - 2016-11-07 15:27:53
|
Hi Guys, I just enabled MySql logs and tested with a simple log in and log out (please see the pic in link). For incoming messages the Sendercompid shows the client app and the Targetcompid shows the executor app so basically sender and target are the same for all messages. Any Ideas? Thanks, Dermot |
|
From: <daw...@ya...> - 2016-11-01 15:16:54
|
Cool! Thanks a lot Mike. I'm surprised this one hasn't come up before. Dermot ----- Original Message ----- >From: Mike Gatny <mg...@co...> >To: daw...@ya... >Cc: "qui...@li..." <qui...@li...> >Date: 2016/11/1, Tue 22:31 >Subject: Re: [Quickfix-developers] 'executor' sending incorrect ExecType > > >I was able to reproduce it -- this is a bug in the executor. It should be sending ExecType=TRADE instead of ExecType=FILL for FIX.4.4 and up. > > >PR here: https://github.com/quickfix/quickfix/pull/118/files > > > >--Mike Gatny >Connamara Systems, LLC > >On Tue, Nov 1, 2016 at 6:04 AM, <daw...@ya...>wrote: > >QuickFIX Documentation: http://www.quickfixengine.org/ quickfix/doc/html/ >> >> >> >>Hi Guys, Still looking for help on this one. Any ideas? >>Thanks, >>Dermot >> >> >>Original Message ----- ----- From:"Dawntrader001attoyahoo.Co.Jp" <Dawntrader001attoyahoo.Co.Jp> To:"Quickfix-developersattolists. Sourceforge.Net" <Quickfix-Developers Atto Lists.Sourceforge.Net> Date:2016/10/6, Thu 11:12 Subject:'Executor' Sending Incorrect ExecType >>> >>> >>> >>> >>> >>> >>>Hi folks, I'm doing some testing using the sample programs tradeclient <->.. Executor executor is sending back ExecType = 2 which is being rejected by tradeclient Both cfg files are set up with BeginString = FIX.4.4 and both are pointing to the same FIX44.xml data dictionary. >>> >>> >>>8 = FIX.4.4 | 9 = 125 | 35 = D | 34 = 2 | 49 = CLIENT1 | 52 = 20161006-01: 58: 47.392 | 56 = EXECUTOR | 11 = 1 | 21 = 1 | 38 = 100 | 40 = 2 | 44 = 157 | 54 = 1 | 55 = IBM | 59 = 0 | 60 = 20161006-01: 57: 45 | 10 = 178 | >>>8 = FIX.4.4 | 9 = 136 | 35 = 8 | 34 = 2 | 49 = EXECUTOR | 52 = 20161006-01: 58: 47.517 | 56 = CLIENT1 | 6 = 157 | 11 = 1 | 14 = 100 | 17 = 3 | 31 = 157 | 32 = 100 | 37 = 3 | 38 = 100 | 39 = 2 | 54 = 1 | 55 = IBM | 150 = 2 | 151 = 0 | 10 = 042 | >>>8 = FIX.4.4 | 9 = 133 | 35 = 3 | 34 = 3 | 49 = CLIENT1 | 52 = 20161006-01: 58: 47.645 | 56 = EXECUTOR | 45 = 2 | 58 = Value is incorrect (out of range) for this tag | 371 = 150 | 372 = 8 | 373 = 5 | 10 = 236 | >>> >>> >>>Any ideas? Thanks, >>>Dermot >>> >>> >>> >>> >>------------------------------ ------------------------------ ------------------ >>Developer Access Program for Intel Xeon Phi Processors >>Access to Intel Xeon Phi processor-based developer platforms. >>With one year of Intel Parallel Studio XE. >>Training and support from Colfax. >>Order your platform today. http://sdm.link/xeonphi >>______________________________ _________________ >>Quickfix-developers mailing listQuickfix-developers@lists. sourceforge.nethttps://lists.sourceforge.net/ lists/listinfo/quickfix- developers >> >> >> > > > |
|
From: Mike G. <mg...@co...> - 2016-11-01 13:57:46
|
I was able to reproduce it -- this is a bug in the executor. It should be sending ExecType=TRADE instead of ExecType=FILL for FIX.4.4 and up. PR here: https://github.com/quickfix/quickfix/pull/118/files -- Mike Gatny Connamara Systems, LLC On Tue, Nov 1, 2016 at 6:04 AM, <daw...@ya...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > > Hi Guys, Still looking for help on this one. Any ideas? > Thanks, > Dermot > > Original Message ----- ----- *From:* "Dawntrader001attoyahoo.Co.Jp" < > Dawntrader001attoyahoo.Co.Jp> *To:* "Quickfix-developersattolists. > Sourceforge.Net" <Quickfix-Developers Atto Lists.Sourceforge.Net> *Date:* > 2016/10/6, Thu 11:12 *Subject:* 'Executor' Sending Incorrect ExecType > > > > > > Hi folks, I'm doing some testing using the sample programs tradeclient > <->.. Executor executor is sending back ExecType = 2 which is being > rejected by tradeclient Both cfg files are set up with BeginString = > FIX.4.4 and both are pointing to the same FIX44.xml data dictionary. > > 8 = FIX.4.4 | 9 = 125 | 35 = D | 34 = 2 | 49 = CLIENT1 | 52 = 20161006-01: > 58: 47.392 | 56 = EXECUTOR | 11 = 1 | 21 = 1 | 38 = 100 | 40 = 2 | 44 = 157 > | 54 = 1 | 55 = IBM | 59 = 0 | 60 = 20161006-01: 57: 45 | 10 = 178 | > 8 = FIX.4.4 | 9 = 136 | 35 = 8 | 34 = 2 | 49 = EXECUTOR | 52 = > 20161006-01: 58: 47.517 | 56 = CLIENT1 | 6 = 157 | 11 = 1 | 14 = 100 | 17 = > 3 | 31 = 157 | 32 = 100 | 37 = 3 | 38 = 100 | 39 = 2 | 54 = 1 | 55 = IBM | > 150 = 2 | 151 = 0 | 10 = 042 | > 8 = FIX.4.4 | 9 = 133 | 35 = 3 | 34 = 3 | 49 = CLIENT1 | 52 = 20161006-01: > 58: 47.645 | 56 = EXECUTOR | 45 = 2 | 58 = Value is incorrect (out of > range) for this tag | 371 = 150 | 372 = 8 | 373 = 5 | 10 = 236 | > > Any ideas? Thanks, > Dermot > > > > > ------------------------------------------------------------ > ------------------ > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: <daw...@ya...> - 2016-11-01 10:04:36
|
Hi Guys, Still looking for help on this one. Any ideas? Thanks, Dermot Original Message ----- ----- From:"Dawntrader001attoyahoo.Co.Jp" <Dawntrader001attoyahoo.Co.Jp> To:"Quickfix-developersattolists.Sourceforge.Net" <Quickfix-Developers Atto Lists.Sourceforge.Net> Date:2016/10/6, Thu 11:12 Subject:'Executor' Sending Incorrect ExecType > > > > > > >Hi folks, I'm doing some testing using the sample programs tradeclient <->.. Executor executor is sending back ExecType = 2 which is being rejected by tradeclient Both cfg files are set up with BeginString = FIX.4.4 and both are pointing to the same FIX44.xml data dictionary. > > >8 = FIX.4.4 | 9 = 125 | 35 = D | 34 = 2 | 49 = CLIENT1 | 52 = 20161006-01: 58: 47.392 | 56 = EXECUTOR | 11 = 1 | 21 = 1 | 38 = 100 | 40 = 2 | 44 = 157 | 54 = 1 | 55 = IBM | 59 = 0 | 60 = 20161006-01: 57: 45 | 10 = 178 | >8 = FIX.4.4 | 9 = 136 | 35 = 8 | 34 = 2 | 49 = EXECUTOR | 52 = 20161006-01: 58: 47.517 | 56 = CLIENT1 | 6 = 157 | 11 = 1 | 14 = 100 | 17 = 3 | 31 = 157 | 32 = 100 | 37 = 3 | 38 = 100 | 39 = 2 | 54 = 1 | 55 = IBM | 150 = 2 | 151 = 0 | 10 = 042 | >8 = FIX.4.4 | 9 = 133 | 35 = 3 | 34 = 3 | 49 = CLIENT1 | 52 = 20161006-01: 58: 47.645 | 56 = EXECUTOR | 45 = 2 | 58 = Value is incorrect (out of range) for this tag | 371 = 150 | 372 = 8 | 373 = 5 | 10 = 236 | > > >Any ideas? Thanks, >Dermot > > > > |
|
From: <daw...@ya...> - 2016-10-06 02:12:49
|
Hi folks, I'm doing some testing using the sample programs tradeclient<->executor. executor is sending back ExecType=2 which is being rejected by tradeclient. Both cfg files are set up with BeginString=FIX.4.4 and both are pointing to the same FIX44.xml data dictionary. 8=FIX.4.4|9=125|35=D|34=2|49=CLIENT1|52=20161006-01:58:47.392|56=EXECUTOR|11=1|21=1|38=100|40=2|44=157|54=1|55=IBM|59=0|60=20161006-01:57:45|10=178| 8=FIX.4.4|9=136|35=8|34=2|49=EXECUTOR|52=20161006-01:58:47.517|56=CLIENT1|6=157|11=1|14=100|17=3|31=157|32=100|37=3|38=100|39=2|54=1|55=IBM|150=2|151=0|10=042| 8=FIX.4.4|9=133|35=3|34=3|49=CLIENT1|52=20161006-01:58:47.645|56=EXECUTOR|45=2|58=Value is incorrect (out of range) for this tag|371=150|372=8|373=5|10=236| Any ideas? Thanks, Dermot |
|
From: Asher N. <ash...@gm...> - 2016-10-05 18:08:49
|
Is sending a resend request to your broker causing issues when the sequence number is bumped? If not, I'd probably just live with the behavior, given that reconnects should be relatively infrequent during a session. Given that there aren't really negative side effects beyond a tiny delay on reconnect, it seems like a pretty harmless issue unless I'm missing something. On Wed, Oct 5, 2016 at 12:29 PM, <daw...@ya...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > > Hi folks, I'm new to FIX development but I'm currently building a FIX > engine for a client to talk to his broker using QuickFix C++ and FIX4.4. I > need some advice and I would really appreciate the input. Here's the > problem briefly:- > > While doing some initial connection testing vs the brokers FIX engine I > noticed every time I logged in the broker's seq. no incremented by 100 > which of course triggered a resend request from my side. I raised this > with the broker who replied as follows... [When we started interfacing > with the exchange using FIX we found anomalies with test requests and > sequences between disconnects and reconnects. (can’t recall exactly what > the issue was) An easy workaround at the time was to bump the sequence by > 100 after a re-connect and just send a fill when they ask for it. This > was clearly carried forward into our fix gateway implementation.]. > > 1. This all sounds very wrong to me, a lazy "workaround". I would at least > expect a SeqReset message from them on logout, which they are not sending. > Any thoughts on this? [yes I know sorry this is really a FIX protocol issue > but it brings to the question I really need to ask]. > > 2. Assuming they are not going to change the behaviour then how might I > work around this from my QuickFix client side? > > Thank You! > Dermot > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: <daw...@ya...> - 2016-10-05 16:29:44
|
Hi folks, I'm new to FIX development but I'm currently building a FIX engine for a client to talk to his broker using QuickFix C++ and FIX4.4. I need some advice and I would really appreciate the input. Here's the problem briefly:- While doing some initial connection testing vs the brokers FIX engine I noticed every time I logged in the broker's seq. no incremented by 100 which of course triggered a resend request from my side. I raised this with the broker who replied as follows... [When we started interfacing with the exchange using FIX we found anomalies with test requests and sequences between disconnects and reconnects. (can’t recall exactly what the issue was) An easy workaround at the time was to bump the sequence by 100 after a re-connect and just send a fill when they ask for it. This was clearly carried forward into our fix gateway implementation.]. 1. This all sounds very wrong to me, a lazy "workaround". I would at least expect a SeqReset message from them on logout, which they are not sending. Any thoughts on this? [yes I know sorry this is really a FIX protocol issue but it brings to the question I really need to ask]. 2. Assuming they are not going to change the behaviour then how might I work around this from my QuickFix client side? Thank You! Dermot |
|
From: Viktor P. <pohrebnyak@i.ua> - 2016-09-28 21:46:31
|
Hi, Shawn. I've replied to you on github - if you use default transport data
dictionary from quickfix "spec/FIXT11.xml" then it is incomplete as it lacks
some values for tag 35 like "BZ" etc. I was able to get the same error when
parsing MassOrderActionReport message while using dd from "spec/FIXT11.xml".
And I got no error when parsing the same message using one of my custom
dictionaries.
Here is all available values for this tag starting from "B":
<value enum='BA' description='COLLATERAL_REPORT'/>
<value enum='BB' description='COLLATERAL_INQUIRY'/>
<value enum='BC' description='NETWORK_STATUS_REQUEST'/>
<value enum='BD' description='NETWORK_STATUS_RESPONSE'/>
<value enum='BE' description='USER_REQUEST'/>
<value enum='BF' description='USER_RESPONSE'/>
<value enum='BG' description='COLLATERAL_INQUIRY_ACK'/>
<value enum='BH' description='CONFIRMATION_REQUEST'/>
<value enum='BI' description='TRADING_SESSION_LIST_REQUEST'/>
<value enum='BJ' description='TRADING_SESSION_LIST'/>
<value enum='BK' description='SECURITY_LIST_UPDATE_REPORT'/>
<value enum='BL' description='ADJUSTED_POSITION_REPORT'/>
<value enum='BM' description='ALLOCATION_INSTRUCTION_ALERT'/>
<value enum='BN' description='EXECUTION_ACKNOWLEDGEMENT'/>
<value enum='BO' description='CONTRARY_INTENTION_REPORT'/>
<value enum='BP' description='SECURITY_DEFINITION_UPDATE_REPORT'/>
This list surely lacks the "BZ" value. So "spec/FIXT11.xml" file should
definitely get fixed.
Best regards,
Viktor
--
View this message in context: http://quickfix.13857.n7.nabble.com/quickfix-rejecting-BZ-message-as-value-out-of-range-tp6820p6826.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.
|
|
From: Grant B. <gbi...@co...> - 2016-09-20 13:51:27
|
Dude, to remove yourself, follow that link at the bottom of this email and then scroll to the bottom. On Mon, Sep 19, 2016 at 4:14 PM, Haskayafx <has...@gm...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > > > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Haskayafx <has...@gm...> - 2016-09-19 21:15:02
|
|
From: Shawn M. <rob...@gm...> - 2016-09-19 19:59:06
|
20160919-06:06:39.000 : 8=FIXT.1.1 9=137 35=BZ 49=SERVX 56=SHAWN 34=12 52=20160919-06:06:39.204 11=SHAWN:CA000000000047 1369=SHAWN:CA000000000047/_ACK 1373=3 1374=7 1375=1 533=2 10=238 And this is the rejected message. I've lightly anonymized the COMPIDs but message should be viewable at https://fixparser.targetcompid.com/ On Mon, Sep 19, 2016 at 3:43 PM, Shawn Mitchell < rob...@gm...> wrote: > Thanks Grant. I've attached the DD and settings. > > On Mon, Sep 19, 2016 at 11:38 AM, Grant Birchmeier < > gbi...@co...> wrote: > >> This is bizarre. >> >> I've never seen a reject on the 35 tag before, and your DD looks >> correct. Based on what you've posted, I don't see anything wrong. >> >> Can we see your config? >> >> On Fri, Sep 16, 2016 at 5:15 PM, Shawn Mitchell < >> rob...@gm...> wrote: >> >>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ >>> >>> >>> >>> My application is the initiator and I send a MassActionRequest to >>> cancel all orders. The orders are canceled but my quickfix client rejects >>> the incoming BZ message. >>> >>> 8=FIXT.1.19=12835=334=549=SHAZZ52=20160916-21:44:19.00056=TESTA45=458=Value is incorrect (out of range) for this tag371=35372=BZ373=510=017 >>> >>> But FIX50SP2.xml has >>> >>> <message name='OrderMassActionReport' msgcat='app' msgtype='BZ'> >>> <field name='ClOrdID' required='N' /> >>> <field name='SecondaryClOrdID' required='N' /> >>> ... >>> >>> and >>> >>> <field number='35' name='MsgType' type='STRING'> >>> <value enum='0' description='HEARTBEAT' /> >>> ... >>> <value enum='BZ' description='ORDERMASSACTIONREPORT' /> >>> >>> All other message flows work properly, I receive ExecutionReport messages, >>> etc. >>> >>> So I'm at a loss. Any help from developers who have run into a similar >>> situation is much appreciated! >>> >>> ------------------------------------------------------------ >>> ------------------ >>> >>> _______________________________________________ >>> Quickfix-developers mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>> >> >> >> >> -- >> Grant Birchmeier >> *Connamara Systems, LLC* >> *Made-To-Measure Trading Solutions.* >> Exactly what you need. No more. No less. >> http://connamara.com >> > > |
|
From: Shawn M. <rob...@gm...> - 2016-09-19 19:43:52
|
# default settings for sessions [DEFAULT] ConnectionType=initiator ReconnectInterval=60 UseDataDictionary=Y ValidateUserDefinedFields=N ValidateFieldsOutOfOrder=N FileLogPath=logs DataDictionary=quickfix/spec/FIX50SP2.xml TransportDataDictionary=quickfix/spec/FIXT11.xml AppDataDictionary=quickfix/spec/FIX50SP2.xml ResetOnLogon=Y ResetOnLogout=Y ResetOnDisconnect=Y [SESSION] BeginString=FIXT.1.1 SenderCompID=SHAWN TargetCompID=TARGET username=sh...@bu... password=password1 DefaultApplVerID=FIX.5.0SP2 FileStorePath=logs/SHAWN FileLogPath=logs/SHAWN StartTime=00:00:00 EndTime=00:00:00 # overide default setting for RecconnectInterval ReconnectInterval=30 HeartBtInt=5 SocketConnectPort=4004 SocketConnectHost=100.55.45.44 # (optional) alternate connection ports and hosts to cycle through on failover [SESSION] BeginString=FIXT.1.1 SenderCompID=epqa-RM11557-bbl01 TargetCompID=TARGET username=BBL...@bi... password=12345678qa DefaultApplVerID=FIX.5.0SP2 FileStorePath=logs/BB1 FileLogPath=logs/BB1 StartTime=00:00:00 EndTime=00:00:00 # overide default setting for RecconnectInterval ReconnectInterval=30 HeartBtInt=5 SocketConnectPort=4004 SocketConnectHost=100.55.45.44 # (optional) alternate connection ports and hosts to cycle through on failover [SESSION] BeginString=FIXT.1.1 SenderCompID=SHAWN2 TargetCompID=TARGET username=sh...@bu... password=password1 DefaultApplVerID=FIX.5.0SP2 FileStorePath=logs/SHAWN2 FileLogPath=logs/SHAWN2 StartTime=00:00:00 EndTime=00:00:00 # overide default setting for RecconnectInterval ReconnectInterval=30 HeartBtInt=5 SocketConnectPort=4004 SocketConnectHost=10.67.77.130 # (optional) alternate connection ports and hosts to cycle through on failover |
|
From: Grant B. <gbi...@co...> - 2016-09-19 16:07:45
|
This is bizarre. I've never seen a reject on the 35 tag before, and your DD looks correct. Based on what you've posted, I don't see anything wrong. Can we see your config? On Fri, Sep 16, 2016 at 5:15 PM, Shawn Mitchell < rob...@gm...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > > My application is the initiator and I send a MassActionRequest to cancel > all orders. The orders are canceled but my quickfix client rejects the > incoming BZ message. > > 8=FIXT.1.19=12835=334=549=SHAZZ52=20160916-21:44:19.00056=TESTA45=458=Value is incorrect (out of range) for this tag371=35372=BZ373=510=017 > > But FIX50SP2.xml has > > <message name='OrderMassActionReport' msgcat='app' msgtype='BZ'> > <field name='ClOrdID' required='N' /> > <field name='SecondaryClOrdID' required='N' /> > ... > > and > > <field number='35' name='MsgType' type='STRING'> > <value enum='0' description='HEARTBEAT' /> > ... > <value enum='BZ' description='ORDERMASSACTIONREPORT' /> > > All other message flows work properly, I receive ExecutionReport messages, > etc. > > So I'm at a loss. Any help from developers who have run into a similar > situation is much appreciated! > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com |
|
From: Shawn M. <rob...@gm...> - 2016-09-16 22:16:34
|
My application is the initiator and I send a MassActionRequest to cancel all orders. The orders are canceled but my quickfix client rejects the incoming BZ message. 8=FIXT.1.19=12835=334=549=SHAZZ52=20160916-21:44:19.00056=TESTA45=458=Value is incorrect (out of range) for this tag371=35372=BZ373=510=017 But FIX50SP2.xml has <message name='OrderMassActionReport' msgcat='app' msgtype='BZ'> <field name='ClOrdID' required='N' /> <field name='SecondaryClOrdID' required='N' /> ... and <field number='35' name='MsgType' type='STRING'> <value enum='0' description='HEARTBEAT' /> ... <value enum='BZ' description='ORDERMASSACTIONREPORT' /> All other message flows work properly, I receive ExecutionReport messages, etc. So I'm at a loss. Any help from developers who have run into a similar situation is much appreciated! |
|
From: Simeon S. <sim...@gm...> - 2016-05-25 16:40:14
|
Yes, ResendRequest is the way to go forward here and even if quickfix had a mechanism of persisting unprocessed (wrt application layer) messages, it will not be a very useful feature. I'll pick the SeqNum from the last persisted message on disk. I know messages are delivered in-order due to TCP so I know if last message I've processed and stored to disk has SeqNum X than I've seen all messages up to and including X. On 23 May 2016 at 23:08, Michael C. Starkie <hik...@gm...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > > If the service can not be depended upon to honor a resend request it's not > a FIX service and nothing you do on the client side will guarantee against > lost data. Unless a TCP socket is closed cleanly you can still lose data. A > network card fails for example. > > What if you persisted the sequence number of the last message processed at > the application layer? Then you know which messages to ignore on a replay. > Having the application separately be able to detect a duplicate message > would be a double safeguard in case the app crashed after processing but > just before persistence. > On Mon, May 23, 2016 at 4:41 PM Viktor Pogrebnyak <pohrebnyak@i.ua> wrote: > >> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ >> >> Hi, >> >> The whole purpose of ResendRequest message is to retrieve messages that >> weren't processed by the client even when it received them. If service >> does >> not keep track of the messages being sent + lacks replay capability then >> you >> are in a big trouble, unfortunately. In your case client must not only >> remember which messages it received but also which were actually >> processed. >> >> Cheers, >> Viktor >> >> >> >> -- >> View this message in context: >> http://quickfix.13857.n7.nabble.com/Persisting-unprocessed-messages-tp6807p6810.html >> Sent from the QuickFIX - Dev mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Mobile security can be enabling, not merely restricting. Employees who >> bring their own devices (BYOD) to work are irked by the imposition of MDM >> restrictions. Mobile Device Manager Plus allows you to control only the >> apps on BYO-devices by containerizing them, leaving personal data >> untouched! >> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Michael C. S. <hik...@gm...> - 2016-05-23 22:08:55
|
If the service can not be depended upon to honor a resend request it's not a FIX service and nothing you do on the client side will guarantee against lost data. Unless a TCP socket is closed cleanly you can still lose data. A network card fails for example. What if you persisted the sequence number of the last message processed at the application layer? Then you know which messages to ignore on a replay. Having the application separately be able to detect a duplicate message would be a double safeguard in case the app crashed after processing but just before persistence. On Mon, May 23, 2016 at 4:41 PM Viktor Pogrebnyak <pohrebnyak@i.ua> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > Hi, > > The whole purpose of ResendRequest message is to retrieve messages that > weren't processed by the client even when it received them. If service does > not keep track of the messages being sent + lacks replay capability then > you > are in a big trouble, unfortunately. In your case client must not only > remember which messages it received but also which were actually processed. > > Cheers, > Viktor > > > > -- > View this message in context: > http://quickfix.13857.n7.nabble.com/Persisting-unprocessed-messages-tp6807p6810.html > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: K. F. <kfr...@gm...> - 2016-05-23 22:06:25
|
Hello Simeon! On Mon, May 23, 2016 at 11:51 AM, Simeon Simeonov <sim...@gm...> wrote: > > Hi, I have a quickfix initiator and I am trying to solve the following problem. If I have a burst of fills, quickfix will receive all the fills and start passing them to the application. The fill messages at this point have been received and are held in memory by quickfix. If the application crashes while processing the messages then what is in memory is lost. When the client restarts it has to re-request the unprocessed messages from the server which might not have them. To emphasize what Viktor said, you have a fundamental problem here. No matter how promptly you persist the messages you receive, there is always the possibility that some messages will be lost in flight. As Viktor said, that is what ResendRequest is for, and for guaranteed reliability, it is necessary for the server to remember (presumably by persisting) the messages it has sent, and to honor the ResendRequest. Let's say your client persists received messages "as soon as" it gets them. Let's say the server writes the messages it is sending to its socket and immediately deletes them from memory (because they've been sent). Now let's say your server crashes (for example, a power failure) before the network has actually delivered the messages to your application. Under these assumptions, you have an unrecoverable error because the messages have been lost for good. No matter how quickly you persist the messages you receive, there will always be such an in-flight window where messages can be lost, so you're better off implementing a robust solution that solves the problem, rather than "persisting really fast" in order to reduce the problem to a small, but non-zero level. The FIX solution is to require both sides of the FIX conversation to remember the messages they have sent, and correctly honor the ResendRequest. (You could imagine a protocol where the client sends back to the server an "I have received and persisted this message -- you can delete it on your end now" message. But you would still have to have a way -- some ResendRequest, or equivalent -- to recover any messages that were in flight when you crashed, before you had a chance to persist them.) To recap: You say "When the client restarts it has to re-request the unprocessed messages from the server which might not have them." The fact that "the server ... might not have them" means that your server is fundamentally broken, and there is no way that the FIX protocol can fix that for you. > My question is this - is there a simple way to make quickfix dump messages to disk Yes, QuickFIX will persist messages to disk and/or a database. > so that when the application crashes it can pick from where it left off? Sort of. It depends what you mean by "from where it left off." It can pick up from where it left off successfully persisting messages, but it can't necessarily pick up from where the server left off writing messages to its socket because of the in-flight issue described above. > I have enabled 'PersistMessages=Y' and I have a disk store but it doesn't seem to be picking up from where it left off upon restart. Presumably the server has written more messages than you have persisted, as described above. That is, the client's notion of "where it left off" does not match that of the server. > I am not sure what config I need to get this functionality. There is no client-side configuration that will (or could) solve the in-flight issue. You need to have your server persist the messages it sends and properly honor ResendRequest. That's the FIX way to implement this kind of fully legitimate requirement of being able to recover after a crash. > Kind regards, > Simeon Good luck. K. Frank |
|
From: Viktor P. <pohrebnyak@i.ua> - 2016-05-23 20:21:03
|
Hi, The whole purpose of ResendRequest message is to retrieve messages that weren't processed by the client even when it received them. If service does not keep track of the messages being sent + lacks replay capability then you are in a big trouble, unfortunately. In your case client must not only remember which messages it received but also which were actually processed. Cheers, Viktor -- View this message in context: http://quickfix.13857.n7.nabble.com/Persisting-unprocessed-messages-tp6807p6810.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: Simeon S. <sim...@gm...> - 2016-05-23 19:47:40
|
Thanks Viktor, I imagine this is a common problem that one needs to guard against. What is the common solution? One way would be to take messages from quickfix with minimal processing and persist them at application level then process them in a separate thread/process - this offloads persisting responsibilities to the application. Another way would be to persist the SeqNum of the last processed message and then at login request from the acceptor all messages after this. However, I will be relying on the acceptor supporting this functionality (i.e. keeping a history of messages). Do these methods sound like a reasonable way to deal with this? On 23 May 2016 at 18:36, Viktor Pogrebnyak <pohrebnyak@i.ua> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ > > Hi, > > Quickfix extracts/processes messages from network buffer one-by-one and > writes them to the disk if configured. There is no way to force behavior > you > want in the current engine. > > Cheers, > Viktor > > > > -- > View this message in context: > http://quickfix.13857.n7.nabble.com/Persisting-unprocessed-messages-tp6807p6808.html > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of MDM > restrictions. Mobile Device Manager Plus allows you to control only the > apps on BYO-devices by containerizing them, leaving personal data > untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
98 messages has been excluded from this view by a project administrator.
