quickfix-developers Mailing List for QuickFIX (Page 269)
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: Patrick R. <pat...@ya...> - 2003-07-26 03:30:09
|
F&O markets are difficult, few use FIX (CME for example), most have specific APIs. F&O brokers begin to develop FIX interface/gateways to their systems though. --- James Downs <jc...@co...> wrote: > I think Island has a 10 character max len, and CBOE > requires a specific > format. > > Jim > > James C. Downs > Connamara Systems, LLC > 53 W. Jackson Blvd > Suite 1627 > Chicago, IL 60604 > 312 - 282 - 7746 > www.connamara.com > > > -----Original Message----- > From: > qui...@li... > [mailto:qui...@li...] > On Behalf Of Jo > Janssens > Sent: Friday, July 25, 2003 7:36 AM > To: qui...@li... > Subject: RE: [Quickfix-developers] ClOrdID > protocol?? > > > This is an issue I have been thinking about as well > - I am planning to use a > clordid that is 16 characters. Does anyone know of a > destination that would > not support an id of at least this length?? > Presently, we route to NYSE, > various nasdaq ecn's, and all 5 options exchanges. > > If someone has had an experience where 16 chars was > too many, let me know. > > Thanks! > Jo > > -----Original Message----- > From: > qui...@li... > [mailto:qui...@li...] > On Behalf Of Oren > Miller > Sent: Thursday, July 24, 2003 10:32 > To: Andrew Munn; > qui...@li... > Subject: Re: [Quickfix-developers] ClOrdID > protocol?? > > There is no standard protocol for this. In fact, > some exchanges won't even > look at it, they often treat it as a pass thru > value. Generally, you just > need to insure somehow that it is unique for the > extent of the session. > Whatever way you choose to do that is entirely up to > you. > > One thing you should verify is the maximum length > your counterparty > supports. Although there is no restriction on the > length of a FIX field, > the counterparty usually stores this value in a > database which forces a > length restriction on their end. If their length > restriction is hig enough, > you can use a UUID. Otherwise time + counter could > be sufficient. > Or simply persisting somewhere the last id that you > used. > > --- Andrew Munn <an...@nm...> wrote: > > If a client program uses a simple counter to > > generate Order IDs and the > > client exits and then restarts, the ClOrdID is > reset > > to 1. Orders sent > > after that get a "duplicate ClOrdID" reject until > > more orders are sent > > than were sent by the previous session (when new > > ClOrdIDs start being > > generated). > > > > What is the standard procedure, if any, to ensure > > uniqueness of ClOrdIDs > > between disconnects, crashes, etc? Should an OMS > > query the message > > store on startup for the highest ClOrdID used that > > day and begin > > incrementing it? Should it assure uniqueness by > > appending a session > > counter to the end of the ID? Should it simply > tack > > on time&date? > > > > > > Thanks > > Andrew Munn > > and...@ho... > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 > /01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including Data > Reports, E-commerce, Portals, and Forums are > available now. Download today > and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 > /01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including Data > Reports, E-commerce, Portals, and Forums are > available now. Download today > and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: James D. <jc...@co...> - 2003-07-26 01:48:15
|
I think Island has a 10 character max len, and CBOE requires a specific format. Jim =20 James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Jo Janssens Sent: Friday, July 25, 2003 7:36 AM To: qui...@li... Subject: RE: [Quickfix-developers] ClOrdID protocol?? This is an issue I have been thinking about as well - I am planning to = use a clordid that is 16 characters. Does anyone know of a destination that = would not support an id of at least this length?? Presently, we route to NYSE, various nasdaq ecn's, and all 5 options exchanges. If someone has had an experience where 16 chars was too many, let me = know. Thanks! Jo -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of = Oren Miller Sent: Thursday, July 24, 2003 10:32 To: Andrew Munn; qui...@li... Subject: Re: [Quickfix-developers] ClOrdID protocol?? There is no standard protocol for this. In fact, some exchanges won't = even look at it, they often treat it as a pass thru value. Generally, you = just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX = field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig = enough, you can use a UUID. Otherwise time + counter could be sufficient.=20 Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). >=20 > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? >=20 >=20 > Thanks > Andrew Munn > and...@ho... >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 > _______________________________________________ > Quickfix-developers mailing list=20 > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including = Data Reports, E-commerce, Portals, and Forums are available now. Download = today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list = Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including = Data Reports, E-commerce, Portals, and Forums are available now. Download = today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Quickfix-developers mailing list = Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Miller, O. <OM...@ri...> - 2003-07-25 17:14:08
|
I'm trying to gather logs from everyone with this problem so we can write a test and fix this. Anyone who has this problem, please send me your event, incoming, and outgoing logs, and please mention the timestamp where the problem begins. Once we get a repeatable test this should be easy to fix. -----Original Message----- From: Andrew [mailto:and...@ho...]=20 Sent: Friday, July 25, 2003 11:20 AM To: qui...@li... Subject: RE: [Quickfix-developers] ResendRequest disapperaing? <--I'm having similar problems. Yup! That's the same thing I am seeing. =20 Oren, is there a patch for this? Andrew Munn and...@ho... -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Jo Janssens Sent: Friday, July 25, 2003 9:41 AM To: qui...@li... Subject: RE: [Quickfix-developers] ResendRequest disapperaing? <--I'm having similar problems. I am also having a problem like this. It seems that somehow the FIX engine gets into an infinite loop of resend requests. Here is my event log. I am connecting to an outside vendor who probably does not use quickfix, and I am using the c++ version of quickfix 1.5.0 now, in case this is important. Jo 20030725-14:18:59 : Created session 20030725-14:18:59 : Connecting to x.x.x.x on port 21600 20030725-14:18:59 : Connection succeeded 20030725-14:19:00 : Initiated logon request 20030725-14:19:00 : Received logon response 20030725-14:19:00 : MsgSeqNum too high RECEIVED: 104 EXPECTED: 102 20030725-14:19:00 : Sent ResendRequest FROM: 102 TO: 103 20030725-14:19:00 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:00 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:00 : Received SequenceReset FROM: 102 TO: 104 20030725-14:19:00 : Processing QUEUED message: 104 20030725-14:19:12 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:20:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:20:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:21:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:21:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : MsgSeqNum too high RECEIVED: 113 EXPECTED: 105 20030725-14:22:10 : Sent ResendRequest FROM: 105 TO: 112 20030725-14:22:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : Received SequenceReset FROM: 105 TO: 113 20030725-14:22:10 : Processing QUEUED message: 113 20030725-14:22:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : MsgSeqNum too high RECEIVED: 117 EXPECTED: 114 20030725-14:23:10 : Sent ResendRequest FROM: 114 TO: 116 20030725-14:23:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : Received SequenceReset FROM: 114 TO: 117 20030725-14:23:10 : Processing QUEUED message: 117 20030725-14:23:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : MsgSeqNum too high RECEIVED: 121 EXPECTED: 118 20030725-14:24:10 : Sent ResendRequest FROM: 118 TO: 120 20030725-14:24:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : Received SequenceReset FROM: 118 TO: 121 20030725-14:24:10 : Processing QUEUED message: 121 20030725-14:24:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : MsgSeqNum too high RECEIVED: 129 EXPECTED: 122 20030725-14:26:54 : Sent ResendRequest FROM: 122 TO: 128 20030725-14:26:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : Received SequenceReset FROM: 122 TO: 129 20030725-14:26:54 : Processing QUEUED message: 129 20030725-14:27:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:27:50 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:33 : MsgSeqNum too high RECEIVED: 135 EXPECTED: 130 20030725-14:28:33 : Sent ResendRequest FROM: 130 TO: 134 20030725-14:28:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:33 : Received SequenceReset FROM: 130 TO: 135 20030725-14:28:33 : Processing QUEUED message: 135 20030725-14:29:03 : MsgSeqNum too high RECEIVED: 137 EXPECTED: 136 20030725-14:29:03 : Sent ResendRequest FROM: 136 TO: 136 20030725-14:29:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:03 : Received SequenceReset FROM: 136 TO: 137 20030725-14:29:03 : Processing QUEUED message: 137 20030725-14:29:33 : MsgSeqNum too high RECEIVED: 139 EXPECTED: 138 20030725-14:29:33 : Sent ResendRequest FROM: 138 TO: 138 20030725-14:29:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:34 : Received SequenceReset FROM: 138 TO: 139 20030725-14:29:34 : Processing QUEUED message: 139 20030725-14:30:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:30:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:03 : MsgSeqNum too high RECEIVED: 144 EXPECTED: 140 20030725-14:31:03 : Sent ResendRequest FROM: 140 TO: 143 20030725-14:31:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:04 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:04 : Received SequenceReset FROM: 140 TO: 144 20030725-14:31:04 : Processing QUEUED message: 144 20030725-14:31:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:03 : MsgSeqNum too high RECEIVED: 148 EXPECTED: 145 20030725-14:32:03 : Sent ResendRequest FROM: 145 TO: 147 20030725-14:32:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:04 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:04 : Received SequenceReset FROM: 145 TO: 148 20030725-14:32:04 : Processing QUEUED message: 148 20030725-14:32:33 : Received ResendRequest FROM: 16 TO: 79 -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Andrew Munn Sent: Wednesday, July 23, 2003 18:09 To: qui...@li... Subject: RE: [Quickfix-developers] ResendRequest disapperaing? <--I'm having similar problems. I am having similar problems. Either I will get the repeated disconnects like those listed, or I will get a situation where I get a ResendRequest loop. Here are parts of the logs from initiator and acceptor: <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, incoming> =20 (8=3DFIX.4.1?9=3D57?35=3D0?34=3D2075?49=3DIN_MULTIFIX1?52=3D20030723-22:00:16?56=3DTW1 ?10=3D021?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2075 EXPECTED: 1967) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2480?49=3DTW1?52=3D20030723-22:00:16?5= 6=3DIN_MULTIFIX1 ?7=3D1967?16=3D2074?10=3D210?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> =20 (8=3DFIX.4.1?9=3D66?35=3D1?34=3D2481?49=3DTW1?52=3D20030723-22:00:22?56=3DIN_MULTIFIX1 ?112=3DTEST?10=3D038?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent test request TEST) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2076?49=3DIN_MULTIFIX1?52=3D20030723-22:00:22?56=3DTW1 ?7=3D2479?16=3D2480?10=3D208?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Received ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> =20 (8=3DFIX.4.1?9=3D98?35=3D4?34=3D2479?43=3DY?49=3DTW1?52=3D20030723-22:00:22?56=3DI= N_MULT IFIX1?122=3D20030723-22:00:22?36=3D2481?123=3DY?10=3D241?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent SequenceReset TO: 2481) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> =20 (8=3DFIX.4.1?9=3D66?35=3D0?34=3D2077?49=3DIN_MULTIFIX1?52=3D20030723-22:00:22?56=3DTW1 ?112=3DTEST?10=3D038?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2077 EXPECTED: 1968) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2482?49=3DTW1?52=3D20030723-22:00:22?56=3DIN_MULTIFIX1 ?7=3D1968?16=3D2076?10=3D212?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, incoming> =20 (8=3DFIX.4.1?9=3D57?35=3D0?34=3D2078?49=3DIN_MULTIFIX1?52=3D20030723-2= 2:00:52?56=3DTW1 ?10=3D024?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2078 EXPECTED: 1968) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2483?49=3DTW1?52=3D20030723-22:00:52?56=3DIN_MULTIFIX1 ?7=3D1968?16=3D2077?10=3D217?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2077) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <20030723-21:59:46, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> =20 (8=3DFIX.4.1?9=3D57?35=3D0?34=3D2075?49=3DIN_MULTIFIX1?52=3D20030723-22:00:16?56=3DTW1 ?10=3D021?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, incoming> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2480?49=3DTW1?52=3D20030723-22:00:16?56=3DIN_MULTIFIX1 ?7=3D1967?16=3D2074?10=3D210?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> =20 (8=3DFIX.4.1?9=3D66?35=3D1?34=3D2481?49=3DTW1?52=3D20030723-22:00:22?56=3DIN_MULTIFIX1 ?112=3DTEST?10=3D038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (MsgSeqNum too high RECEIVED: 2481 EXPECTED: 2479) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2076?49=3DIN_MULTIFIX1?52=3D20030723-2= 2:00:22?56=3DTW1 ?7=3D2479?16=3D2480?10=3D208?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Sent ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> =20 (8=3DFIX.4.1?9=3D98?35=3D4?34=3D2479?43=3DY?49=3DTW1?52=3D20030723-22:00:22?56=3DIN_MULT IFIX1?122=3D20030723-22:00:22?36=3D2481?123=3DY?10=3D241?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received SequenceReset FROM: 2479 TO: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Processing QUEUED message: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> =20 (8=3DFIX.4.1?9=3D66?35=3D1?34=3D2481?49=3DTW1?52=3D20030723-22:00:22?56=3DIN_MULTIFIX1 ?112=3DTEST?10=3D038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> =20 (8=3DFIX.4.1?9=3D66?35=3D0?34=3D2077?49=3DIN_MULTIFIX1?52=3D20030723-22:00:22?56=3DTW1 ?112=3DTEST?10=3D038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2482?49=3DTW1?52=3D20030723-22:00:22?56=3DIN_MULTIFIX1 ?7=3D1968?16=3D2076?10=3D212?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> =20 (8=3DFIX.4.1?9=3D57?35=3D0?34=3D2078?49=3DIN_MULTIFIX1?52=3D20030723-22:00:52?56=3DT= W1 ?10=3D024?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, incoming> =20 (8=3DFIX.4.1?9=3D72?35=3D2?34=3D2483?49=3DTW1?52=3D20030723-22:00:52?56=3DIN_MULTIFIX1 ?7=3D1968?16=3D2077?10=3D217?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2077) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Disconnecting) Thanks, Andrew -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Howard Engelhart Sent: Wednesday, July 23, 2003 3:56 PM To: qui...@li... Subject: [Quickfix-developers] ResendRequest disapperaing? I have written a FIX server (an acceptor) and a FIX Client (initiator) both=20 using QuickFIX. When my client attempts to connect to the server using a=20 MsgSeqNum that is higher than expected, the server sends back the=20 LogonRequest followed by a ResendRequest to the client (log excerpt below),=20 however I never see this second (ResendRequest) message on my client. I do=20 not see it in the message store, logs, nor can I catch it in the=20 fromAdmin/fromApp handlers. Is there something I need to be doing here? Thanks, Howard 8=3DFIX.4.29=3D6035=3DA34=3D149=3DSBI052=3D20030723-20:50:0156=3DSLGM098=3D0108=3D3010=3D150 8=3DFIX.4.29=3D5835=3D234=3D249=3DSBI052=3D20030723-20:50:0156=3DSLGM07=3D116=3D7610=3D046 20030723-20:50:01 : Received logon request 20030723-20:50:01 : Responding to logon request 20030723-20:50:01 : MsgSeqNum too high RECEIVED: 77 EXPECTED: 1 20030723-20:50:01 : Sent ResendRequest FROM: 1 TO: 76 20030723-20:50:01 : Disconnecting ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_= 01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ----------------------------------------- This email and any attachments are confidential and may be legally privileged. N= o confidentiality or privilege is waived or lost by any transmission in erro= r. If you are not the intended recipient you are hereby notified that any u= se, printing, copying or disclosure is strictly prohibited. Please delete t= his email and any attachments, without printing, copying, forwarding or savi= ng them and notify the sender immediately by reply e-mail. The company rese= rves the right to monitor all e-mail communications through its networks. U= nless otherwise stated, any financial results or price data contained in thi= s email are indicative only and are subject to change without notice. |
|
From: Andrew <and...@ho...> - 2003-07-25 16:22:27
|
Yup! That's the same thing I am seeing. Oren, is there a patch for this? Andrew Munn and...@ho... -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Jo Janssens Sent: Friday, July 25, 2003 9:41 AM To: qui...@li... Subject: RE: [Quickfix-developers] ResendRequest disapperaing? <--I'm having similar problems. I am also having a problem like this. It seems that somehow the FIX engine gets into an infinite loop of resend requests. Here is my event log. I am connecting to an outside vendor who probably does not use quickfix, and I am using the c++ version of quickfix 1.5.0 now, in case this is important. Jo 20030725-14:18:59 : Created session 20030725-14:18:59 : Connecting to x.x.x.x on port 21600 20030725-14:18:59 : Connection succeeded 20030725-14:19:00 : Initiated logon request 20030725-14:19:00 : Received logon response 20030725-14:19:00 : MsgSeqNum too high RECEIVED: 104 EXPECTED: 102 20030725-14:19:00 : Sent ResendRequest FROM: 102 TO: 103 20030725-14:19:00 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:00 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:00 : Received SequenceReset FROM: 102 TO: 104 20030725-14:19:00 : Processing QUEUED message: 104 20030725-14:19:12 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:20:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:20:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:21:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:21:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : MsgSeqNum too high RECEIVED: 113 EXPECTED: 105 20030725-14:22:10 : Sent ResendRequest FROM: 105 TO: 112 20030725-14:22:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : Received SequenceReset FROM: 105 TO: 113 20030725-14:22:10 : Processing QUEUED message: 113 20030725-14:22:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : MsgSeqNum too high RECEIVED: 117 EXPECTED: 114 20030725-14:23:10 : Sent ResendRequest FROM: 114 TO: 116 20030725-14:23:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : Received SequenceReset FROM: 114 TO: 117 20030725-14:23:10 : Processing QUEUED message: 117 20030725-14:23:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : MsgSeqNum too high RECEIVED: 121 EXPECTED: 118 20030725-14:24:10 : Sent ResendRequest FROM: 118 TO: 120 20030725-14:24:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : Received SequenceReset FROM: 118 TO: 121 20030725-14:24:10 : Processing QUEUED message: 121 20030725-14:24:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : MsgSeqNum too high RECEIVED: 129 EXPECTED: 122 20030725-14:26:54 : Sent ResendRequest FROM: 122 TO: 128 20030725-14:26:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : Received SequenceReset FROM: 122 TO: 129 20030725-14:26:54 : Processing QUEUED message: 129 20030725-14:27:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:27:50 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:33 : MsgSeqNum too high RECEIVED: 135 EXPECTED: 130 20030725-14:28:33 : Sent ResendRequest FROM: 130 TO: 134 20030725-14:28:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:33 : Received SequenceReset FROM: 130 TO: 135 20030725-14:28:33 : Processing QUEUED message: 135 20030725-14:29:03 : MsgSeqNum too high RECEIVED: 137 EXPECTED: 136 20030725-14:29:03 : Sent ResendRequest FROM: 136 TO: 136 20030725-14:29:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:03 : Received SequenceReset FROM: 136 TO: 137 20030725-14:29:03 : Processing QUEUED message: 137 20030725-14:29:33 : MsgSeqNum too high RECEIVED: 139 EXPECTED: 138 20030725-14:29:33 : Sent ResendRequest FROM: 138 TO: 138 20030725-14:29:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:34 : Received SequenceReset FROM: 138 TO: 139 20030725-14:29:34 : Processing QUEUED message: 139 20030725-14:30:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:30:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:03 : MsgSeqNum too high RECEIVED: 144 EXPECTED: 140 20030725-14:31:03 : Sent ResendRequest FROM: 140 TO: 143 20030725-14:31:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:04 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:04 : Received SequenceReset FROM: 140 TO: 144 20030725-14:31:04 : Processing QUEUED message: 144 20030725-14:31:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:03 : MsgSeqNum too high RECEIVED: 148 EXPECTED: 145 20030725-14:32:03 : Sent ResendRequest FROM: 145 TO: 147 20030725-14:32:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:04 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:04 : Received SequenceReset FROM: 145 TO: 148 20030725-14:32:04 : Processing QUEUED message: 148 20030725-14:32:33 : Received ResendRequest FROM: 16 TO: 79 -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Andrew Munn Sent: Wednesday, July 23, 2003 18:09 To: qui...@li... Subject: RE: [Quickfix-developers] ResendRequest disapperaing? <--I'm having similar problems. I am having similar problems. Either I will get the repeated disconnects like those listed, or I will get a situation where I get a ResendRequest loop. Here are parts of the logs from initiator and acceptor: <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=57?35=0?34=2075?49=IN_MULTIFIX1?52=20030723-22:00:16?56=TW1 ?10=021?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2075 EXPECTED: 1967) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2480?49=TW1?52=20030723-22:00:16?56=IN_MULTIFIX1 ?7=1967?16=2074?10=210?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent test request TEST) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=72?35=2?34=2076?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?7=2479?16=2480?10=208?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Received ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=98?35=4?34=2479?43=Y?49=TW1?52=20030723-22:00:22?56=IN_MULT IFIX1?122=20030723-22:00:22?36=2481?123=Y?10=241?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent SequenceReset TO: 2481) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=66?35=0?34=2077?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2077 EXPECTED: 1968) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2482?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?7=1968?16=2076?10=212?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=57?35=0?34=2078?49=IN_MULTIFIX1?52=20030723-22:00:52?56=TW1 ?10=024?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2078 EXPECTED: 1968) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2483?49=TW1?52=20030723-22:00:52?56=IN_MULTIFIX1 ?7=1968?16=2077?10=217?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2077) =========================================================== <20030723-21:59:46, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=57?35=0?34=2075?49=IN_MULTIFIX1?52=20030723-22:00:16?56=TW1 ?10=021?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2480?49=TW1?52=20030723-22:00:16?56=IN_MULTIFIX1 ?7=1967?16=2074?10=210?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (MsgSeqNum too high RECEIVED: 2481 EXPECTED: 2479) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=72?35=2?34=2076?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?7=2479?16=2480?10=208?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Sent ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=98?35=4?34=2479?43=Y?49=TW1?52=20030723-22:00:22?56=IN_MULT IFIX1?122=20030723-22:00:22?36=2481?123=Y?10=241?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received SequenceReset FROM: 2479 TO: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Processing QUEUED message: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=66?35=0?34=2077?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2482?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?7=1968?16=2076?10=212?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=57?35=0?34=2078?49=IN_MULTIFIX1?52=20030723-22:00:52?56=TW1 ?10=024?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2483?49=TW1?52=20030723-22:00:52?56=IN_MULTIFIX1 ?7=1968?16=2077?10=217?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2077) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Disconnecting) Thanks, Andrew -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Howard Engelhart Sent: Wednesday, July 23, 2003 3:56 PM To: qui...@li... Subject: [Quickfix-developers] ResendRequest disapperaing? I have written a FIX server (an acceptor) and a FIX Client (initiator) both using QuickFIX. When my client attempts to connect to the server using a MsgSeqNum that is higher than expected, the server sends back the LogonRequest followed by a ResendRequest to the client (log excerpt below), however I never see this second (ResendRequest) message on my client. I do not see it in the message store, logs, nor can I catch it in the fromAdmin/fromApp handlers. Is there something I need to be doing here? Thanks, Howard 8=FIX.4.29=6035=A34=149=SBI052=20030723-20:50:0156=SLGM098=0108=3010=150 8=FIX.4.29=5835=234=249=SBI052=20030723-20:50:0156=SLGM07=116=7610=046 20030723-20:50:01 : Received logon request 20030723-20:50:01 : Responding to logon request 20030723-20:50:01 : MsgSeqNum too high RECEIVED: 77 EXPECTED: 1 20030723-20:50:01 : Sent ResendRequest FROM: 1 TO: 76 20030723-20:50:01 : Disconnecting ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Joerg T. <Joe...@ma...> - 2003-07-25 14:56:21
|
Jo Janssens wrote: > This is an issue I have been thinking about as well - I am planning to > use a clordid that is 16 characters. Does anyone know of a destination > that would not support an id of at least this length?? Presently, we > route to NYSE, various nasdaq ecn's, and all 5 options exchanges. I can confirm that the Bank_Internal_Reference field of the Swiss Exchange (http://www.swx.com) and the virt-X (http://www.virt-x.com) is 16 chars long. This field is passed through from the order to the matching trades so that it may be taken as some sort of ClOrdID field. Just if anybody cares... Jo"rg -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
|
From: Jo J. <jo...@tr...> - 2003-07-25 14:41:07
|
I am also having a problem like this. It seems that somehow the FIX engine gets into an infinite loop of resend requests. Here is my event log. I am connecting to an outside vendor who probably does not use quickfix, and I am using the c++ version of quickfix 1.5.0 now, in case this is important. Jo 20030725-14:18:59 : Created session 20030725-14:18:59 : Connecting to x.x.x.x on port 21600 20030725-14:18:59 : Connection succeeded 20030725-14:19:00 : Initiated logon request 20030725-14:19:00 : Received logon response 20030725-14:19:00 : MsgSeqNum too high RECEIVED: 104 EXPECTED: 102 20030725-14:19:00 : Sent ResendRequest FROM: 102 TO: 103 20030725-14:19:00 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:00 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:00 : Received SequenceReset FROM: 102 TO: 104 20030725-14:19:00 : Processing QUEUED message: 104 20030725-14:19:12 : Received ResendRequest FROM: 16 TO: 79 20030725-14:19:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:20:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:20:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:21:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:21:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : MsgSeqNum too high RECEIVED: 113 EXPECTED: 105 20030725-14:22:10 : Sent ResendRequest FROM: 105 TO: 112 20030725-14:22:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:22:10 : Received SequenceReset FROM: 105 TO: 113 20030725-14:22:10 : Processing QUEUED message: 113 20030725-14:22:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : MsgSeqNum too high RECEIVED: 117 EXPECTED: 114 20030725-14:23:10 : Sent ResendRequest FROM: 114 TO: 116 20030725-14:23:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:23:10 : Received SequenceReset FROM: 114 TO: 117 20030725-14:23:10 : Processing QUEUED message: 117 20030725-14:23:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : MsgSeqNum too high RECEIVED: 121 EXPECTED: 118 20030725-14:24:10 : Sent ResendRequest FROM: 118 TO: 120 20030725-14:24:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:24:10 : Received SequenceReset FROM: 118 TO: 121 20030725-14:24:10 : Processing QUEUED message: 121 20030725-14:24:40 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:10 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:25:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : MsgSeqNum too high RECEIVED: 129 EXPECTED: 122 20030725-14:26:54 : Sent ResendRequest FROM: 122 TO: 128 20030725-14:26:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : Received ResendRequest FROM: 16 TO: 79 20030725-14:26:54 : Received SequenceReset FROM: 122 TO: 129 20030725-14:26:54 : Processing QUEUED message: 129 20030725-14:27:24 : Received ResendRequest FROM: 16 TO: 79 20030725-14:27:50 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:33 : MsgSeqNum too high RECEIVED: 135 EXPECTED: 130 20030725-14:28:33 : Sent ResendRequest FROM: 130 TO: 134 20030725-14:28:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:28:33 : Received SequenceReset FROM: 130 TO: 135 20030725-14:28:33 : Processing QUEUED message: 135 20030725-14:29:03 : MsgSeqNum too high RECEIVED: 137 EXPECTED: 136 20030725-14:29:03 : Sent ResendRequest FROM: 136 TO: 136 20030725-14:29:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:03 : Received SequenceReset FROM: 136 TO: 137 20030725-14:29:03 : Processing QUEUED message: 137 20030725-14:29:33 : MsgSeqNum too high RECEIVED: 139 EXPECTED: 138 20030725-14:29:33 : Sent ResendRequest FROM: 138 TO: 138 20030725-14:29:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:29:34 : Received SequenceReset FROM: 138 TO: 139 20030725-14:29:34 : Processing QUEUED message: 139 20030725-14:30:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:30:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:03 : MsgSeqNum too high RECEIVED: 144 EXPECTED: 140 20030725-14:31:03 : Sent ResendRequest FROM: 140 TO: 143 20030725-14:31:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:04 : Received ResendRequest FROM: 16 TO: 79 20030725-14:31:04 : Received SequenceReset FROM: 140 TO: 144 20030725-14:31:04 : Processing QUEUED message: 144 20030725-14:31:33 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:03 : MsgSeqNum too high RECEIVED: 148 EXPECTED: 145 20030725-14:32:03 : Sent ResendRequest FROM: 145 TO: 147 20030725-14:32:03 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:04 : Received ResendRequest FROM: 16 TO: 79 20030725-14:32:04 : Received SequenceReset FROM: 145 TO: 148 20030725-14:32:04 : Processing QUEUED message: 148 20030725-14:32:33 : Received ResendRequest FROM: 16 TO: 79 -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Andrew Munn Sent: Wednesday, July 23, 2003 18:09 To: qui...@li... Subject: RE: [Quickfix-developers] ResendRequest disapperaing? <--I'm having similar problems. I am having similar problems. Either I will get the repeated disconnects like those listed, or I will get a situation where I get a ResendRequest loop. Here are parts of the logs from initiator and acceptor: <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=57?35=0?34=2075?49=IN_MULTIFIX1?52=20030723-22:00:16?56=TW1 ?10=021?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2075 EXPECTED: 1967) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2480?49=TW1?52=20030723-22:00:16?56=IN_MULTIFIX1 ?7=1967?16=2074?10=210?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent test request TEST) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=72?35=2?34=2076?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?7=2479?16=2480?10=208?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Received ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=98?35=4?34=2479?43=Y?49=TW1?52=20030723-22:00:22?56=IN_MULT IFIX1?122=20030723-22:00:22?36=2481?123=Y?10=241?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent SequenceReset TO: 2481) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=66?35=0?34=2077?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2077 EXPECTED: 1968) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2482?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?7=1968?16=2076?10=212?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=57?35=0?34=2078?49=IN_MULTIFIX1?52=20030723-22:00:52?56=TW1 ?10=024?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2078 EXPECTED: 1968) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2483?49=TW1?52=20030723-22:00:52?56=IN_MULTIFIX1 ?7=1968?16=2077?10=217?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2077) =========================================================== <20030723-21:59:46, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=57?35=0?34=2075?49=IN_MULTIFIX1?52=20030723-22:00:16?56=TW1 ?10=021?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2480?49=TW1?52=20030723-22:00:16?56=IN_MULTIFIX1 ?7=1967?16=2074?10=210?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (MsgSeqNum too high RECEIVED: 2481 EXPECTED: 2479) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=72?35=2?34=2076?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?7=2479?16=2480?10=208?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Sent ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=98?35=4?34=2479?43=Y?49=TW1?52=20030723-22:00:22?56=IN_MULT IFIX1?122=20030723-22:00:22?36=2481?123=Y?10=241?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received SequenceReset FROM: 2479 TO: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Processing QUEUED message: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=66?35=0?34=2077?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2482?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?7=1968?16=2076?10=212?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=57?35=0?34=2078?49=IN_MULTIFIX1?52=20030723-22:00:52?56=TW1 ?10=024?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2483?49=TW1?52=20030723-22:00:52?56=IN_MULTIFIX1 ?7=1968?16=2077?10=217?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2077) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Disconnecting) Thanks, Andrew -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Howard Engelhart Sent: Wednesday, July 23, 2003 3:56 PM To: qui...@li... Subject: [Quickfix-developers] ResendRequest disapperaing? I have written a FIX server (an acceptor) and a FIX Client (initiator) both using QuickFIX. When my client attempts to connect to the server using a MsgSeqNum that is higher than expected, the server sends back the LogonRequest followed by a ResendRequest to the client (log excerpt below), however I never see this second (ResendRequest) message on my client. I do not see it in the message store, logs, nor can I catch it in the fromAdmin/fromApp handlers. Is there something I need to be doing here? Thanks, Howard 8=FIX.4.29=6035=A34=149=SBI052=20030723-20:50:0156=SLGM098=0108=3010=150 8=FIX.4.29=5835=234=249=SBI052=20030723-20:50:0156=SLGM07=116=7610=046 20030723-20:50:01 : Received logon request 20030723-20:50:01 : Responding to logon request 20030723-20:50:01 : MsgSeqNum too high RECEIVED: 77 EXPECTED: 1 20030723-20:50:01 : Sent ResendRequest FROM: 1 TO: 76 20030723-20:50:01 : Disconnecting ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Jo J. <jo...@tr...> - 2003-07-25 12:35:31
|
This is an issue I have been thinking about as well - I am planning to use a clordid that is 16 characters. Does anyone know of a destination that would not support an id of at least this length?? Presently, we route to NYSE, various nasdaq ecn's, and all 5 options exchanges. If someone has had an experience where 16 chars was too many, let me know. Thanks! Jo -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Oren Miller Sent: Thursday, July 24, 2003 10:32 To: Andrew Munn; qui...@li... Subject: Re: [Quickfix-developers] ClOrdID protocol?? There is no standard protocol for this. In fact, some exchanges won't even look at it, they often treat it as a pass thru value. Generally, you just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig enough, you can use a UUID. Otherwise time + counter could be sufficient. Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). > > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? > > > Thanks > Andrew Munn > and...@ho... > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: James D. <jc...@co...> - 2003-07-24 22:45:42
|
Aside from the length of the ClOrdID some exchanges (CBOE comes to mind) requires a specific format. Jim =20 James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of = Oren Miller Sent: Thursday, July 24, 2003 10:32 AM To: Andrew Munn; qui...@li... Subject: Re: [Quickfix-developers] ClOrdID protocol?? There is no standard protocol for this. In fact, some exchanges won't = even look at it, they often treat it as a pass thru value. Generally, you = just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX = field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig = enough, you can use a UUID. Otherwise time + counter could be sufficient.=20 Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). >=20 > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? >=20 >=20 > Thanks > Andrew Munn > and...@ho... >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Quickfix-developers mailing list=20 > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including = Data Reports, E-commerce, Portals, and Forums are available now. Download = today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Quickfix-developers mailing list = Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Alvin W. <xw...@qt...> - 2003-07-24 20:11:18
|
Hi, is there a way that I can be notified that the FIX connection is down (out of heart-beat, being disconnected, trying to reconnect)? Thanks! |
|
From: Oren M. <ore...@ya...> - 2003-07-24 17:05:14
|
Well the default behavior of QuickFIX is to reject messages that have timestamps older than 2 minutes (as per the spec) This can be turned off or configured to some other value. I would recommend that you fix this first before looking at resend issues because this may be complicated your problems. You can either tell your counterparty to turn this feature off or figure out why the timestamps are out of whack. It looks like your clocks are 4 minutes apart, so you may want to just synchronize your clocks. BTW, looks you were having some resend issues with your last post :) --- Patrick Reuter <pat...@ya...> wrote: > Dont know, havent looked at it. > QuickFix apparently is sending that to us(guess > not), > or maybe the client's app ?... > I agree though : strange reject messages. > > I am trying to figure out the resend issue first, > I'll > see about the app complaining later on (not too late > !) > > > --- Oren Miller <ore...@ya...> wrote: > > What's with all the SendingTime Accuracy problems? > > > > --- Patrick Reuter <pat...@ya...> > wrote: > > > We have some bad networking issues with a Client > > > using > > > QuickFix (1.5) > > > > > > Have a look at the log below (sorry for the > > size..) > > > we are in a bad loop. > > > Let me know if you can make sense of it. > > > > > > It happened many times the same day, always the > > same > > > problem of FIX engine asking resend to each > other, > > > even if it does get more complicated as the day > > went > > > by... below is just the beginning of the > problem. > > > The > > > thing I dont like though, is that our server > sends > > > the > > > resend request first (!) and the client > > answers/ask > > > a > > > resend with a sequence number that is not the > one > > we > > > requested in the resend request - so we're > stuck. > > > > > > > > > > > > > > > > > > FINE > > > Sending : > > > > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > > > Sending : > > > > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > > > Sending : > > > > > > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > > > Timeout|10=115| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > > > accuracy problem|372=1|373=10|10=238|^M > > > > > > Login OUT ok > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > > > Sending : > > > > > > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > > > to logout|10=108|^M > > > > > > Login IN OK > > > Receiving : > > > > > > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > > > Sending : > > > > > > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > > > > > Server Receives 344 (where is 343?) > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > > > Server Resend request for 343 > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > > > Client Resend request for 340 (that was the > logout > > > answer above) ?? + asks that with 345, not 343 > we > > > requested > > > -> we loop and hit a dead end... > > > Receiving : > > > > > > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > > > Sending : > > > > > > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > > > Sending : > > > > > > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > > > accuracy problem|372=2|373=10|10=238| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > > > accuracy problem|372=4|373=10|10=240| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > > > accuracy problem|372=1|373=10|10=233| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! SiteBuilder - Free, easy-to-use web site > > > design software > > > http://sitebuilder.yahoo.com > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by: Free pre-built > > > ASP.NET sites including > > > Data Reports, E-commerce, Portals, and Forums > are > > > available now. > > > Download today and enter to win an XBOX or > Visual > > > Studio .NET. > > > > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > _______________________________________________ > > > Quickfix-developers mailing list > > > Qui...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 16:45:03
|
Dont know, havent looked at it. QuickFix apparently is sending that to us(guess not), or maybe the client's app ?... I agree though : strange reject messages. I am trying to figure out the resend issue first, I'll see about the app complaining later on (not too late !) --- Oren Miller <ore...@ya...> wrote: > What's with all the SendingTime Accuracy problems? > > --- Patrick Reuter <pat...@ya...> wrote: > > We have some bad networking issues with a Client > > using > > QuickFix (1.5) > > > > Have a look at the log below (sorry for the > size..) > > we are in a bad loop. > > Let me know if you can make sense of it. > > > > It happened many times the same day, always the > same > > problem of FIX engine asking resend to each other, > > even if it does get more complicated as the day > went > > by... below is just the beginning of the problem. > > The > > thing I dont like though, is that our server sends > > the > > resend request first (!) and the client > answers/ask > > a > > resend with a sequence number that is not the one > we > > requested in the resend request - so we're stuck. > > > > > > > > > > > > FINE > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > > Receiving : > > > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > > Sending : > > > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > > Timeout|10=115| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > > accuracy problem|372=1|373=10|10=238|^M > > > > Login OUT ok > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > > Sending : > > > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > > to logout|10=108|^M > > > > Login IN OK > > Receiving : > > > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > > Sending : > > > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > > > Server Receives 344 (where is 343?) > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > > Server Resend request for 343 > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > > Client Resend request for 340 (that was the logout > > answer above) ?? + asks that with 345, not 343 we > > requested > > -> we loop and hit a dead end... > > Receiving : > > > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > > Sending : > > > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > > Sending : > > > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > > accuracy problem|372=2|373=10|10=238| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > > accuracy problem|372=4|373=10|10=240| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > > accuracy problem|372=1|373=10|10=233| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > > design software > > http://sitebuilder.yahoo.com > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 16:44:44
|
Dont know, havent looked at it. QuickFix apparently is sending that to us(guess not), or maybe the client's app ?... I agree though : strange reject messages. I am trying to figure out the resend issue first, I'll see about the app complaining later on (not too late !) --- Oren Miller <ore...@ya...> wrote: > What's with all the SendingTime Accuracy problems? > > --- Patrick Reuter <pat...@ya...> wrote: > > We have some bad networking issues with a Client > > using > > QuickFix (1.5) > > > > Have a look at the log below (sorry for the > size..) > > we are in a bad loop. > > Let me know if you can make sense of it. > > > > It happened many times the same day, always the > same > > problem of FIX engine asking resend to each other, > > even if it does get more complicated as the day > went > > by... below is just the beginning of the problem. > > The > > thing I dont like though, is that our server sends > > the > > resend request first (!) and the client > answers/ask > > a > > resend with a sequence number that is not the one > we > > requested in the resend request - so we're stuck. > > > > > > > > > > > > FINE > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > > Receiving : > > > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > > Sending : > > > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > > Timeout|10=115| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > > accuracy problem|372=1|373=10|10=238|^M > > > > Login OUT ok > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > > Sending : > > > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > > to logout|10=108|^M > > > > Login IN OK > > Receiving : > > > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > > Sending : > > > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > > > Server Receives 344 (where is 343?) > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > > Server Resend request for 343 > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > > Client Resend request for 340 (that was the logout > > answer above) ?? + asks that with 345, not 343 we > > requested > > -> we loop and hit a dead end... > > Receiving : > > > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > > Sending : > > > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > > Sending : > > > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > > accuracy problem|372=2|373=10|10=238| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > > accuracy problem|372=4|373=10|10=240| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > > accuracy problem|372=1|373=10|10=233| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > > design software > > http://sitebuilder.yahoo.com > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Oren M. <ore...@ya...> - 2003-07-24 16:36:47
|
What's with all the SendingTime Accuracy problems? --- Patrick Reuter <pat...@ya...> wrote: > We have some bad networking issues with a Client > using > QuickFix (1.5) > > Have a look at the log below (sorry for the size..) > we are in a bad loop. > Let me know if you can make sense of it. > > It happened many times the same day, always the same > problem of FIX engine asking resend to each other, > even if it does get more complicated as the day went > by... below is just the beginning of the problem. > The > thing I dont like though, is that our server sends > the > resend request first (!) and the client answers/ask > a > resend with a sequence number that is not the one we > requested in the resend request - so we're stuck. > > > > > > FINE > Sending : > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > Receiving : > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > Sending : > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > Sending : > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > Timeout|10=115| > Receiving : > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > accuracy problem|372=1|373=10|10=238|^M > > Login OUT ok > Receiving : > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > Sending : > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > to logout|10=108|^M > > Login IN OK > Receiving : > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > Sending : > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > Server Receives 344 (where is 343?) > Receiving : > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > Server Resend request for 343 > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > Client Resend request for 340 (that was the logout > answer above) ?? + asks that with 345, not 343 we > requested > -> we loop and hit a dead end... > Receiving : > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > Sending : > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > Sending : > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > Receiving : > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > accuracy problem|372=2|373=10|10=238| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > Receiving : > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > Receiving : > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > accuracy problem|372=4|373=10|10=240| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > Receiving : > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > Receiving : > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > accuracy problem|372=1|373=10|10=233| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 16:05:10
|
We have some bad networking issues with a Client using QuickFix (1.5) Have a look at the log below (sorry for the size..) we are in a bad loop. Let me know if you can make sense of it. It happened many times the same day, always the same problem of FIX engine asking resend to each other, even if it does get more complicated as the day went by... below is just the beginning of the problem. The thing I dont like though, is that our server sends the resend request first (!) and the client answers/ask a resend with a sequence number that is not the one we requested in the resend request - so we're stuck. FINE Sending : 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| Receiving : 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| Sending : 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| Sending : 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt Timeout|10=115| Receiving : 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime accuracy problem|372=1|373=10|10=238|^M Login OUT ok Receiving : 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M Sending : 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying to logout|10=108|^M Login IN OK Receiving : 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| Sending : 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| Server Receives 344 (where is 343?) Receiving : 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| Server Resend request for 343 Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| Client Resend request for 340 (that was the logout answer above) ?? + asks that with 345, not 343 we requested -> we loop and hit a dead end... Receiving : 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| Sending : 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| Sending : 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| Receiving : 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime accuracy problem|372=2|373=10|10=238| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| Receiving : 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| Receiving : 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime accuracy problem|372=4|373=10|10=240| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| Receiving : 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| Receiving : 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime accuracy problem|372=1|373=10|10=233| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 15:57:11
|
One thing though - try no to link reset of sequence number with reset of clordid if you use such thing. Furthermore, most people reset their session every 24 hours. If you trade in different regions, you always have orders in one place, so doing a reset of clordid every day is not great either (actually, it just will not work). the best is to try to never use the same orderid or eventually recycle every month I guess (watch out for GTC/GTD orders though) Concerning length, in my case, we're limited to 12 chars by the servers that are connected to the exchange, on top of that, these same servers hate when the format of this clientordid changes. --- Oren Miller <ore...@ya...> wrote: > There is no standard protocol for this. In fact, > some > exchanges won't even look at it, they often treat it > as a pass thru value. Generally, you just need to > insure somehow that it is unique for the extent of > the > session. Whatever way you choose to do that is > entirely up to you. > > One thing you should verify is the maximum length > your > counterparty supports. Although there is no > restriction on the length of a FIX field, the > counterparty usually stores this value in a database > which forces a length restriction on their end. If > their length restriction is hig enough, you can use > a > UUID. Otherwise time + counter could be sufficient. > > Or simply persisting somewhere the last id that you > used. > > --- Andrew Munn <an...@nm...> wrote: > > If a client program uses a simple counter to > > generate Order IDs and the > > client exits and then restarts, the ClOrdID is > reset > > to 1. Orders sent > > after that get a "duplicate ClOrdID" reject until > > more orders are sent > > than were sent by the previous session (when new > > ClOrdIDs start being > > generated). > > > > What is the standard procedure, if any, to ensure > > uniqueness of ClOrdIDs > > between disconnects, crashes, etc? Should an OMS > > query the message > > store on startup for the highest ClOrdID used that > > day and begin > > incrementing it? Should it assure uniqueness by > > appending a session > > counter to the end of the ID? Should it simply > tack > > on time&date? > > > > > > Thanks > > Andrew Munn > > and...@ho... > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Oren M. <ore...@ya...> - 2003-07-24 15:32:21
|
There is no standard protocol for this. In fact, some exchanges won't even look at it, they often treat it as a pass thru value. Generally, you just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig enough, you can use a UUID. Otherwise time + counter could be sufficient. Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). > > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? > > > Thanks > Andrew Munn > and...@ho... > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Andrew M. <an...@nm...> - 2003-07-23 23:10:36
|
I am having similar problems. Either I will get the repeated disconnects like those listed, or I will get a situation where I get a ResendRequest loop. Here are parts of the logs from initiator and acceptor: <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=57?35=0?34=2075?49=IN_MULTIFIX1?52=20030723-22:00:16?56=TW1 ?10=021?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2075 EXPECTED: 1967) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2480?49=TW1?52=20030723-22:00:16?56=IN_MULTIFIX1 ?7=1967?16=2074?10=210?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:16, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent test request TEST) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=72?35=2?34=2076?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?7=2479?16=2480?10=208?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Received ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=98?35=4?34=2479?43=Y?49=TW1?52=20030723-22:00:22?56=IN_MULT IFIX1?122=20030723-22:00:22?36=2481?123=Y?10=241?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent SequenceReset TO: 2481) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=66?35=0?34=2077?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2077 EXPECTED: 1968) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2482?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?7=1968?16=2076?10=212?) <20030723-22:00:22, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, incoming> (8=FIX.4.1?9=57?35=0?34=2078?49=IN_MULTIFIX1?52=20030723-22:00:52?56=TW1 ?10=024?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (MsgSeqNum too high RECEIVED: 2078 EXPECTED: 1968) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, outgoing> (8=FIX.4.1?9=72?35=2?34=2483?49=TW1?52=20030723-22:00:52?56=IN_MULTIFIX1 ?7=1968?16=2077?10=217?) <20030723-22:00:52, FIX.4.1:TW1->IN_MULTIFIX1, event> (Sent ResendRequest FROM: 1968 TO: 2077) =========================================================== <20030723-21:59:46, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=57?35=0?34=2075?49=IN_MULTIFIX1?52=20030723-22:00:16?56=TW1 ?10=021?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2480?49=TW1?52=20030723-22:00:16?56=IN_MULTIFIX1 ?7=1967?16=2074?10=210?) <20030723-22:00:16, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1967 TO: 2074) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (MsgSeqNum too high RECEIVED: 2481 EXPECTED: 2479) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=72?35=2?34=2076?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?7=2479?16=2480?10=208?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Sent ResendRequest FROM: 2479 TO: 2480) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=98?35=4?34=2479?43=Y?49=TW1?52=20030723-22:00:22?56=IN_MULT IFIX1?122=20030723-22:00:22?36=2481?123=Y?10=241?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received SequenceReset FROM: 2479 TO: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Processing QUEUED message: 2481) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=66?35=1?34=2481?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=66?35=0?34=2077?49=IN_MULTIFIX1?52=20030723-22:00:22?56=TW1 ?112=TEST?10=038?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2482?49=TW1?52=20030723-22:00:22?56=IN_MULTIFIX1 ?7=1968?16=2076?10=212?) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2076) <20030723-22:00:22, FIX.4.1:IN_MULTIFIX1->TW1, outgoing> (8=FIX.4.1?9=57?35=0?34=2078?49=IN_MULTIFIX1?52=20030723-22:00:52?56=TW1 ?10=024?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, incoming> (8=FIX.4.1?9=72?35=2?34=2483?49=TW1?52=20030723-22:00:52?56=IN_MULTIFIX1 ?7=1968?16=2077?10=217?) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Received ResendRequest FROM: 1968 TO: 2077) <20030723-22:00:52, FIX.4.1:IN_MULTIFIX1->TW1, event> (Disconnecting) Thanks, Andrew -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Howard Engelhart Sent: Wednesday, July 23, 2003 3:56 PM To: qui...@li... Subject: [Quickfix-developers] ResendRequest disapperaing? I have written a FIX server (an acceptor) and a FIX Client (initiator) both using QuickFIX. When my client attempts to connect to the server using a MsgSeqNum that is higher than expected, the server sends back the LogonRequest followed by a ResendRequest to the client (log excerpt below), however I never see this second (ResendRequest) message on my client. I do not see it in the message store, logs, nor can I catch it in the fromAdmin/fromApp handlers. Is there something I need to be doing here? Thanks, Howard 8=FIX.4.29=6035=A34=149=SBI052=20030723-20:50:0156=SLGM098=0108=3010=150 8=FIX.4.29=5835=234=249=SBI052=20030723-20:50:0156=SLGM07=116=7610=046 20030723-20:50:01 : Received logon request 20030723-20:50:01 : Responding to logon request 20030723-20:50:01 : MsgSeqNum too high RECEIVED: 77 EXPECTED: 1 20030723-20:50:01 : Sent ResendRequest FROM: 1 TO: 76 20030723-20:50:01 : Disconnecting ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Andrew M. <an...@nm...> - 2003-07-23 22:57:16
|
If a client program uses a simple counter to generate Order IDs and the client exits and then restarts, the ClOrdID is reset to 1. Orders sent after that get a "duplicate ClOrdID" reject until more orders are sent than were sent by the previous session (when new ClOrdIDs start being generated). What is the standard procedure, if any, to ensure uniqueness of ClOrdIDs between disconnects, crashes, etc? Should an OMS query the message store on startup for the highest ClOrdID used that day and begin incrementing it? Should it assure uniqueness by appending a session counter to the end of the ID? Should it simply tack on time&date? Thanks Andrew Munn and...@ho... |
|
From: Howard E. <ho...@ex...> - 2003-07-23 20:56:41
|
I have written a FIX server (an acceptor) and a FIX Client (initiator) both using QuickFIX. When my client attempts to connect to the server using a MsgSeqNum that is higher than expected, the server sends back the LogonRequest followed by a ResendRequest to the client (log excerpt below), however I never see this second (ResendRequest) message on my client. I do not see it in the message store, logs, nor can I catch it in the fromAdmin/fromApp handlers. Is there something I need to be doing here? Thanks, Howard 8=FIX.4.29=6035=A34=149=SBI052=20030723-20:50:0156=SLGM098=0108=3010=150 8=FIX.4.29=5835=234=249=SBI052=20030723-20:50:0156=SLGM07=116=7610=046 20030723-20:50:01 : Received logon request 20030723-20:50:01 : Responding to logon request 20030723-20:50:01 : MsgSeqNum too high RECEIVED: 77 EXPECTED: 1 20030723-20:50:01 : Sent ResendRequest FROM: 1 TO: 76 20030723-20:50:01 : Disconnecting |
|
From: Oren M. <ore...@ya...> - 2003-07-22 01:27:20
|
The problem is the compiler. 2.96 is a buggy unnoficial release: http://gcc.gnu.org/gcc-2.96.html One of the problems is if exception is thrown inside a shared object, event if it is caught, applications will crash. This is why this is a problem with the JNI shared object. You should either move to gcc 2.95.3, or upgrade to 3.2 James Walker <wa...@jl...> wrote: I'm trying to run tradeclient against the java version of executor and executor crashes everytime I connect to it. The C++ version of executor works fine. I'm using gcc version 2.96 under RedHat Linux. I'm running java 1.3.1 08. The only information that I get from the jvm is that I executed code at pc 0x0. I've tried quickfix 1.4, 1.5, and the latest CVS version. I'm wondering what success people have had with JNI on Linux. Any advice would be welcome. -- Les Walker ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software |
|
From: Oren M. <ore...@ya...> - 2003-07-22 01:23:34
|
It doesn't matter whether the first field is marked as required, there is a set of rules for repeating groups that is always true. They are listed here in the repeating groups section: http://www.fixprotocol.org/specification/fix-42-with_errata_20010501.html#_Toc513372716 The first bulletin point listed is as follows: "If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a "delimiter" indicating a new repeating group entry." So even if you mark the first field as not required, it will be overriden. Maybe a warning should be displayed if you try to do this. Alok Lal <al...@ra...> wrote: All, I think I discovered a bug in parsing groups. In Message::setGroup, there's a call to DataDictionary::getGroup in which the delimiter is set to the first field that is within the group. However, this assumes the first field in the group will always be present, which is false: In the above, the delimiter is set to whatever tag # is associated with "Foo1" but since it clearly isn't required, there's no guarantee it'll appear within a message. If it doesn't appear, then "Foo2" won't be parsed as part of the group and that causes the body length to be incorrect resulting in an invalid FIX. Please let me know if you agree/disagree or are unclear about what I've just mentioned. Thanks. Alok ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software |
|
From: James W. <wa...@jl...> - 2003-07-22 00:19:15
|
I'm trying to run tradeclient against the java version of executor and executor crashes everytime I connect to it. The C++ version of executor works fine. I'm using gcc version 2.96 under RedHat Linux. I'm running java 1.3.1 08. The only information that I get from the jvm is that I executed code at pc 0x0. I've tried quickfix 1.4, 1.5, and the latest CVS version. I'm wondering what success people have had with JNI on Linux. Any advice would be welcome. -- Les Walker |
|
From: Alok L. <al...@ra...> - 2003-07-21 22:44:04
|
All, I think I discovered a bug in parsing groups. In Message::setGroup, there's a call to DataDictionary::getGroup in which the delimiter is set to the first field that is within the group. However, this assumes the first field in the group will always be present, which is false: <group name="NoMyGroup" required="N" > <field name="Foo1" required="N" /> <field name="Foo2" required="N" /> </group> In the above, the delimiter is set to whatever tag # is associated with "Foo1" but since it clearly isn't required, there's no guarantee it'll appear within a message. If it doesn't appear, then "Foo2" won't be parsed as part of the group and that causes the body length to be incorrect resulting in an invalid FIX. Please let me know if you agree/disagree or are unclear about what I've just mentioned. Thanks. Alok |
|
From: Jo J. <jo...@tr...> - 2003-07-21 19:49:06
|
Hi All, I am trying to use QuickFix in a managed C++ application (not QuickFix.NET). When the app starts up, I get an ConfigError with the message "Could not initialize COM" I investigated and the error is RPC_E_CHANGED_MODE. This occurs in the initialization of the MSXML object. Does anyone know why this would be? Do I need to change some setting so the threading model will be compatible? Thanks, Jo Janssens |
|
From: Alok L. <al...@ra...> - 2003-07-18 20:09:13
|
All, I recently upgraded my QuickFix to 1.5.0 in order to get support for nested groups and components. When I receive security list messages, it seems that SecurityRequestResult is not getting parsed properly or is not being read. Has anybody had any problems like this before? Thanks. Alok |
98 messages has been excluded from this view by a project administrator.
