quickfix-developers Mailing List for QuickFIX (Page 152)
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
|
| 2026 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Miguel P. <mpe...@ho...> - 2006-05-05 17:17:37
|
<html><div style='background-color:'><P>hello, I install quickfix, and I have tree cuestions: <P>I cannot write in MYSQL database what I do wrong? <BR>I compile the examples and the database but when I try to configure to record in MYSQL nothing happens <P>Fix can support DB2 or I need to do something more? <BR>Whit quickfix can use ODBC to use a external Database? <BR>Have support for the AS/400, ISERIES OR I5. </P><BR><BR> <DIV> <DIV style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-BOTTOM: 10px; PADDING-TOP: 10px">And I thought that my president was stupid</DIV></DIV></div><br clear=all><hr>Éxitos, grandes clásicos y novedades. <a href="http://g.msn.com/8HMAESES/2755??PS=47575" target="_top">Un millón de canciones en MSN Music. </a> </html> |
|
From: Steve B. <sb...@sm...> - 2006-05-04 20:19:32
|
Hi Victor, =20 The class is in the backport-util-concurrent JAR file. Are you sure there's no mistake in your classpath setup? =20 Steve ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Victor Sent: Thursday, May 04, 2006 8:42 PM To: qui...@li... Subject: [Quickfix-developers] Quick Fix newbie question. =09 =09 I downloaded =20 Binary: quickfix-1.0.0-beta3-bin.zip <http://prdownloads.sourceforge.net/quickfix/quickfix-1.0.0-beta3-bin.zi p>=20 =09 from http://www.quickfixengine.org/download.html =09 =09 =09 I set my classpath as=20 =09 C:\QuickFix\quickfixj\quickfixj.jar; C:\QuickFix\quickfixj\lib\backport-util-concurrent-2.0.jar; C:\QuickFix\quickfixj\lib\mina-0.8.2.jar; C:\QuickFix\quickfixj\lib\slf4j-jdk14-1.0-rc5.jar =09 =09 I tried to run the executor .bat under C:\QuickFix\quickfixj\bin =09 executor. bat has nothing great it runs this class java quickfix.examples.executor.Executor =09 I get this exception =09 Exception in thread "main" java.lang.NoClassDefFoundError: edu/emory/mathcs/backport/java/util/concurrent/ThreadFactory at quickfix.examples.executor.Executor.main(Executor.java:51) =09 =09 Can anybody help me on this?. I know its not able to find some threadfactory class but where is it?. fundamentally I running "quickfix.examples.executor.Executor" whicj is in quickfixj.jar . =09 Thanks =09 =09 =09 =09 =09 =09 ________________________________ New Yahoo! Messenger with Voice. Call regular phones from your PC <http://us.rd.yahoo.com/mail_us/taglines/postman5/*http://us.rd.yahoo.co m/evt=3D39666/*http://messenger.yahoo.com> and save big. |
|
From: Victor <vis...@ya...> - 2006-05-04 18:42:14
|
I downloaded Binary: quickfix-1.0.0-beta3-bin.zip from http://www.quickfixengine.org/download.html I set my classpath as C:\QuickFix\quickfixj\quickfixj.jar; C:\QuickFix\quickfixj\lib\backport-util-concurrent-2.0.jar; C:\QuickFix\quickfixj\lib\mina-0.8.2.jar; C:\QuickFix\quickfixj\lib\slf4j-jdk14-1.0-rc5.jar I tried to run the executor .bat under C:\QuickFix\quickfixj\bin executor. bat has nothing great it runs this class java quickfix.examples.executor.Executor I get this exception Exception in thread "main" java.lang.NoClassDefFoundError: edu/emory/mathcs/backport/java/util/concurrent/ThreadFactory at quickfix.examples.executor.Executor.main(Executor.java:51) Can anybody help me on this?. I know its not able to find some threadfactory class but where is it?. fundamentally I running "quickfix.examples.executor.Executor" whicj is in quickfixj.jar . Thanks --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. |
|
From: SteveGoodsell <ste...@ff...> - 2006-05-04 08:58:15
|
Hi Caleb, We are generating TradeCaptureReports and sending them to the FIX clients. The clients are required to then respond with a TradeCaptureReportAck. This works fine till we encounter the resent request event, then once the messages have been resentr (by the quick fix api) the TradeCaptureReports are no longer being received (or reported as received in toApp on the client side). Forcing a log off and log on again sorts this out. I have to stress that this happens when the app is under heavy load (1 msg per 0.5secs) and that was why I was wondering if I have to hold off on the sending of our app generated messages until the resendrequest is finished. It could be, as you sort of suggested, down to my coding too :) Steve -- View this message in context: http://www.nabble.com/ResendRequest-help%21-t1512694.html#a4225335 Sent from the QuickFIX - Dev forum at Nabble.com. |
|
From: Steve B. <sb...@sm...> - 2006-05-03 17:25:45
|
Hi Tom,
=20
Thanks. This was already fixed in the developer repository. Like I said
in a recent message, the anonymous repository is several weeks (at
least) out of date due to SourceForge CVS problems. I'm sorry about that
but there isn't anything I can do to address the problem and I'm not
sure how long it will take SourceForge to fix it. If you are a developer
on any SourceForge project you can check out a read only version of the
QFJ developer repository. That repository will have the up-to-date code.
=20
Regards,
=20
Steve
________________________________
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Tom Dilatush
Sent: Wednesday, May 03, 2006 7:03 PM
To: qui...@li...
Subject: [Quickfix-developers] Empty Tag 58 in Logout request...
=09
=09
This is with QuickFIX/J, checked out of the anonymous repository
on 5/1/2006.
=09
The problem occurred when manually initiating logout by calling
(Session).logout(), instead of (Session).logout(String). The result was
that an empty tag 58 was inserted in the logout message, reflecting the
empty String in the state object.
=09
So...
=09
I took this code (from Session.generateLogout(String):
=09
if (text !=3D null) {
logout.setString(Text.FIELD, text);
}
=09
and modified it to this:
=09
if( (text !=3D null) && (text.length() > 0) ) {
logout.setString(Text.FIELD, text);
}
=09
Voila! The problem is no more...
=09
Tom...
=09
|
|
From: Tom D. <to...@di...> - 2006-05-03 17:03:08
|
This is with QuickFIX/J, checked out of the anonymous repository on
5/1/2006.
The problem occurred when manually initiating logout by calling
(Session).logout(), instead of (Session).logout(String). The result was
that an empty tag 58 was inserted in the logout message, reflecting the
empty String in the state object.
So...
I took this code (from Session.generateLogout(String):
* if (text != null) {
logout.setString(Text.FIELD, text);
}
*
and modified it to this:
* if( (text != null) && (text.length() > 0) ) {
logout.setString(Text.FIELD, text);
}
*
Voila! The problem is no more...
Tom...
|
|
From: Caleb E. <cal...@gm...> - 2006-05-03 16:51:23
|
On 4/26/06, SteveGoodsell <ste...@ff...> wrote: > But.. Sometimes the client is in the middle of receiving a large number o= f > messages when this event occurs. At this point, the client stops respondi= ng > (ACK) to the messages being sent both from the QuickFix engine and from m= y > side of the application. What sort of ACK are you talking about? FIX doesn't have any sort of protocol-level ACKing. Is this client yours? Can you see what is happening in that application? If not, there isn't much you can do. Is this causing any problems with your Acceptor, or just the quiet "death" of the client app? > Should I be halting all my application based messages until the resend > request completes? How can I tell when this complete? That really shouldn't be necessary, given well behaved applications. -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: SteveGoodsell <ste...@ff...> - 2006-05-03 16:30:41
|
BUMP.. I could do with some advice on the please... Anybody? Regards, Steve -- View this message in context: http://www.nabble.com/ResendRequest-help%21-t1512694.html#a4213724 Sent from the QuickFIX - Dev forum at Nabble.com. |
|
From: Steve B. <sb...@sm...> - 2006-05-03 16:15:58
|
Wenchao, =20 There is some documentation on the data dictionary, validation, and related topics at... =20 http://www.quickfixengine.org/quickfixj/doc/usermanual/usage/validation. html =20 Yes, the custom field is indirectly causing the problem. You can add the field to the data dictionary by adding a field element with the fields section of the dictionary and then add a reference to the custom field in the group definition for the snapshot message. =20 Note that you don't necessarily have to regenerate the classes after adding the custom field. Just modifying the data dictionary XML will support the validation and parsing of the=20 message. =20 Steve ________________________________ From: Wenchao Tao [mailto:wy...@me...]=20 Sent: Wednesday, May 03, 2006 6:05 PM To: Steve Bate Subject: RE: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem =09 =09 Hi Steve, =20 Thanks for the quick response. For the custom tags, I basically disabled the validation by setting ValidateUserDefinedFields to N in the property file for now. I haven't attempted to modify the default data dictionary files yet. By looking at the trace, the incoming message does seem to put the SecurityType field in the NoMDEntries group, which should be ok, right? Any suggestions as to how to go about resolve this problem in my situation? =20 I'd also like to know the steps in modifying the default data dictionary. I tried to rename the NoMDEntries to NoMDEntriesX (was a simple test), but the quickfixj package failed to compile. So it seems dictionary is also being reference somewhere else. Can you let me know where I can find some info on how to modify the dictionary?=20 =20 I really appreciate your help on this. =20 --Wenchao- =20 =20 =09 ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: Wednesday, May 03, 2006 7:51 AM To: qui...@li... Subject: RE: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem =20 Wenchao, =20 The group information is looked up using the message type and the group count field number. If the group is defined differently for different messages is will be validated differently. Is there any possibility that the security type is defined outside the group? For example, it appears there is a custom tag in the group, 10455=3D6JM6. = I'm guessing you may have added this field to the data dictionary or it would have failed validation. However, if you didn't add the custom field reference inside the NoMDEntries group definition it will trigger the termination of the group parsing. The next field is the security type which is not valid /outside/ the group. =20 Steve =20 =09 ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Wenchao Tao Sent: Wednesday, May 03, 2006 9:10 AM To: qui...@li... Subject: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem Hi,=20 =20 I started coding fix using quickfixj just a few days ago. I am implementing a client that gets realtime data feed from the fix server at our broker. In my program, I send MarketDataRequest, and expect MarketDataSnapshotFullRefresh and MarketDataIncrementalRefresh back. I have no problem with the MarketDataSnapshotFullRefresh, but quickfixj always rejects the MarketDataIncrementalRefresh complaining that tag 167 (SecurityType) is not defined for this message type. I checked the FIX42.xml, and verified that tag 167 is defined for MarketDataIncrementalRefresh under group NoMDEntries. I took a look at the DataDictionary.java, and it seems the validation step searches group definition by name. And the group name is not unique in FIX42.xml. For example, group NoMDEntries appears in MarketDataSnapshortFullRefresh as well as in MarketDataIncrementalRefresh, and the set of tags are different for the two groups. Can this be the cause to the problem? I am attaching the quickfixj trace for reference. Any advice would be greatly appreciated. =20 --Wenchao- =20 =20 =20 [java] <20060503-06:16:06, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D172 35=3DV 34=3D3 49=3DPRICE = 52=3D20060503-06:16:06.776 56=3Dfc 262=3D2001 263=3D1 264=3D1 265=3D1 266=3DY 146=3D1 55=3D6J = 48=3DCME000040287 167=3DFUT 200=3D200606 207=3DCME 267=3D4 269=3D5 269=3D4 269=3D7 269=3D8 = 10=3D110 ) [java] <20060503-06:16:06, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00200 35=3DW 49=3Dfc 56=3DPRICE 34=3D132 52=3D20060503-06:16:06.884 55=3D6J 48=3DCME000040287 10455=3D6JM6 = 167=3DFUT 207=3DCME 262=3D2001 387=3D2087 200=3D200606 268=3D4 269=3D4 270=3D8873 = 269=3D5 270=3D8892 269=3D7 270=3D8893 269=3D8 270=3D8870 10=3D128 ) [java] <20060503-06:16:36, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00056 35=3D0 49=3Dfc 56=3DPRICE 34=3D133 52=3D20060503-06:16:36.884 10=3D207 ) [java] <20060503-06:16:36, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D54 35=3D0 34=3D4 49=3DPRICE = 52=3D20060503-06:16:36.964 56=3Dfc 10=3D217 ) ... [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00161 35=3DX 49=3Dfc 56=3DPRICE 34=3D149 52=3D20060503-06:24:22.472 262=3D2001 268=3D1 279=3D1 55=3D6J = 48=3DCME000040287 10455=3D6JM6 167=3DFUT 207=3DCME 269=3D7 270=3D8894 387=3D2115 = 200=3D200606 10=3D061 ) [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, event> (Message 149 Rejected: Tag not defined for this message type:167) [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D123 35=3D3 34=3D20 49=3DPRICE = 52=3D20060503-06:24:22.556 56=3Dfc 45=3D149 58=3DTag not defined for this message type 371=3D167 = 372=3DX 373=3D2 10=3D118 ) =20 =20 =09 =09 ---------------------------------------------------------- IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the recipient, please immediately notify us by return email, and delete this message from your computer. =09 ----------------------------------------------------------=20 ---------------------------------------------------------- IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the recipient, please immediately notify us by return email, and delete this message from your computer. ----------------------------------------------------------=20 |
|
From: Steve B. <sb...@sm...> - 2006-05-03 14:53:31
|
Wenchao, =20 The group information is looked up using the message type and the group count field number. If the group is defined differently for different messages is will be validated differently. Is there any possibility that the security type is defined outside the group? For example, it appears there is a custom tag in the group, 10455=3D6JM6. I'm guessing you may have added this field to the data dictionary or it would have failed validation. However, if you didn't add the custom field reference inside the NoMDEntries group definition it will trigger the termination of the group parsing. The next field is the security type which is not valid /outside/ the group. =20 Steve ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Wenchao Tao Sent: Wednesday, May 03, 2006 9:10 AM To: qui...@li... Subject: [Quickfix-developers] quickfixj: Incremental Refresh (x) problem =09 =09 Hi,=20 =20 I started coding fix using quickfixj just a few days ago. I am implementing a client that gets realtime data feed from the fix server at our broker. In my program, I send MarketDataRequest, and expect MarketDataSnapshotFullRefresh and MarketDataIncrementalRefresh back. I have no problem with the MarketDataSnapshotFullRefresh, but quickfixj always rejects the MarketDataIncrementalRefresh complaining that tag 167 (SecurityType) is not defined for this message type. I checked the FIX42.xml, and verified that tag 167 is defined for MarketDataIncrementalRefresh under group NoMDEntries. I took a look at the DataDictionary.java, and it seems the validation step searches group definition by name. And the group name is not unique in FIX42.xml. For example, group NoMDEntries appears in MarketDataSnapshortFullRefresh as well as in MarketDataIncrementalRefresh, and the set of tags are different for the two groups. Can this be the cause to the problem? I am attaching the quickfixj trace for reference. Any advice would be greatly appreciated. =20 --Wenchao- =20 =20 =20 [java] <20060503-06:16:06, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D172 35=3DV 34=3D3 49=3DPRICE 52=3D20060503-06:16:06.776 = 56=3Dfc 262=3D2001 263=3D1 264=3D1 265=3D1 266=3DY 146=3D1 55=3D6J = 48=3DCME000040287 167=3DFUT 200=3D200606 207=3DCME 267=3D4 269=3D5 269=3D4 269=3D7 269=3D8 10=3D110 = ) [java] <20060503-06:16:06, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00200 35=3DW 49=3Dfc 56=3DPRICE 34=3D132 = 52=3D20060503-06:16:06.884 55=3D6J 48=3DCME000040287 10455=3D6JM6 167=3DFUT 207=3DCME 262=3D2001 = 387=3D2087 200=3D200606 268=3D4 269=3D4 270=3D8873 269=3D5 270=3D8892 269=3D7 = 270=3D8893 269=3D8 270=3D8870 10=3D128 ) [java] <20060503-06:16:36, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00056 35=3D0 49=3Dfc 56=3DPRICE 34=3D133 = 52=3D20060503-06:16:36.884 10=3D207 ) [java] <20060503-06:16:36, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D54 35=3D0 34=3D4 49=3DPRICE 52=3D20060503-06:16:36.964 = 56=3Dfc 10=3D217 ) ... [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, incoming> (8=3DFIX.4.2 9=3D00161 35=3DX 49=3Dfc 56=3DPRICE 34=3D149 = 52=3D20060503-06:24:22.472 262=3D2001 268=3D1 279=3D1 55=3D6J 48=3DCME000040287 10455=3D6JM6 = 167=3DFUT 207=3DCME 269=3D7 270=3D8894 387=3D2115 200=3D200606 10=3D061 ) [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, event> (Message 149 Rejected: Tag not defined for this message type:167) [java] <20060503-06:24:22, FIX.4.2:PRICE->fc, outgoing> (8=3DFIX.4.2 9=3D123 35=3D3 34=3D20 49=3DPRICE = 52=3D20060503-06:24:22.556 56=3Dfc 45=3D149 58=3DTag not defined for this message type 371=3D167 372=3DX = 373=3D2 10=3D118 ) =20 =20 ---------------------------------------------------------- IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the recipient, please immediately notify us by return email, and delete this message from your computer. ----------------------------------------------------------=20 |
|
From: Wenchao T. <wy...@me...> - 2006-05-03 07:10:43
|
Hi,
I started coding fix using quickfixj just a few days ago. I am
implementing a client that gets realtime data feed from the fix server at
our broker. In my program, I send MarketDataRequest, and expect
MarketDataSnapshotFullRefresh and MarketDataIncrementalRefresh back. I have
no problem with the MarketDataSnapshotFullRefresh, but quickfixj always
rejects the MarketDataIncrementalRefresh complaining that tag 167
(SecurityType) is not defined for this message type. I checked the
FIX42.xml, and verified that tag 167 is defined for
MarketDataIncrementalRefresh under group NoMDEntries. I took a look at the
DataDictionary.java, and it seems the validation step searches group
definition by name. And the group name is not unique in FIX42.xml. For
example, group NoMDEntries appears in MarketDataSnapshortFullRefresh as well
as in MarketDataIncrementalRefresh, and the set of tags are different for
the two groups. Can this be the cause to the problem? I am attaching the
quickfixj trace for reference. Any advice would be greatly appreciated.
--Wenchao-
[java] <20060503-06:16:06, FIX.4.2:PRICE->fc, outgoing> (8=FIX.4.2
9=172 35=V 34=3 49=PRICE 52=20060503-06:16:06.776 56=fc 262=2001 263=1 264=1
265=1 266=Y 146=1 55=6J 48=CME000040287 167=FUT 200=200606 207=CME 267=4
269=5 269=4 269=7 269=8 10=110 )
[java] <20060503-06:16:06, FIX.4.2:PRICE->fc, incoming> (8=FIX.4.2
9=00200 35=W 49=fc 56=PRICE 34=132 52=20060503-06:16:06.884 55=6J
48=CME000040287 10455=6JM6 167=FUT 207=CME 262=2001 387=2087 200=200606
268=4 269=4 270=8873 269=5 270=8892 269=7 270=8893 269=8 270=8870 10=128 )
[java] <20060503-06:16:36, FIX.4.2:PRICE->fc, incoming> (8=FIX.4.2
9=00056 35=0 49=fc 56=PRICE 34=133 52=20060503-06:16:36.884 10=207 )
[java] <20060503-06:16:36, FIX.4.2:PRICE->fc, outgoing> (8=FIX.4.2 9=54
35=0 34=4 49=PRICE 52=20060503-06:16:36.964 56=fc 10=217 )
...
[java] <20060503-06:24:22, FIX.4.2:PRICE->fc, incoming> (8=FIX.4.2
9=00161 35=X 49=fc 56=PRICE 34=149 52=20060503-06:24:22.472 262=2001 268=1
279=1 55=6J 48=CME000040287 10455=6JM6 167=FUT 207=CME 269=7 270=8894
387=2115 200=200606 10=061 )
[java] <20060503-06:24:22, FIX.4.2:PRICE->fc, event> (Message 149
Rejected: Tag not defined for this message type:167)
[java] <20060503-06:24:22, FIX.4.2:PRICE->fc, outgoing> (8=FIX.4.2
9=123 35=3 34=20 49=PRICE 52=20060503-06:24:22.556 56=fc 45=149 58=Tag not
defined for this message type 371=167 372=X 373=2 10=118 )
----------------------------------------------------------
IMPORTANT WARNING: This email (and any attachments) is only intended for the use of the person or entity to which it is addressed, and may contain information that is privileged and confidential. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. Unauthorized redisclosure or failure to maintain confidentiality may subject you to federal and state penalties. If you are not the recipient, please immediately notify us by return email, and delete this message from your computer.
----------------------------------------------------------
|
|
From: John H. <JH...@al...> - 2006-05-02 18:21:41
|
Would greatly appreciate it if anybody could point me in the right
direction here:
=20
- I've successfully built the quickfix_net and quickfix_net_messages
dlls from the vs8 project.
- I've successfully built a VB application in VS 2005 which receives
messages from my clearing firm, uses messagecracker and stores the
fields in a database properly (ExecReports only for fills).
- I can successfully pass my clearing firm's session level and message
level testing with my app in debug mode withint he IDE
- I can leave the interface running on my machine from within the
development environment all day without problems
=20
When I attempt to publish the application so I can install it on a
production machine, the install completely crashes, asking me if I want
to send the error report to Microsoft. All other publishing from this
machine works without a hitch. If I try to install onto my devel
machine it still crashes, so I don't think its a problem looking for
dependencies like the seqnum files, etc.
=20
Is this most likely a problem with my VB app publishing settings
(includes, etc.)? Is it perhaps a problem with my quickfix_net and
quickfix_net_messages builds? Do I need to set specific properties for
building the dlls (debug vs. release)?
=20
I'm at a loss as to where to begin looking for the problem and any help
would be greatly appreciated.
=20
Thank you,
=20
John
=20
--------------------------------------
John Haldi
Allagash Trading, LLC
120 Broadway, 20th Floor
New York, NY 10271
212.433.3958
jo...@al...
=20
|
|
From: Shane R. <SR...@Ty...> - 2006-05-02 08:53:57
|
I am using QF with CME and have it configured for week long sessions. Ideally my engine should run all week without stopping but in the event that it does have to re-login mid-week. I would like to back-request up to the maximum 2500 messages as allowed by CME. How do I do this? =20 Additionally I am trying to understand how to ascertain when connecting what the current counter party seq num is so that I can subtract 2500 from it and request this batch of messages. =20 Thanks in advance, =20 Shane Ryan +44(0) 207 151 0056 =20 Tyler Capital 4Th Floor 40 Lime St EC3M 7AW =20 |
|
From: Steve B. <sb...@sm...> - 2006-05-01 20:04:03
|
Also, remember that SourceForge is currently having trouble with the synchronization of their anonymous CVS. The last time I checked (about a week ago) the anonymous quickfix repository=20 was about a month or more out of date. Steve =20 > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Tom Dilatush > Sent: Monday, May 01, 2006 9:21 PM > To: qui...@li... > Subject: [Quickfix-developers] CVS issues... >=20 > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > On another SourceForge project I'm involved with, we=20 > discovered that the=20 > error message "login aborted" is the normal response (at least on=20 > SourceForge) when the CVS server is overloaded. This is=20 > apparently its=20 > load-limiting mechanism: to refuse logins. The obscure error message=20 > may be intended to introduce a delay between retries, but I'm=20 > not sure=20 > about that part <smile>. >=20 > In any case, whether you use the anonymous login or the=20 > account login,=20 > retrying enough times will make it work. I just checked out the=20 > quickfixj tree, and it took me about 10 tries with the login=20 > command and=20 > about 15 with the co command -- but eventually, it worked. >=20 > Tom... >=20 >=20 >=20 > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web=20 > services, security? > Get stuff done quickly with pre-integrated technology to make=20 > your job easier > Download IBM WebSphere Application Server v.1.0.1 based on=20 > Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > dat=3D121642 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers >=20 |
|
From: Tom D. <to...@di...> - 2006-05-01 19:21:28
|
On another SourceForge project I'm involved with, we discovered that the error message "login aborted" is the normal response (at least on SourceForge) when the CVS server is overloaded. This is apparently its load-limiting mechanism: to refuse logins. The obscure error message may be intended to introduce a delay between retries, but I'm not sure about that part <smile>. In any case, whether you use the anonymous login or the account login, retrying enough times will make it work. I just checked out the quickfixj tree, and it took me about 10 tries with the login command and about 15 with the co command -- but eventually, it worked. Tom... |
|
From: Caleb E. <cal...@gm...> - 2006-05-01 13:03:39
|
On 4/29/06, Brian Erst <azz...@ya...> wrote: > That code was rearranged because otherwise we would timeout (heartbeat) w= hile > processing gap-fills/sequence resends. If you check the sequence number p= rior to > incrementing the received time, the heartbeat timeout got triggered and t= he session > would drop. > > We'll have to be careful how to rearrange the code so we don't fix the ne= w problem by reintroducing the old one. > > I'm attaching the original email chain that caused us to create the exist= ing code (Jun 27 2005 patch to Session.cpp). The change you outline was made to Session.cpp in between releases 1.9.4 and 1.10.2 of QuickFIX, as was the change I made to "optimize" the ResendRequest processing. I think the two have similar aims. In versions of QuickFIX prior to and including 1.9.4, a big gap fill could take a number of disconnect/reconnect iterations before it would get cleared up. This was because QuickFIX would potentially issue multiple ResendRequest messages for an identical range of messages, causing needless extra traffic and delays before the Session was able to catch up with the far-end. This would cause lastReceivedTime not to be updated, because messages in the proper range were not being received. Since 1.10.2, the QF code should issue one and only one ResendRequest when it detects a gap, and almost immediately start receiving "in-sequence" messages from the far end, which would cause the old lastReceivedTime update logic to function correctly AFAICT. I think the lastReceivedTime update should be moved back where it was in version 1.73 of Session.cpp. This would allow a proper disconnect when a connection isn't properly syncing or heartbeating. The way the code is setup now, a conneciton will never drop as long as the far end is sending SOME valid FIX messages! This is definitely a bit tricky and we should probably come up with a test for this. -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Brian E. <azz...@ya...> - 2006-04-30 03:28:21
|
Oren -
That code was rearranged because otherwise we would timeout (heartbeat) while processing gap-fills/sequence resends. If you check the sequence number prior to incrementing the received time, the heartbeat timeout got triggered and the session would drop.
We'll have to be careful how to rearrange the code so we don't fix the new problem by reintroducing the old one.
I'm attaching the original email chain that caused us to create the existing code (Jun 27 2005 patch to Session.cpp).
- Brian
---- Original messages follow ----
Oren -
I believe the following change to Session.cpp will fix the timeout
problem when receiving out-of-sequence messages while awaiting a
sequence reset/gap-fill:
Move the following lines in Session::verify(...)
UtcTimeStamp now;
m_state.lastReceivedTime( now );
from their current position up to a spot just before the preceding
if/else clause:
-->>Place the code here<<--
if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )
This will increment the "lastReceivedTime" in the SessionState object
even when the sequence number is wrong. This appears to solve a whole
bunch of interrelated timeouts that could occur in this scenario (test
request, heartbeat, logon response, etc.) in one quick hit. Sequence
too low is largely unaffected by this change, as it will cause a
disconnect when hit, so that part of the code shouldn't need to be
rearranged.
It was somewhat unclear to me whether the following line:
m_state.testRequest( 0 );
Also needed to be moved, but it seemed like it did not.
- Brian Erst
Thynk Software, Inc.
--- Oren Miller <or...@qu...> wrote:
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Seems to me this shouldn't be happening. I'm guessing that the
> engine isn't
> processing the message because the sequence number is too high, hence
> no
> heartbeat is processed. I believe that out of sequence messages
> should
> probably count as a keep-alive even if their contents arn't
> processed.
>
> --oren
>
> ----- Original Message -----
> From: "Alexey Zubko" <ale...@in...>
> To: <qui...@li...>
> Sent: Monday, June 27, 2005 1:44 PM
> Subject: [Quickfix-developers] MsgSeqNum too high problem
>
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi,
> >
> > I'd like to ask if QF initiator acts correctly in the following
> scenario.
> > The initiator detects that seqnum of a server is too high and sends
> a
> > resend message.
> > The server doesn't resend requested messages, but there are
> heartbeat
> > messages.
> > The initiator disconnects because of timeout on heartbeat. :-)
> > Below is the initiator's log.
> >
> > 20050627-17:52:50 : Created session
> > 20050627-17:52:51 : Connecting to eng-server on port 5725
> > 20050627-17:52:51 : Connection succeeded
> > 20050627-17:52:52 : Initiated logon request
> > 20050627-17:53:15 : Received logon response
> > 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
> 15
> > 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14
> > 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
> 16
> > 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15
> > 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
> 17
> > 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16
> > 20050627-17:53:22 : Sent test request TEST
> > 20050627-17:53:22 : MsgSeqNum too high, expecting 13 but received
> 18
> > 20050627-17:53:22 : Sent ResendRequest FROM: 13 TO: 17
> > 20050627-17:53:37 : MsgSeqNum too high, expecting 13 but received
> 19
> > 20050627-17:53:37 : Sent ResendRequest FROM: 13 TO: 18
> > 20050627-17:53:40 : Timed out waiting for heartbeat
> > 20050627-17:53:40 : Disconnecting
> >
> >
> >
> > --
> >
> > Regards,
> > Alexey Zubko
> >
> > Infinium Capital Corporation
> > (416) 360-7000 ext. 305
----- Original Message ----
From: Oren Miller <or...@qu...>
To: Caleb Epstein <cal...@gm...>; Ajay Kamdar <Aja...@tr...>
Cc: qui...@li...
Sent: Saturday, April 29, 2006 6:18:38 PM
Subject: Re: [Quickfix-developers] Incorrect handling of SequenceReset
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html
----- Original Message -----
In practice, the Session should eventually disconnect due to heartbeat
timeouts if the SequenceReset isn't processed properly. Did you wait
long enough for this to happen in your tests?
-----------------------------
I don't think it would actually. This is a snippet of the code for
processing messages:
UtcTimeStamp now;
m_state.lastReceivedTime( now );
m_state.testRequest( 0 );
if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )
{
doTargetTooHigh( msg );
return false;
}
else if ( checkTooLow && isTargetTooLow( msgSeqNum ) )
{
doTargetTooLow( msg );
return false;
}
Looks like the lastReceivedTime is being updated before we are even checking
the sequence numbers. So I don't believe a heartbeat timeout would ever
occur. Perhaps we should only update the received time if we actually
process the message?
--oren
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Oren M. <or...@qu...> - 2006-04-29 23:18:51
|
----- Original Message -----
In practice, the Session should eventually disconnect due to heartbeat
timeouts if the SequenceReset isn't processed properly. Did you wait
long enough for this to happen in your tests?
-----------------------------
I don't think it would actually. This is a snippet of the code for
processing messages:
UtcTimeStamp now;
m_state.lastReceivedTime( now );
m_state.testRequest( 0 );
if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )
{
doTargetTooHigh( msg );
return false;
}
else if ( checkTooLow && isTargetTooLow( msgSeqNum ) )
{
doTargetTooLow( msg );
return false;
}
Looks like the lastReceivedTime is being updated before we are even checking
the sequence numbers. So I don't believe a heartbeat timeout would ever
occur. Perhaps we should only update the received time if we actually
process the message?
--oren
|
|
From: Oren M. <or...@qu...> - 2006-04-29 23:05:48
|
MessageFYI, I've added a new ResetOnLogon settings which in the case of =
an initiator, will reset the sequence numbers before sending a logon =
(causing a ResetSeqNumFlag to go out as well). In the case of an =
initiator, the sequence number will be reset when receiving a logon =
regardless of whether or not a reset flag is present. This has been =
checked into cvs and will go out with the next release.
--oren
----- Original Message -----=20
From: Ajay Kamdar=20
To: qui...@li...=20
Sent: Saturday, April 29, 2006 2:40 PM
Subject: RE: [Quickfix-developers] Sending 141=3DY
Unless I am missing something obvious, I don't see a direct way to =
navigate from a FIX::SessionID to the session's configuration settings. =
Would it make sense to enhance the Session such that it is constructed =
with a const reference to the Dictionary of its settings which can then =
be accessed by code that has a pointer to a FIX::Session?
Until then I will pass a reference to the Settings to my derived =
Application class and get to the session Settings from there.
- Ajay
-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Saturday, April 29, 2006 1:19 PM
To: Ajay Kamdar; qui...@li...
Subject: Re: [Quickfix-developers] Sending 141=3DY
There is not a configuration setting for this right now (we need =
one). Currently, this has to be accomplished by adding a little bit of =
code. In order to accomplish this, you need to have your application =
reset() the session in onCreate(). This would ensure that the session =
would always have reset sequence numbers after a crash.
--oren
=
________________________________________________________________________
The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by =
anyone else
is unauthorized. If you are not the intended recipient, any =
disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.
TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.
|
|
From: Oren M. <or...@qu...> - 2006-04-29 20:15:47
|
MessageNot sure what you are asking here. You can look up a specific = sessions dictionary with its SessionID using the get method on = SessionSettings: http://www.quickfixengine.org/quickfix/doc/html/class_f_i_x_1_1_session_s= ettings.html#a3 You will need to have access to the SessionSettings object of course. Being able to access the settings directly from the session might be a = nice convenience as well. --oren ----- Original Message -----=20 From: Ajay Kamdar=20 To: qui...@li...=20 Sent: Saturday, April 29, 2006 2:40 PM Subject: RE: [Quickfix-developers] Sending 141=3DY Unless I am missing something obvious, I don't see a direct way to = navigate from a FIX::SessionID to the session's configuration settings. = Would it make sense to enhance the Session such that it is constructed = with a const reference to the Dictionary of its settings which can then = be accessed by code that has a pointer to a FIX::Session? Until then I will pass a reference to the Settings to my derived = Application class and get to the session Settings from there. - Ajay -----Original Message----- From: Oren Miller [mailto:or...@qu...]=20 Sent: Saturday, April 29, 2006 1:19 PM To: Ajay Kamdar; qui...@li... Subject: Re: [Quickfix-developers] Sending 141=3DY There is not a configuration setting for this right now (we need = one). Currently, this has to be accomplished by adding a little bit of = code. In order to accomplish this, you need to have your application = reset() the session in onCreate(). This would ensure that the session = would always have reset sequence numbers after a crash. --oren = ________________________________________________________________________ The information in this email is confidential and may be legally = privileged. It is intended solely for the addressee. Access to this email by = anyone else is unauthorized. If you are not the intended recipient, any = disclosure, copying, distribution or any action taken or omitted to be taken in reliance on = it, is prohibited and may be unlawful. TradeWeb reserves the right to monitor and review the content of all = messages sent to or from this e-mail address. Messages sent to or from this e-mail = address may be stored on the TradeWeb e-mail system. |
|
From: Ajay K. <Aja...@tr...> - 2006-04-29 19:41:03
|
Unless I am missing something obvious, I don't see a direct way to navigate from a FIX::SessionID to the session's configuration settings. Would it make sense to enhance the Session such that it is constructed with a const reference to the Dictionary of its settings which can then be accessed by code that has a pointer to a FIX::Session? =20 Until then I will pass a reference to the Settings to my derived Application class and get to the session Settings from there. =20 - Ajay -----Original Message----- From: Oren Miller [mailto:or...@qu...]=20 Sent: Saturday, April 29, 2006 1:19 PM To: Ajay Kamdar; qui...@li... Subject: Re: [Quickfix-developers] Sending 141=3DY =09 =09 There is not a configuration setting for this right now (we need one). Currently, this has to be accomplished by adding a little bit of code. In order to accomplish this, you need to have your application reset() the session in onCreate(). This would ensure that the session would always have reset sequence numbers after a crash. =20 --oren =20 -------------------------------------------------------------------------= -- The information in this email is confidential and may be legally = privileged. It is intended solely for the addressee. Access to this email by anyone = else is unauthorized. If you are not the intended recipient, any disclosure, = copying, distribution or any action taken or omitted to be taken in reliance on = it, is prohibited and may be unlawful. TradeWeb reserves the right to monitor and review the content of all = messages sent to or from this e-mail address. Messages sent to or from this e-mail = address may be stored on the TradeWeb e-mail system. |
|
From: Ajay K. <Aja...@tr...> - 2006-04-29 19:07:31
|
-----Original Message----- From: Caleb Epstein [mailto:cal...@gm...]=20 Sent: Saturday, April 29, 2006 8:10 AM To: Ajay Kamdar Cc: qui...@li... Subject: Re: [Quickfix-developers] Incorrect handling of SequenceReset On 4/28/06, Ajay Kamdar <Aja...@tr...> wrote: > > I am testing QuickFIX 1.11.0 to see if I can use it for a new project=20 > instead of our current production FIX engine. During my tests I saw=20 > incorrect behavior in QuickFIX's handling of a SequenceReset message.=20 > It looks like (a) QuickFIX failed to reset its next expted target=20 > number in response to a SequenceReset, and (b) subsequenly refused to=20 > send another resend request for ever because it had already sent a=20 > previous resend request. I saw this happen once, but unfortunately=20 > can't reproduce it consistently. Is this something that rings a bell=20 > with anyone? Given the event log you included, the application clearly received and processed the SequenceReset and looking at the code, there's nothing else that could happen but it changing the state's next expected sequence number. What sort of Store are you using for this NullApplication? Perhaps its not behaving correctly w/r/t updating sequence numbers. Given that there are extensive tests to exercise SequenceResets, it seems likely that there is something in your application or configuration thats leading to this behavior. <snip> In practice, the Session should eventually disconnect due to heartbeat timeouts if the SequenceReset isn't processed properly. Did you wait long enough for this to happen in your tests? > Here's the relevant excerpt from the FIX message and event log: > > 20060428-15:41:27 Incoming FIX :=20 > = 8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D5=0149=3DCAPISIM=0152=3D20060428-15:= 41:27.349=0156=3DCAPIGW > =0110=3D166=01 > 20060428-15:41:27 : MsgSeqNum too high, expecting 1 but received 5 > 20060428-15:41:27 Outgoing FIX : > 8=3DFIX.4.4=019=3D65=0135=3D2=0134=3D6=0149=3DCAPIGW=0152=3D20060428-15:4= 1:27.349=0156=3DCAPISIM=017 =3D1=0116=3D0=0110=3D036=01 > 20060428-15:41:27 : Sent ResendRequest FROM: 1 TO: 0 > 20060428-15:41:27 Incoming FIX : > 8=3DFIX.4.4=019=3D98=0135=3D4=0134=3D1=0143=3DY=0149=3DCAPISIM=0152=3D200= 60428-15:41:27.349=0156=3DCAP IGW=01122=3D20060428-15:41:27.349=0136=3D6=01123=3DY=0110=3D192=01 > 20060428-15:41:27 : Received SequenceReset FROM: 1 TO: 6 > 20060428-15:41:57 Incoming FIX : > 8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D6=0149=3DCAPISIM=0152=3D20060428-15:= 41:57.349=0156=3DCAPIGW=011 0=3D170=01 > 20060428-15:41:57 : MsgSeqNum too high, expecting 1 but received 6 This makes me suspect something wrong with your Application's Store.=20 Clearly QF handled the SequenceReset above, so it should be expecting SeqNum 6 here. -- Caleb Epstein caleb dot epstein at gmail dot com Caleb, For these tests I was using the builtin FIX::FileStoreFactory and the builtin FIX::NullApplication. The SequenceReset was received at 15:41:27, and then the "Already sent Resend Request" message kept on showing up every 30 seconds upon every heartbeat (there was no other traffic) until 15:48:57 after which I disconnected the session manually. Unfortunately other than this one instance, I have been unable to reproduce the problem. I have included the configuration below in case something stands out.=20 Thanks, - Ajay [DEFAULT] ConnectionType=3Dacceptor SocketAcceptPort=3D5001 FileStorePath=3Dstore FileLogPath=3Dlog StartTime=3D00:00:00 EndTime=3D00:00:00 MillisecondsInTimeStamp=3DY =09 DataDictionary=3Dspec/FIX44.xml UseDataDictionary=3DY SocketNodelay=3DY ResetOnLogout=3DY I ResetOnDisconnect=3DY =09 SendResetSeqNumFlag=3DY # undocumented flag [SESSION] BeginString=3DFIX.4.4 ConnectionType=3Dinitiator SenderCompID=3DCAPISIM TargetCompID=3DCAPIGW SocketConnectHost=3Dlocalhost SocketConnectPort=3D5001 HeartBtInt=3D30 =09 ReconnectInterval=3D30 =09 SendResetSeqNumFlag=3DY # undocumented flag [SESSION] BeginString=3DFIX.4.4 SenderCompID=3DCAPIGW TargetCompID=3DCAPISIM -------------------------------------------------------------------------= -- The information in this email is confidential and may be legally = privileged. It is intended solely for the addressee. Access to this email by anyone = else is unauthorized. If you are not the intended recipient, any disclosure, = copying, distribution or any action taken or omitted to be taken in reliance on = it, is prohibited and may be unlawful. TradeWeb reserves the right to monitor and review the content of all = messages sent to or from this e-mail address. Messages sent to or from this e-mail = address may be stored on the TradeWeb e-mail system. |
|
From: Oren M. <or...@qu...> - 2006-04-29 17:19:12
|
MessageThere is not a configuration setting for this right now (we need = one). Currently, this has to be accomplished by adding a little bit of = code. In order to accomplish this, you need to have your application = reset() the session in onCreate(). This would ensure that the session = would always have reset sequence numbers after a crash. --oren ----- Original Message -----=20 From: Ajay Kamdar=20 To: qui...@li...=20 Sent: Friday, April 28, 2006 7:29 AM Subject: [Quickfix-developers] Sending 141=3DY It seems to me that there is a problem in consistently sending 141=3DY = in a Logon even when ResetOnLogout, ResetOnDisconnect, and = SendResetSeqNumFlag are all set to Y for a session.=20 When using FIX4.1 and higher, QuickFix decides to set 141=3DY when = initiating a Logon if 1. one of the session config attributes ResetOnLogout, = ResetOnDisconnect, or SendResetSeqNumFlag is set to Y 2. and if the expected sender and target sequence numbers are equal to = 1 When ResetOnLogout and ResetOnDisconnect are set, QuickFix will reset = the sequence numbers to 1 upon a graceful session logout or abrupt = disconnect, the above conditions will be satisfied, and the next Logon = message will contain 141=3DY. However, if the engine process were to = crash for whatever reason, the sequence numbers will NOT be equal to 1 = because QuickFix never got the opportunity to reset the sequence = numbers. Hence when the initiator sends a Logon after the process is = restarted, its Logon will not contain 141=3DY even though all the = necessary configuration attributes are set correctly. From a logical perspective, IMHO in this case it should not make any = difference whether a connection to a counter party was broken because of = a Logout, socket disconnect, or engine crash. Any ideas how to make = QuickFix consistently send 141=3DY with the out of the box configuration = attributes without having to add additional logic in the application? Thanks, - Ajay = ________________________________________________________________________ The information in this email is confidential and may be legally = privileged. It is intended solely for the addressee. Access to this email by = anyone else is unauthorized. If you are not the intended recipient, any = disclosure, copying, distribution or any action taken or omitted to be taken in reliance on = it, is prohibited and may be unlawful. TradeWeb reserves the right to monitor and review the content of all = messages sent to or from this e-mail address. Messages sent to or from this e-mail = address may be stored on the TradeWeb e-mail system. |
|
From: Caleb E. <cal...@gm...> - 2006-04-29 12:10:10
|
On 4/28/06, Ajay Kamdar <Aja...@tr...> wrote: > > I am testing QuickFIX 1.11.0 to see if I can use it for a new project > instead of our current production FIX engine. During my tests I saw > incorrect behavior in QuickFIX's handling of a SequenceReset message. It > looks like (a) QuickFIX failed to reset its next expted target number in > response to a SequenceReset, and (b) subsequenly refused to send another > resend request for ever because it had already sent a previous resend > request. I saw this happen once, but unfortunately can't reproduce it > consistently. Is this something that rings a bell with anyone? Given the event log you included, the application clearly received and processed the SequenceReset and looking at the code, there's nothing else that could happen but it changing the state's next expected sequence number. What sort of Store are you using for this NullApplication? Perhaps its not behaving correctly w/r/t updating sequence numbers. Given that there are extensive tests to exercise SequenceResets, it seems likely that there is something in your application or configuration thats leading to this behavior. > There are a couple of things that might be problematic: > > 1) QuickFIX's handling of the SequenceReset is split across two methods. = The > Session::nextSequenceReset method that processes the incoming sequence ca= ll > m_state.setNextTargetMsgSeqNum(), but the > m_state.resendRange() is reset in Session::verify only when the next mess= age > arrives. If the connection were to drop for whatever reason after the > SequenceReset and between the next message's arrival, it seems to me that > the m_state.m_resendRange would not reflect the correct state that the > resend request had been satisfied. Wouldn't it be better to reset > m_state.m_resendRange within Session::nextSequenceReset right where the n= ext > target seqnum is updated? Look at the end of Session::disconnect, which is called whenever the Session disconnects. m_resendRange is reset to (0,0). > 2) There is no timeout associated with how long QuickFIX waits for a rese= nd > request to be satisfied. If the counter party's resent messages or > SequenceReset are queued up behind a bunch of other messages, or if > QuickFIX does not correctly process the SequenceReset (as the log below > shows), then the session can potentially loop for a very long time > complaining about MsgSeqNum too high and keep queuing up new messages. FW= IW, > the Appia FIX engine (I used to manage its development team) in this type= of > a situation dropped the connection after a configurable interval waiting = for > the resend request to be satisfied. A dropped connection typically gets > picked up quickly by monitoring systems, thereby alerting someone that th= ere > is a problem that may need intervention. IMHO QuickFIX should have someth= ing > similar in Session.doTargetTooHigh to break out in case a resend request = is > not satisfied for a long time. This is an interesting idea. Perhaps this could be made configurable in the Session. In practice, the Session should eventually disconnect due to heartbeat timeouts if the SequenceReset isn't processed properly. Did you wait long enough for this to happen in your tests? > Here's the relevant excerpt from the FIX message and event log: > > 20060428-15:41:27 Incoming FIX : > 8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D5=0149=3DCAPISIM=0152=3D20060428-15:= 41:27.349=0156=3DCAPIGW=0110=3D166=01 > 20060428-15:41:27 : MsgSeqNum too high, expecting 1 but received 5 > 20060428-15:41:27 Outgoing FIX : > 8=3DFIX.4.4=019=3D65=0135=3D2=0134=3D6=0149=3DCAPIGW=0152=3D20060428-15:4= 1:27.349=0156=3DCAPISIM=017=3D1=0116=3D0=0110=3D036=01 > 20060428-15:41:27 : Sent ResendRequest FROM: 1 TO: 0 > 20060428-15:41:27 Incoming FIX : > 8=3DFIX.4.4=019=3D98=0135=3D4=0134=3D1=0143=3DY=0149=3DCAPISIM=0152=3D200= 60428-15:41:27.349=0156=3DCAPIGW=01122=3D20060428-15:41:27.349=0136=3D6=011= 23=3DY=0110=3D192=01 > 20060428-15:41:27 : Received SequenceReset FROM: 1 TO: 6 > 20060428-15:41:57 Incoming FIX : > 8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D6=0149=3DCAPISIM=0152=3D20060428-15:= 41:57.349=0156=3DCAPIGW=0110=3D170=01 > 20060428-15:41:57 : MsgSeqNum too high, expecting 1 but received 6 This makes me suspect something wrong with your Application's Store.=20 Clearly QF handled the SequenceReset above, so it should be expecting SeqNum 6 here. -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Ajay K. <Aja...@tr...> - 2006-04-28 22:32:55
|
I am testing QuickFIX 1.11.0 to see if I can use it for a new project
instead of our current production FIX engine. During my tests I saw
incorrect behavior in QuickFIX's handling of a SequenceReset message. It
looks like (a) QuickFIX failed to reset its next expted target number in
response to a SequenceReset, and (b) subsequenly refused to send another
resend request for ever because it had already sent a previous resend
request. I saw this happen once, but unfortunately can't reproduce it
consistently. Is this something that rings a bell with anyone?
=20
There are a couple of things that might be problematic:
=20
1) QuickFIX's handling of the SequenceReset is split across two methods.
The Session::nextSequenceReset method that processes the incoming
sequence call m_state.setNextTargetMsgSeqNum(), but the
m_state.resendRange() is reset in Session::verify only when the next
message arrives. If the connection were to drop for whatever reason
after the SequenceReset and between the next message's arrival, it seems
to me that the m_state.m_resendRange would not reflect the correct state
that the resend request had been satisfied. Wouldn't it be better to
reset m_state.m_resendRange within Session::nextSequenceReset right
where the next target seqnum is updated?
=20
2) There is no timeout associated with how long QuickFIX waits for a
resend request to be satisfied. If the counter party's resent messages
or SequenceReset are queued up behind a bunch of other messages, or if
QuickFIX does not correctly process the SequenceReset (as the log below
shows), then the session can potentially loop for a very long time
complaining about MsgSeqNum too high and keep queuing up new messages.
FWIW, the Appia FIX engine (I used to manage its development team) in
this type of a situation dropped the connection after a configurable
interval waiting for the resend request to be satisfied. A dropped
connection typically gets picked up quickly by monitoring systems,
thereby alerting someone that there is a problem that may need
intervention. IMHO QuickFIX should have something similar in
Session.doTargetTooHigh to break out in case a resend request is not
satisfied for a long time.
=20
Anyway, coming back to the problem that I saw. In my test setup, I have
a) two QuickFIX sessions back to back, so there is no complication due
to how some other engine does resends
b) I am writing both the FIX messages and events into a single log file
to make it simpler to follow the sequence of events. In the log excerpt
shown below, the FIX message sent/received is written first followed by
the event description.
c) I am using FIX::NullApplication for my test, so there is no
application event handler that could be interfering with the
SequenceReset handling
=20
Here's the sequence of events that transpired
1) CAPIGW was expecing msg with seqnum 5, but got seqnum 1
2) CAPIGW sent a ResendRequest from 1 to 0 to CAPISIM
3) CAPIMSIM responded with a SequenceReset 34=3D1 resetting the seqnum =
to
6
As subsequent messages show, QuickFIX failed to correctly process
the SequenceReset
4) Message from CAPISIM arrives with 34=3D6
5) CAPIGW complains that MsgSeqNum is too high
6) CAPIGW says a ResendRequest from 1 to 4 has already been sent, and
hence does not send another ResendRequest
7) CAPIGW loops for ever on steps 4, 5, 6 because it is still waiting
for messages that it should have already skipped if it had correctly
processed the SequenceReset in step #3.
=20
Here's the relevant excerpt from the FIX message and event log:
=20
20060428-15:41:27 Incoming FIX :
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D5=0149=3DCAPISIM=0152=3D20060428-15:=
41:27.349=0156=3DCAPIGW=011
0=3D166=01
20060428-15:41:27 : MsgSeqNum too high, expecting 1 but received 5
20060428-15:41:27 Outgoing FIX :
8=3DFIX.4.4=019=3D65=0135=3D2=0134=3D6=0149=3DCAPIGW=0152=3D20060428-15:4=
1:27.349=0156=3DCAPISIM=017
=3D1=0116=3D0=0110=3D036=01
20060428-15:41:27 : Sent ResendRequest FROM: 1 TO: 0
20060428-15:41:27 Incoming FIX :
8=3DFIX.4.4=019=3D98=0135=3D4=0134=3D1=0143=3DY=0149=3DCAPISIM=0152=3D200=
60428-15:41:27.349=0156=3DCAP
IGW=01122=3D20060428-15:41:27.349=0136=3D6=01123=3DY=0110=3D192=01
20060428-15:41:27 : Received SequenceReset FROM: 1 TO: 6
20060428-15:41:57 Incoming FIX :
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D6=0149=3DCAPISIM=0152=3D20060428-15:=
41:57.349=0156=3DCAPIGW=011
0=3D170=01
20060428-15:41:57 : MsgSeqNum too high, expecting 1 but received 6
20060428-15:41:57 : Already sent ResendRequest FROM: 1 TO: 4. Not
sending another.
20060428-15:41:57 Outgoing FIX :
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D7=0149=3DCAPIGW=0152=3D20060428-15:4=
1:57.349=0156=3DCAPISIM=011
0=3D171=01
20060428-15:42:27 Outgoing FIX :
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D8=0149=3DCAPIGW=0152=3D20060428-15:4=
2:27.349=0156=3DCAPISIM=011
0=3D170=01
20060428-15:42:27 Incoming FIX :
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D7=0149=3DCAPISIM=0152=3D20060428-15:=
42:27.349=0156=3DCAPIGW=011
0=3D169=01
20060428-15:42:27 : MsgSeqNum too high, expecting 1 but received 7
20060428-15:42:27 : Already sent ResendRequest FROM: 1 TO: 4. Not
sending another.
20060428-15:42:57 Outgoing FIX :
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D9=0149=3DCAPIGW=0152=3D20060428-15:4=
2:57.350=0156=3DCAPISIM=011
0=3D166=01
20060428-15:42:57 Incoming FIX :
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D8=0149=3DCAPISIM=0152=3D20060428-15:=
42:57.350=0156=3DCAPIGW=011
0=3D165=01
20060428-15:42:57 : MsgSeqNum too high, expecting 1 but received 8
20060428-15:42:57 : Already sent ResendRequest FROM: 1 TO: 4. Not
sending another.
-------------------------------------------------------------------------=
--
The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by anyone =
else
is unauthorized. If you are not the intended recipient, any disclosure, =
copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.
TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.
|
98 messages has been excluded from this view by a project administrator.
