quickfix-developers Mailing List for QuickFIX (Page 251)
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: Oren M. <ore...@ya...> - 2004-03-09 05:03:58
|
Vijay, You still have some build artifacts from you VC6 build lying around. This is confusing your VC7 build when trying to link in object files since their respective STL implementations are not comparible. If you are building VC7 you need to make sure that these object files are gone. You can either do a full clean on all VC6 projects, delete all the Release and Build directories, or what I really prefer is to just have separate quickfix directories for VC6 and VC7, that way you never have to worry about this. --oren --- Vijay Singh Yadav <vy...@op...> wrote: > Hello All, > I had a project in VC++ 6 that uses Quickfix and it > worked flawlessly. I have moved the code to VC++ 7 > and I get the following errors. I am not able to > diagnose the problem. I am still using straight C++ > API (i.e. not .net) > > thanks, > > -- vijay > > ---------- > Linking... > > LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' > due to '/INCREMENTAL:NO' specification > > quickfix_debug.lib(Acceptor.obj) : warning LNK4049: > locally defined symbol ??1logic_error@std@@UAE@XZ > (public: virtual __thiscall > std::logic_error::~logic_error(void)) imported > > quickfix_debug.lib(Dictionary.obj) : warning > LNK4049: locally defined symbol > ??1logic_error@std@@UAE@XZ (public: virtual > __thiscall std::logic_error::~logic_error(void)) > imported > > quickfix_debug.lib(SessionFactory.obj) : warning > LNK4049: locally defined symbol > ??1logic_error@std@@UAE@XZ (public: virtual > __thiscall std::logic_error::~logic_error(void)) > imported > > : > > : > > : > > quickfix_debug.lib(Session.obj) : warning LNK4217: > locally defined symbol > ??0logic_error@std@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@@Z > (public: __thiscall > std::logic_error::logic_error(class > std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > > const &)) imported in function "public: __thiscall > FIX::FieldConvertError::FieldConvertError(void)" > (??0FieldConvertError@FIX@@QAE@XZ) > > quickfix_debug.lib(Message.obj) : warning LNK4049: > locally defined symbol > ??0logic_error@std@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@@Z > (public: __thiscall > std::logic_error::logic_error(class > std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > > const &)) imported > > quickfix_debug.lib(FieldMap.obj) : warning LNK4049: > locally defined symbol > ??0logic_error@std@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@@Z > (public: __thiscall > std::logic_error::logic_error(class > std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > > const &)) imported > > quickfix_debug.lib(Initiator.obj) : warning LNK4049: > locally defined symbol > ??0logic_error@std@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@1@@Z > (public: __thiscall > std::logic_error::logic_error(class > std::basic_string<char,struct > std::char_traits<char>,class std::allocator<char> > > const &)) imported > > quickfix_debug.lib(Acceptor.obj) : warning LNK4049: > locally defined symbol > ??0logic_error@std@@QAE@ABV01@@Z (public: __thiscall > std::logic_error::logic_error(class std::logic_error > const &)) imported > > : > > : > > : > > N¬HS^µéX¬²'²Þu¼ÂâìSºÚ+©l·.)îÆÛ¢¸Þ±éíyÖò ©âzThm¸§°úÞ²'^Ö§t!¡ñ?:(µç!h'¬-æ«?ëÞ¯+ax ®ºwZéíj[-¢Ì¬µévh§Ëkjبm§ÿÚvÊ,vw(ö?õã½Z ÷ë(§%ɺ'$~,]z÷¥¢«²f¢)à+-Bèø±uëÞ^®Éb²Û,¢êÜyú+?éÞ¶m¦Ïÿ+-²Ê.Ç¢¸ ?ë+-³ùb²Ø§~?êº'$~,]z÷¥¢« __________________________________ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com |
|
From: Vijay S. Y. <vy...@op...> - 2004-03-08 22:48:53
|
SGVsbG8gQWxsLA0KIEkgaGFkIGEgcHJvamVjdCBpbiBWQysrIDYgdGhhdCB1c2VzIFF1aWNrZml4 IGFuZCBpdCB3b3JrZWQgZmxhd2xlc3NseS4gSSBoYXZlIG1vdmVkIHRoZSBjb2RlIHRvIFZDKysg NyBhbmQgSSBnZXQgdGhlIGZvbGxvd2luZyBlcnJvcnMuIEkgYW0gbm90IGFibGUgdG8gZGlhZ25v c2UgdGhlIHByb2JsZW0uIEkgYW0gc3RpbGwgdXNpbmcgc3RyYWlnaHQgQysrIEFQSSAoaS5lLiBu b3QgLm5ldCkNCiANCnRoYW5rcywNCiANCi0tIHZpamF5DQogDQotLS0tLS0tLS0tDQpMaW5raW5n Li4uDQoNCkxJTksgOiB3YXJuaW5nIExOSzQwNzU6IGlnbm9yaW5nICcvRURJVEFORENPTlRJTlVF JyBkdWUgdG8gJy9JTkNSRU1FTlRBTDpOTycgc3BlY2lmaWNhdGlvbg0KDQpxdWlja2ZpeF9kZWJ1 Zy5saWIoQWNjZXB0b3Iub2JqKSA6IHdhcm5pbmcgTE5LNDA0OTogbG9jYWxseSBkZWZpbmVkIHN5 bWJvbCA/PzFsb2dpY19lcnJvckBzdGRAQFVBRUBYWiAocHVibGljOiB2aXJ0dWFsIF9fdGhpc2Nh bGwgc3RkOjpsb2dpY19lcnJvcjo6fmxvZ2ljX2Vycm9yKHZvaWQpKSBpbXBvcnRlZA0KDQpxdWlj a2ZpeF9kZWJ1Zy5saWIoRGljdGlvbmFyeS5vYmopIDogd2FybmluZyBMTks0MDQ5OiBsb2NhbGx5 IGRlZmluZWQgc3ltYm9sID8/MWxvZ2ljX2Vycm9yQHN0ZEBAVUFFQFhaIChwdWJsaWM6IHZpcnR1 YWwgX190aGlzY2FsbCBzdGQ6OmxvZ2ljX2Vycm9yOjp+bG9naWNfZXJyb3Iodm9pZCkpIGltcG9y dGVkDQoNCnF1aWNrZml4X2RlYnVnLmxpYihTZXNzaW9uRmFjdG9yeS5vYmopIDogd2FybmluZyBM Tks0MDQ5OiBsb2NhbGx5IGRlZmluZWQgc3ltYm9sID8/MWxvZ2ljX2Vycm9yQHN0ZEBAVUFFQFha IChwdWJsaWM6IHZpcnR1YWwgX190aGlzY2FsbCBzdGQ6OmxvZ2ljX2Vycm9yOjp+bG9naWNfZXJy b3Iodm9pZCkpIGltcG9ydGVkDQoNCjoNCg0KOg0KDQo6DQoNCnF1aWNrZml4X2RlYnVnLmxpYihT ZXNzaW9uLm9iaikgOiB3YXJuaW5nIExOSzQyMTc6IGxvY2FsbHkgZGVmaW5lZCBzeW1ib2wgPz8w bG9naWNfZXJyb3JAc3RkQEBRQUVAQUJWPyRiYXNpY19zdHJpbmdARFU/JGNoYXJfdHJhaXRzQERA c3RkQEBWPyRhbGxvY2F0b3JAREAyQEAxQEBaIChwdWJsaWM6IF9fdGhpc2NhbGwgc3RkOjpsb2dp Y19lcnJvcjo6bG9naWNfZXJyb3IoY2xhc3Mgc3RkOjpiYXNpY19zdHJpbmc8Y2hhcixzdHJ1Y3Qg c3RkOjpjaGFyX3RyYWl0czxjaGFyPixjbGFzcyBzdGQ6OmFsbG9jYXRvcjxjaGFyPiA+IGNvbnN0 ICYpKSBpbXBvcnRlZCBpbiBmdW5jdGlvbiAicHVibGljOiBfX3RoaXNjYWxsIEZJWDo6RmllbGRD b252ZXJ0RXJyb3I6OkZpZWxkQ29udmVydEVycm9yKHZvaWQpIiAoPz8wRmllbGRDb252ZXJ0RXJy b3JARklYQEBRQUVAWFopDQoNCnF1aWNrZml4X2RlYnVnLmxpYihNZXNzYWdlLm9iaikgOiB3YXJu aW5nIExOSzQwNDk6IGxvY2FsbHkgZGVmaW5lZCBzeW1ib2wgPz8wbG9naWNfZXJyb3JAc3RkQEBR QUVAQUJWPyRiYXNpY19zdHJpbmdARFU/JGNoYXJfdHJhaXRzQERAc3RkQEBWPyRhbGxvY2F0b3JA REAyQEAxQEBaIChwdWJsaWM6IF9fdGhpc2NhbGwgc3RkOjpsb2dpY19lcnJvcjo6bG9naWNfZXJy b3IoY2xhc3Mgc3RkOjpiYXNpY19zdHJpbmc8Y2hhcixzdHJ1Y3Qgc3RkOjpjaGFyX3RyYWl0czxj aGFyPixjbGFzcyBzdGQ6OmFsbG9jYXRvcjxjaGFyPiA+IGNvbnN0ICYpKSBpbXBvcnRlZA0KDQpx dWlja2ZpeF9kZWJ1Zy5saWIoRmllbGRNYXAub2JqKSA6IHdhcm5pbmcgTE5LNDA0OTogbG9jYWxs eSBkZWZpbmVkIHN5bWJvbCA/PzBsb2dpY19lcnJvckBzdGRAQFFBRUBBQlY/JGJhc2ljX3N0cmlu Z0BEVT8kY2hhcl90cmFpdHNAREBzdGRAQFY/JGFsbG9jYXRvckBEQDJAQDFAQFogKHB1YmxpYzog X190aGlzY2FsbCBzdGQ6OmxvZ2ljX2Vycm9yOjpsb2dpY19lcnJvcihjbGFzcyBzdGQ6OmJhc2lj X3N0cmluZzxjaGFyLHN0cnVjdCBzdGQ6OmNoYXJfdHJhaXRzPGNoYXI+LGNsYXNzIHN0ZDo6YWxs b2NhdG9yPGNoYXI+ID4gY29uc3QgJikpIGltcG9ydGVkDQoNCnF1aWNrZml4X2RlYnVnLmxpYihJ bml0aWF0b3Iub2JqKSA6IHdhcm5pbmcgTE5LNDA0OTogbG9jYWxseSBkZWZpbmVkIHN5bWJvbCA/ PzBsb2dpY19lcnJvckBzdGRAQFFBRUBBQlY/JGJhc2ljX3N0cmluZ0BEVT8kY2hhcl90cmFpdHNA REBzdGRAQFY/JGFsbG9jYXRvckBEQDJAQDFAQFogKHB1YmxpYzogX190aGlzY2FsbCBzdGQ6Omxv Z2ljX2Vycm9yOjpsb2dpY19lcnJvcihjbGFzcyBzdGQ6OmJhc2ljX3N0cmluZzxjaGFyLHN0cnVj dCBzdGQ6OmNoYXJfdHJhaXRzPGNoYXI+LGNsYXNzIHN0ZDo6YWxsb2NhdG9yPGNoYXI+ID4gY29u c3QgJikpIGltcG9ydGVkDQoNCnF1aWNrZml4X2RlYnVnLmxpYihBY2NlcHRvci5vYmopIDogd2Fy bmluZyBMTks0MDQ5OiBsb2NhbGx5IGRlZmluZWQgc3ltYm9sID8/MGxvZ2ljX2Vycm9yQHN0ZEBA UUFFQEFCVjAxQEBaIChwdWJsaWM6IF9fdGhpc2NhbGwgc3RkOjpsb2dpY19lcnJvcjo6bG9naWNf ZXJyb3IoY2xhc3Mgc3RkOjpsb2dpY19lcnJvciBjb25zdCAmKSkgaW1wb3J0ZWQNCg0KOg0KDQo6 DQoNCjoNCg0K |
|
From: James C. D. <jc...@co...> - 2004-03-04 15:25:23
|
Joel, Thanks. I'll check out Ethereal. Jim James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com _____ From: Joel Natividad [mailto:jna...@tc...] Sent: Thursday, March 04, 2004 9:00 AM To: ore...@ya...; jc...@co...; qui...@li...; qui...@li... Subject: RE: QuickFIX 1.7.0 Available Jim, You may want to check out Ethereal - an open-source protocol analyzer which I've found extremely helpful in debugging FIX. It has a built-in FIX filter and its sooo much easier than slogging thru logfiles. Just fire it up, and put in the string "FIX" in the filter field and you're set. And Oren, keep up the great work!!! BTW, is there an active wishlist? Also, you may want to think about mounting an instance of Bugzilla to engage the community better. I can help in this regard too, since we use Bugzilla extensively in our devt efforts and we've even customized it, borrowing some idears from the KDE Bugzilla instance (bugs.kde.org). I've found that Bugzilla becomes the de-facto wishlist and workflow manager in OSS projects that I participate in. Lastly, it would be great if the community comes together to put up a hosted Exchange Simulator for more robust testing of QuickFix based projects. Best Regards and more power to QuickFix! Joel --------------------------------------------------- Joel Natividad TCG Software Services jna...@tc... Personal Assistant: +1 (201) 356-5070 Fax: +1 (201) 356-5070 ======================================================== From: "James C. Downs" <jc...@co...> To: "'Oren Miller'" <ore...@ya...>, "'announcements QuickFIX'" <qui...@li...>, "'developers QuickFIX'" <qui...@li...>, "'users QuickFIX'" <qui...@li...> Date: Wed, 3 Mar 2004 08:06:20 -0600 Subject: [Quickfix-users] RE: [Quickfix-developers] QuickFIX 1.7.0 Available Oren, The new site looks great! Anne did a outstanding job. Thanks to her and ThoughtWorks.=20 I want to help with some of the initiatives (it looks like I might have = a little more time on my hands shortly :). For me the log viewer it tops = on my list. My eyes can't take looking at 65 meg log files anymore!=20 Jim =20 James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 <file://www.connamara.com> www.connamara.com |
|
From: Joel N. <jna...@tc...> - 2004-03-04 15:21:29
|
Jim, You may want to check out Ethereal - an open-source protocol analyzer which I've found extremely helpful in debugging FIX. It has a built-in FIX filter and its sooo much easier than slogging thru logfiles. Just fire it up, and put in the string "FIX" in the filter field and you're set. And Oren, keep up the great work!!! BTW, is there an active wishlist? Also, you may want to think about mounting an instance of Bugzilla to engage the community better. I can help in this regard too, since we use Bugzilla extensively in our devt efforts and we've even customized it, borrowing some idears from the KDE Bugzilla instance (bugs.kde.org). I've found that Bugzilla becomes the de-facto wishlist and workflow manager in OSS projects that I participate in. Lastly, it would be great if the community comes together to put up a hosted Exchange Simulator for more robust testing of QuickFix based projects. Best Regards and more power to QuickFix! Joel --------------------------------------------------- Joel Natividad TCG Software Services jna...@tc... Personal Assistant: +1 (201) 356-5070 Fax: +1 (201) 356-5070 ======================================================== From: "James C. Downs" <jc...@co...> To: "'Oren Miller'" <ore...@ya...>, "'announcements QuickFIX'" <qui...@li...>, "'developers QuickFIX'" <qui...@li...>, "'users QuickFIX'" <qui...@li...> Date: Wed, 3 Mar 2004 08:06:20 -0600 Subject: [Quickfix-users] RE: [Quickfix-developers] QuickFIX 1.7.0 Available Oren, The new site looks great! Anne did a outstanding job. Thanks to her and ThoughtWorks.=20 I want to help with some of the initiatives (it looks like I might have = a little more time on my hands shortly :). For me the log viewer it tops = on my list. My eyes can't take looking at 65 meg log files anymore!=20 Jim =20 James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com |
|
From: Miller, O. <OM...@ri...> - 2004-03-04 13:57:09
|
Just got word from the email administrator that they lost all my email = from yesterday. This is the address all my sourceforge email is routed = to. So if you sent me any coments about the release during this time I = did not receive them. Please resend. BTW we destroyed our record for number of hits at the website yesterday. = It was 10 times the average. Amazing job getting the word out. Thanks = to everyone. --oren -------------------------- Sent from my BlackBerry Wireless Handheld |
|
From: James C. D. <jc...@co...> - 2004-03-03 14:19:43
|
Oren, The new site looks great! Anne did a outstanding job. Thanks to her and ThoughtWorks.=20 I want to help with some of the initiatives (it looks like I might have = a little more time on my hands shortly :). For me the log viewer it tops = on my list. My eyes can't take looking at 65 meg log files anymore!=20 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: Tuesday, March 02, 2004 10:35 PM To: announcements QuickFIX; developers QuickFIX; users QuickFIX Subject: [Quickfix-developers] QuickFIX 1.7.0 Available QuickFIX 1.7.0 is now available at the usual place: http://quickfix.thoughtworks.com/ Wait... did I say usual place. Not anymore since the fabulous Anne = Lewis over at ThoughtWorks had her way with it. She did a great job = redesigning the website. I mucked about with the formula a bit when creating the generator so if anything looks odd, it's all me. Make sure to refresh you're browsers so you don't pull up an old cache = of the site! Release notes are of course available: http://sourceforge.net/project/shownotes.php?group_id=3D37535&release_id=3D= 22112 1 What can I say? I know this one took longer than promised but I think = it is a really solid release.=20 FIX 4.4 for .NET, FreeBSD and Mac OS X, and well, just read the release notes. For java users, the package name has changed. Sorry! Release = notes explain. Seriously, if you are a Java or .NET users, it is particularly important = you read these release notes. I think this release is a milestone in that it really puts us where we = want to be for launching future initiatives. I've written a sort of summary = of where QuickFIX is and where I envision it might go in the future. It is available at the quickfix website. Please read it and give some feedback. QuickFIX is unique compared to = other engines in how open it's process is, take advantage! So many people helped on this version I don't even know where to begin. = I've tried to add everyone to the CONTRIBUTERS and THANKS files to = acknowledge their efforts. If you belong in one of these files please tell me! I = want to see everyone get appropriate credit. QuickFIX 1.6.0 was downloaded over 2000 times. We are getting record = amounts of downloads, webhits, and contributions. The companies that are using = and seriously considering QuickFIX is growing more impressive all the time. Thanks to everyone for making this project so sucessful. My hope is = that there would be a serious open alternative to the increasingly pricey fix engines associated with this "open" standard. I believe today we can say there is one. --oren __________________________________ Do you Yahoo!? Yahoo! Search - Find what you=12re looking for faster = http://search.yahoo.com ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software = kit from IBM. Click Now! http://ads.osdn.com/?ad_id=3D1356&alloc_id=3D3438&op=3Dclick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Paul B. <bee...@bt...> - 2004-03-03 09:45:33
|
Good Morning, Many thanks for the new version of quick fix. Just wondered what has happened to the TestRequest class in c++ in 4.2? Has this now been made redundant? I found no reference to it on the release notes! Many thanks again for a great product, Paul Paul Beechey Technical Architect Aitken Campbell & Company Ltd. Telephone: 01386 40282 Mobile: 07764 445867 Email: pau...@ai... IMPORTANT This email, and any attachments, contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient please note that any form of disclosure, distribution, copying or use of this email or the information in it or in any attachments is strictly prohibited and may be unlawful. If you have received this email in error, please inform Aitken Campbell by return email then delete the email and destroy any copies of it. We advise that in keeping with good computing practice the recipient of this email should ensure that it is virus free. We do not accept responsibility for any virus that may be transferred by way of this email. Email may be susceptible to data corruption, interception and unauthorised amendment, and we do not accept liability for any corruption, interception or amendment or any consequences thereof. Calls to Aitken Campbell may be recorded to assist us in improving our service to you. Aitken Campbell & Company Ltd, a subsidiary of The Toronto-Dominion Bank. Authorised and regulated by the Financial Services Authority (FSA registered number 140813), a member of The London Stock Exchange and OFEX. Registered in Scotland registration number SC97757. Registered Office: Ground Floor, 2 Central Quay, 89 Hydepark Street, Glasgow, G3 8BW. |
|
From: Oren M. <ore...@ya...> - 2004-03-03 04:47:48
|
QuickFIX 1.7.0 is now available at the usual place: http://quickfix.thoughtworks.com/ Wait... did I say usual place. Not anymore since the fabulous Anne Lewis over at ThoughtWorks had her way with it. She did a great job redesigning the website. I mucked about with the formula a bit when creating the generator so if anything looks odd, it's all me. Make sure to refresh you're browsers so you don't pull up an old cache of the site! Release notes are of course available: http://sourceforge.net/project/shownotes.php?group_id=37535&release_id=221121 What can I say? I know this one took longer than promised but I think it is a really solid release. FIX 4.4 for .NET, FreeBSD and Mac OS X, and well, just read the release notes. For java users, the package name has changed. Sorry! Release notes explain. Seriously, if you are a Java or .NET users, it is particularly important you read these release notes. I think this release is a milestone in that it really puts us where we want to be for launching future initiatives. I've written a sort of summary of where QuickFIX is and where I envision it might go in the future. It is available at the quickfix website. Please read it and give some feedback. QuickFIX is unique compared to other engines in how open it's process is, take advantage! So many people helped on this version I don't even know where to begin. I've tried to add everyone to the CONTRIBUTERS and THANKS files to acknowledge their efforts. If you belong in one of these files please tell me! I want to see everyone get appropriate credit. QuickFIX 1.6.0 was downloaded over 2000 times. We are getting record amounts of downloads, webhits, and contributions. The companies that are using and seriously considering QuickFIX is growing more impressive all the time. Thanks to everyone for making this project so sucessful. My hope is that there would be a serious open alternative to the increasingly pricey fix engines associated with this "open" standard. I believe today we can say there is one. --oren __________________________________ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com |
|
From: zyang <zy...@bl...> - 2004-03-02 19:08:31
|
We have a need to reject a logon before disconnecting. I have modified C++ source to achive that. I have some questions regarding that. 1. for version 1.6, are there anyways for us to reject with a text reason without actually modifing the libaray? The way to reject a logon described in the document is to throw a RejetLogin exception. This will cause disconnect immediately without sending a reject message. 2. If there is none, how can I contribute my changes to the quickfix. Do I support the feature in java and c#? We are using C#, so that is not a problem for me. But supporting java will be probelmatic for us. zy...@bl... (919)960-6042 x18 |
|
From: Timothy Y. <ty...@pa...> - 2004-03-02 14:48:13
|
Our code is currently based on 1.5. However I can't see any evidence that
this has been fixed in 1.6; sendRaw looks identical.
-----Original Message-----
From: Oren Miller [mailto:ore...@ya...]
Sent: Monday, March 01, 2004 10:43 PM
To: Timothy Yates; 'qui...@li...'
Subject: Re: [Quickfix-developers] Problems with Session::sendRaw().
Can I ask what version of QF you are based off of? I
ask because it looks to me like you might be running
off of a 1.5 base. Looking through the repository it
looks like some of these issues had already been
addressed in 1.6. Do you know what version you are
running?
--- Timothy Yates <ty...@pa...> wrote:
> After further analysis of problems we were
> experiencing at one of our client
> sites, it is now clear exactly what was happening.
>
> The client buy-side application lost the FIX
> connection (probably due to an
> abnormal termination of the client).
>
> After about 5 minutes, the client logged on again.
> Our sell-side
> application takes a long time to process the logon
> (about 20 seconds).
> During this time it sends any executions that
> occurred while the client was
> logged off. In the cases in point, one or two
> executions were sent.
> However, since these messages were sent before the
> logon process was
> completed, we encountered the sendRaw bug. This bug
> results in a hole in
> the message store -- a message string with zero
> length.
>
> When the client application received our logon
> reply, they noticed the
> missing executions and (correctly) ask the server to
> resend them. Since
> these were never successfully committed to the
> message store, the session
> was then broken irretrievably.
>
> Clearly, there is a questionmark over whether it
> should be legal in quickfix
> to send messages when logged out, or (as we did)
> during the logon process.
> I believe it should be possible, though clearly with
> the sendRaw bug it does
> not work in the current quickfix release.
>
> We have fixed the sendRaw bug, and the problem goes
> away. Business messages
> sent during the logon process are suppressed, but
> the client can
> successfully ask for them to be resent after the
> logon has completed.
>
> Here's our modified version of sendRaw:
>
> --------
>
> bool Session::sendRaw( Message& message, int num )
> { QF_STACK_PUSH(Session::sendRaw)
>
> Locker l( m_mutex );
>
> try
> {
> bool result = false;
> Header& header = message.getHeader();
> MsgType msgType;
> header.getField( msgType );
>
> fill( header );
> std::string messageString;
>
> if ( num )
> header.setField( MsgSeqNum( num ) );
>
> if ( Message::isAdminMsgType( msgType ) )
> {
> m_application.toAdmin( message, m_sessionID );
> if (
> msgType == "A" || msgType == "5"
> || msgType == "2" || msgType == "4"
> || isLoggedOn()
> )
> {
> result = send(
> message.toString(messageString) );
> }
> else
> {
> message.toString(messageString);
> m_state.onEvent("Suppressed send of administrative
> message:
> " + messageString);
> }
> }
> else
> {
> try
> {
> m_application.toApp( message, m_sessionID );
> if ( isLoggedOn() )
> {
> result = send( message.toString(messageString)
> );
> }
> else
> {
> message.toString(messageString);
> m_state.onEvent("Suppressed send of application
> message: "
> + messageString );
> }
> }
> catch ( DoNotSend& )
> {
> return false;
> }
> }
>
> if ( !num )
> {
> MsgSeqNum msgSeqNum;
> header.getField( msgSeqNum );
> m_state.set( msgSeqNum, messageString );
> m_state.incrNextSenderMsgSeqNum();
> }
> return result;
> }
> catch ( IOException& )
> { return false; }
>
> QF_STACK_POP
> }
>
> Tim Yates
> Lead Developer
> Patsystems (US) LLC
> 141 West Jackson Boulevard
> Chicago 60604, USA
> Tel +1 (312) 542-1336
> www.patsystems.com
>
>
> DISCLAIMER: This e-mail is confidential and may also
> be legally privileged.
> If you are not the intended recipient, use of the
> information contained in
> this e-mail (including disclosure, copying or
> distribution) is prohibited
> and may be unlawful. Please inform the sender and
> delete the message
> immediately from your system. This e-mail is
> attributed to the sender and
> may not necessarily reflect the views of the
> Patsystems Group and no member
> of the Patsystems Group accepts any liability for
> any action taken in
> reliance on the contents of this e-mail (other than
> where it has a legal or
> regulatory obligation to do so) or for the
> consequences of any computer
> viruses which may have been transmitted by this
> e-mail. The Patsystems Group
> comprises Patsystems plc and its subsidiary group of
> companies.
>
>
>
-------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps
> Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
>
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you're looking for faster
http://search.yahoo.com
DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful. Please inform the sender and delete the message
immediately from your system. This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.
|
|
From: Oren M. <ore...@ya...> - 2004-03-02 04:55:45
|
Can I ask what version of QF you are based off of? I
ask because it looks to me like you might be running
off of a 1.5 base. Looking through the repository it
looks like some of these issues had already been
addressed in 1.6. Do you know what version you are
running?
--- Timothy Yates <ty...@pa...> wrote:
> After further analysis of problems we were
> experiencing at one of our client
> sites, it is now clear exactly what was happening.
>
> The client buy-side application lost the FIX
> connection (probably due to an
> abnormal termination of the client).
>
> After about 5 minutes, the client logged on again.
> Our sell-side
> application takes a long time to process the logon
> (about 20 seconds).
> During this time it sends any executions that
> occurred while the client was
> logged off. In the cases in point, one or two
> executions were sent.
> However, since these messages were sent before the
> logon process was
> completed, we encountered the sendRaw bug. This bug
> results in a hole in
> the message store -- a message string with zero
> length.
>
> When the client application received our logon
> reply, they noticed the
> missing executions and (correctly) ask the server to
> resend them. Since
> these were never successfully committed to the
> message store, the session
> was then broken irretrievably.
>
> Clearly, there is a questionmark over whether it
> should be legal in quickfix
> to send messages when logged out, or (as we did)
> during the logon process.
> I believe it should be possible, though clearly with
> the sendRaw bug it does
> not work in the current quickfix release.
>
> We have fixed the sendRaw bug, and the problem goes
> away. Business messages
> sent during the logon process are suppressed, but
> the client can
> successfully ask for them to be resent after the
> logon has completed.
>
> Here's our modified version of sendRaw:
>
> --------
>
> bool Session::sendRaw( Message& message, int num )
> { QF_STACK_PUSH(Session::sendRaw)
>
> Locker l( m_mutex );
>
> try
> {
> bool result = false;
> Header& header = message.getHeader();
> MsgType msgType;
> header.getField( msgType );
>
> fill( header );
> std::string messageString;
>
> if ( num )
> header.setField( MsgSeqNum( num ) );
>
> if ( Message::isAdminMsgType( msgType ) )
> {
> m_application.toAdmin( message, m_sessionID );
> if (
> msgType == "A" || msgType == "5"
> || msgType == "2" || msgType == "4"
> || isLoggedOn()
> )
> {
> result = send(
> message.toString(messageString) );
> }
> else
> {
> message.toString(messageString);
> m_state.onEvent("Suppressed send of administrative
> message:
> " + messageString);
> }
> }
> else
> {
> try
> {
> m_application.toApp( message, m_sessionID );
> if ( isLoggedOn() )
> {
> result = send( message.toString(messageString)
> );
> }
> else
> {
> message.toString(messageString);
> m_state.onEvent("Suppressed send of application
> message: "
> + messageString );
> }
> }
> catch ( DoNotSend& )
> {
> return false;
> }
> }
>
> if ( !num )
> {
> MsgSeqNum msgSeqNum;
> header.getField( msgSeqNum );
> m_state.set( msgSeqNum, messageString );
> m_state.incrNextSenderMsgSeqNum();
> }
> return result;
> }
> catch ( IOException& )
> { return false; }
>
> QF_STACK_POP
> }
>
> Tim Yates
> Lead Developer
> Patsystems (US) LLC
> 141 West Jackson Boulevard
> Chicago 60604, USA
> Tel +1 (312) 542-1336
> www.patsystems.com
>
>
> DISCLAIMER: This e-mail is confidential and may also
> be legally privileged.
> If you are not the intended recipient, use of the
> information contained in
> this e-mail (including disclosure, copying or
> distribution) is prohibited
> and may be unlawful. Please inform the sender and
> delete the message
> immediately from your system. This e-mail is
> attributed to the sender and
> may not necessarily reflect the views of the
> Patsystems Group and no member
> of the Patsystems Group accepts any liability for
> any action taken in
> reliance on the contents of this e-mail (other than
> where it has a legal or
> regulatory obligation to do so) or for the
> consequences of any computer
> viruses which may have been transmitted by this
> e-mail. The Patsystems Group
> comprises Patsystems plc and its subsidiary group of
> companies.
>
>
>
-------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps
> Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
>
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
__________________________________
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
http://search.yahoo.com
|
|
From: Timothy Y. <ty...@pa...> - 2004-03-01 21:14:26
|
After further analysis of problems we were experiencing at one of our client
sites, it is now clear exactly what was happening.
The client buy-side application lost the FIX connection (probably due to an
abnormal termination of the client).
After about 5 minutes, the client logged on again. Our sell-side
application takes a long time to process the logon (about 20 seconds).
During this time it sends any executions that occurred while the client was
logged off. In the cases in point, one or two executions were sent.
However, since these messages were sent before the logon process was
completed, we encountered the sendRaw bug. This bug results in a hole in
the message store -- a message string with zero length.
When the client application received our logon reply, they noticed the
missing executions and (correctly) ask the server to resend them. Since
these were never successfully committed to the message store, the session
was then broken irretrievably.
Clearly, there is a questionmark over whether it should be legal in quickfix
to send messages when logged out, or (as we did) during the logon process.
I believe it should be possible, though clearly with the sendRaw bug it does
not work in the current quickfix release.
We have fixed the sendRaw bug, and the problem goes away. Business messages
sent during the logon process are suppressed, but the client can
successfully ask for them to be resent after the logon has completed.
Here's our modified version of sendRaw:
--------
bool Session::sendRaw( Message& message, int num )
{ QF_STACK_PUSH(Session::sendRaw)
Locker l( m_mutex );
try
{
bool result = false;
Header& header = message.getHeader();
MsgType msgType;
header.getField( msgType );
fill( header );
std::string messageString;
if ( num )
header.setField( MsgSeqNum( num ) );
if ( Message::isAdminMsgType( msgType ) )
{
m_application.toAdmin( message, m_sessionID );
if (
msgType == "A" || msgType == "5"
|| msgType == "2" || msgType == "4"
|| isLoggedOn()
)
{
result = send( message.toString(messageString) );
}
else
{
message.toString(messageString);
m_state.onEvent("Suppressed send of administrative message:
" + messageString);
}
}
else
{
try
{
m_application.toApp( message, m_sessionID );
if ( isLoggedOn() )
{
result = send( message.toString(messageString) );
}
else
{
message.toString(messageString);
m_state.onEvent("Suppressed send of application message: "
+ messageString );
}
}
catch ( DoNotSend& )
{
return false;
}
}
if ( !num )
{
MsgSeqNum msgSeqNum;
header.getField( msgSeqNum );
m_state.set( msgSeqNum, messageString );
m_state.incrNextSenderMsgSeqNum();
}
return result;
}
catch ( IOException& )
{ return false; }
QF_STACK_POP
}
Tim Yates
Lead Developer
Patsystems (US) LLC
141 West Jackson Boulevard
Chicago 60604, USA
Tel +1 (312) 542-1336
www.patsystems.com
DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful. Please inform the sender and delete the message
immediately from your system. This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.
|
|
From: Oren M. <om...@ri...> - 2004-03-01 21:04:11
|
Yes you can. FIX::Session::sendToTarget was made a static method to=20 solve this very problem, that you can't always predict when or where=20 you will want to send a message. Anytime you want to send a message=20 from anywhere in the process, you can use this call to do it. It makes=20= no difference if you are in the application interface or in an obscure=20= thread called by some wacky third party library called tibco. As long=20= as you have a sessionid or the correct routing fields are set in the=20 message header, the message will find its way to the correct client. --oren On Mar 1, 2004, at 2:14 PM, Dahl, Jon wrote: > Oren, > =A0 > You are correct in your assumptions. I will be returned the correct=20 > SenderCompId, TargetCompId, and BeginString. > =A0 > The Tibco interface will be implemented within the same process - not=20= > outside. > =A0 > My main concern is getting the message from the Tibco Callback=20 > function to the right client. Correct me if I am wrong here, but I=20 > couldn't call FIX::Session::sendToTarget()=A0from outside the=20 > Application interface could I? > =A0 > =A0 > =A0 > -----Original Message----- > From: Oren Miller [mailto:om...@ri...] > Sent: Monday, March 01, 2004 1:53 PM > To: Dahl, Jon > Cc: qui...@li... > Subject: Re: [Quickfix-developers] Tibco Rendezvous Implementation=20 > Question > > John, > > > Can you clarify the architecture? I think this is what you are doing.=20= > You have clients connecting in through QuickFIX (via socket?), who=20 > send order, you take those orders and publish them on the TIB which is=20= > picked up by you're matching engine (in FIX?), you then match the=20 > orders and publish them back, which is picked up by a process that=20 > then needs to send the matched order back to the originating clients=20= > through QuickFIX. Is this correct? > > > Now I guess the question is how you are changing the routing=20 > information when you publish to the matching engine. Essentially to=20 > send things back to the same client you will have to have the correct=20= > beginstring, sendercompid, and targetcompid. Is this information that=20= > you have lost in the transformation to the order matcher or is it=20 > still around, or can it be derived from the message in some other=20 > manner? > > > --oren > > > On Mar 1, 2004, at 10:26 AM, Dahl, Jon wrote: > > > We are going to be talking to our Matching Engine over Tibco with a > pub/sub communication mechanism. > There will be only one connection to the Tibco bus and all > requests/responses will come over that one > connection. > > > Is there anyway to inject the response messages into QuickFIX... by=20 > that > I mean making sure they go to > the correct client. Responses from the engine will be in FIX format. > > > > > Thanks, > > > JD > > > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > > > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Dahl, J. <JD...@cm...> - 2004-03-01 20:28:12
|
Oren, =20 You are correct in your assumptions. I will be returned the correct SenderCompId, TargetCompId, and BeginString. =20 The Tibco interface will be implemented within the same process - not outside. =20 My main concern is getting the message from the Tibco Callback function to the right client. Correct me if I am wrong here, but I couldn't call FIX::Session::sendToTarget() from outside the Application interface could I? =20 =20 =20 -----Original Message----- From: Oren Miller [mailto:om...@ri...]=20 Sent: Monday, March 01, 2004 1:53 PM To: Dahl, Jon Cc: qui...@li... Subject: Re: [Quickfix-developers] Tibco Rendezvous Implementation Question =09 =09 John,=20 Can you clarify the architecture? I think this is what you are doing. You have clients connecting in through QuickFIX (via socket?), who send order, you take those orders and publish them on the TIB which is picked up by you're matching engine (in FIX?), you then match the orders and publish them back, which is picked up by a process that then needs to send the matched order back to the originating clients through QuickFIX. Is this correct?=20 Now I guess the question is how you are changing the routing information when you publish to the matching engine. Essentially to send things back to the same client you will have to have the correct beginstring, sendercompid, and targetcompid. Is this information that you have lost in the transformation to the order matcher or is it still around, or can it be derived from the message in some other manner?=20 --oren=20 On Mar 1, 2004, at 10:26 AM, Dahl, Jon wrote:=20 We are going to be talking to our Matching Engine over Tibco with a=20 pub/sub communication mechanism.=20 There will be only one connection to the Tibco bus and all=20 requests/responses will come over that one=20 connection.=20 Is there anyway to inject the response messages into QuickFIX... by that=20 I mean making sure they go to=20 the correct client. Responses from the engine will be in FIX format.=20 Thanks,=20 JD=20 -------------------------------------------------------=20 SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with=20 a free DVD software kit from IBM. Click Now!=20 http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick=20 _______________________________________________=20 Quickfix-developers mailing list=20 Qui...@li...=20 =09 https://lists.sourceforge.net/lists/listinfo/quickfix-developers=20 |
|
From: Oren M. <om...@ri...> - 2004-03-01 20:05:51
|
John, Can you clarify the architecture? I think this is what you are doing. =20= You have clients connecting in through QuickFIX (via socket?), who send=20= order, you take those orders and publish them on the TIB which is=20 picked up by you're matching engine (in FIX?), you then match the=20 orders and publish them back, which is picked up by a process that then=20= needs to send the matched order back to the originating clients through=20= QuickFIX. Is this correct? Now I guess the question is how you are changing the routing=20 information when you publish to the matching engine. Essentially to=20 send things back to the same client you will have to have the correct=20 beginstring, sendercompid, and targetcompid. Is this information that=20= you have lost in the transformation to the order matcher or is it still=20= around, or can it be derived from the message in some other manner? --oren On Mar 1, 2004, at 10:26 AM, Dahl, Jon wrote: > We are going to be talking to our Matching Engine over Tibco with a > pub/sub communication mechanism. > There will be only one connection to the Tibco bus and all > requests/responses will come over that one > connection. > > Is there anyway to inject the response messages into QuickFIX... by=20 > that > I mean making sure they go to > the correct client. Responses from the engine will be in FIX format. > > > > Thanks, > > JD > > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Dahl, J. <JD...@cm...> - 2004-03-01 16:40:13
|
We are going to be talking to our Matching Engine over Tibco with a pub/sub communication mechanism. There will be only one connection to the Tibco bus and all requests/responses will come over that one connection. Is there anyway to inject the response messages into QuickFIX... by that I mean making sure they go to=20 the correct client. Responses from the engine will be in FIX format. Thanks, JD |
|
From: Oren M. <ore...@ya...> - 2004-03-01 02:36:31
|
Heri,
I checked this in, though I made a couple of
modifications.
The reverseRoute method now throws a FieldNotFound
exception. This is for if any of the required routing
fields (BeginString, SenderCompID, TargetCompID) are
not present. I did this so someone doesn't reverse
the route on a message which is missing a critical
field causing the message to go to some potentially
unexpected destination. For most cases this doesn't
matter since every message coming out of a session is
guaranteed to have these fields.
I also wrote a unit test for this method which
revealed a bug. The value of OnBehalfOfCompID, not
OnBehalfOfSubID was being placed into the
DeliverToSubID. This was fixed.
Thank you for the contribution, this is a great
feature.
--oren
--- "H. Steuer" <st...@st...> wrote:
> Hello,
>
> regarding to my post from 04/02/17 and Orens
> suggestions I finally had time to wrap stuff into a
> method. Attached you find a diff against Message.cpp
> and Message.h that adds a method called
> "reverseRoute".
>
>
> This method prepares a FIX::Message object and adds
> BeginString, SenderCompID, TargetCompID,
> OnBehalfOfCompID, DeliverToCompID, OnBehalfOfSubID
> and DeliverToSubID tags to the message header
> depending on an underlying message header.
>
> Using that method you can do something like :
>
> fromApp(Message foo , SessionID sessionID )
> {
> Message back;
> back.reverseRoute( foo.getHeader() );
> /* add your payload here */
> Session::sendToTarget( back );
> }
>
> ... which then will get routed correctly to your
> peer.
>
> Additionally I've added the new patches to
> Session.cpp which now use reverseRoute() to add
> routing tags to session level reject messages.
>
>
> Oren, please let me know if that stuff and the small
> patch to SocketConnection.cpp i posted on 04/02/18
> will go into the tree.
> Otherwise I'll keep the patches in a local
> repository.
>
>
>
>
> Kind regards,
> Heri
> --
> This e-mail may contain confidential and/or
> privileged information.
> If you are not the intended recipient (or have
> received this e-mail in error)
> please notify the sender immediately and destroy
> this e-mail. Any unauthorized
> copying, disclosure or distribution of the material
> in this e-mail is strictly
> forbidden.
>
> ATTACHMENT part 2 application/octet-stream
name=Session.patch
> ATTACHMENT part 3 application/octet-stream
name=Message.patch
__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools
|
|
From: H. S. <st...@st...> - 2004-02-29 21:15:53
|
Hello,
regarding to my post from 04/02/17 and Orens suggestions I finally had time to wrap stuff into a method. Attached you find a diff against Message.cpp and Message.h that adds a method called "reverseRoute".
This method prepares a FIX::Message object and adds BeginString, SenderCompID, TargetCompID, OnBehalfOfCompID, DeliverToCompID, OnBehalfOfSubID and DeliverToSubID tags to the message header depending on an underlying message header.
Using that method you can do something like :
fromApp(Message foo , SessionID sessionID )
{
Message back;
back.reverseRoute( foo.getHeader() );
/* add your payload here */
Session::sendToTarget( back );
}
... which then will get routed correctly to your peer.
Additionally I've added the new patches to Session.cpp which now use reverseRoute() to add routing tags to session level reject messages.
Oren, please let me know if that stuff and the small patch to SocketConnection.cpp i posted on 04/02/18 will go into the tree.
Otherwise I'll keep the patches in a local repository.
Kind regards,
Heri
--
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
|
|
From: Timothy Y. <ty...@pa...> - 2004-02-27 20:01:24
|
After further analysis of problems we were experiencing at one of our client
sites, it is now clear exactly what was happening.
The client buy-side application lost the FIX connection (probably due to an
abnormal termination of the client).
After about 5 minutes, the client logged on again. Our sell-side
application takes a long time to process the logon (about 20 seconds).
During this time it sends any executions that occurred while the client was
logged off. In the cases in point, one or two executions were sent.
However, since these messages were sent before the logon process was
completed, we encountered the sendRaw bug. This bug results in a hole in
the message store -- a message string with zero length.
When the client application received our logon reply, they noticed the
missing executions and (correctly) ask the server to resend them. Since
these were never successfully committed to the message store, the session
was then broken irretrievably.
Clearly, there is a questionmark over whether it should be legal in quickfix
to send messages when logged out, or (as we did) during the logon process.
I believe it should be possible, though clearly with the sendRaw bug it does
not work in the current quickfix release.
We have fixed the sendRaw bug, and the problem goes away. Business messages
sent during the logon process are suppressed, but the client can
successfully ask for them to be resent after the logon has completed.
Here's our modified version of sendRaw:
--------
bool Session::sendRaw( Message& message, int num )
{ QF_STACK_PUSH(Session::sendRaw)
Locker l( m_mutex );
try
{
bool result = false;
Header& header = message.getHeader();
MsgType msgType;
header.getField( msgType );
fill( header );
std::string messageString;
if ( num )
header.setField( MsgSeqNum( num ) );
if ( Message::isAdminMsgType( msgType ) )
{
m_application.toAdmin( message, m_sessionID );
if (
msgType == "A" || msgType == "5"
|| msgType == "2" || msgType == "4"
|| isLoggedOn()
)
{
result = send( message.toString(messageString) );
}
else
{
message.toString(messageString);
m_state.onEvent("Suppressed send of administrative message:
" + messageString);
}
}
else
{
try
{
m_application.toApp( message, m_sessionID );
if ( isLoggedOn() )
{
result = send( message.toString(messageString) );
}
else
{
message.toString(messageString);
m_state.onEvent("Suppressed send of application message: "
+ messageString );
}
}
catch ( DoNotSend& )
{
return false;
}
}
if ( !num )
{
MsgSeqNum msgSeqNum;
header.getField( msgSeqNum );
m_state.set( msgSeqNum, messageString );
m_state.incrNextSenderMsgSeqNum();
}
return result;
}
catch ( IOException& )
{ return false; }
QF_STACK_POP
}
--------
-----Original Message-----
From: Miller, Oren [mailto:OM...@ri...]
Sent: Friday, February 27, 2004 9:36 AM
To: Timothy Yates; qui...@li...
Cc: William Todd; Lenny Shleymovich
Subject: RE: [Quickfix-developers] Bug in Session::sendRaw.
I think what we have to determine is whether it is acceptable to send a
logout if a valid logon hasn't been recieved. I'm not sure that it is, I
think this is a good question to post at fixprotocol.org
--oren
-----Original Message-----
From: Timothy Yates [mailto:ty...@pa...]
Sent: Thu 2/26/2004 10:53 AM
To: 'qui...@li...'
Cc: William Todd; Lenny Shleymovich
Subject: [Quickfix-developers] Bug in Session::sendRaw.
There is an bug in Session::sendRaw, which may cause a sequence number to be
consumed without any message actually being sent.
For example, session-level reject messages are not sent if the session is
not logged in. In such cases, an empty message (empty string) is committed
to the message store and the outbound sequence number is incremented. This
causes the session to be irretrievably broken. If the client asks for the
missing message, an exception is thrown on attempting to parse the empty
message from the message store. In the current quickfix release, this will
cause the client's resend request to be ignored.
The attached acceptance test definition illustrates this problem by sending
a logon message with a bad sending time. This seems like a slightly
artificial test case. However, we have seen a large number of instances of
this problem which were caused by something other than bad sending time. We
are still trying to ascertain exactly which outbound messages were being
suppressed.
I am not certain what the correct behaviour should be for this test case.
Should the reject still be sent, or should it be suppressed? I think it
should be suppressed because the normal way to reject a logon is either with
a logout or a disconnect. Ideally, the logout text should include the
reason for the problem (i.e. sending time inaccuracy), otherwise it could be
very difficult for the client to ascertain.
<<5000_STA.def>>
Tim Yates
Lead Developer
Patsystems (US) LLC
141 West Jackson Boulevard
Chicago 60604, USA
Tel +1 (312) 542-1336
www.patsystems.com
DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful. Please inform the sender and delete the message
immediately from your system. This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.
DISCLAIMER: This e-mail is confidential and may also be legally privileged.
If you are not the intended recipient, use of the information contained in
this e-mail (including disclosure, copying or distribution) is prohibited
and may be unlawful. Please inform the sender and delete the message
immediately from your system. This e-mail is attributed to the sender and
may not necessarily reflect the views of the Patsystems Group and no member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems Group
comprises Patsystems plc and its subsidiary group of companies.
|
|
From: Miller, O. <OM...@ri...> - 2004-02-27 16:10:11
|
Looks like pretty much this exact question was just addressed in the = forum = (http://www.fixprotocol.org/cgi-bin/BBS.cgi?menu=3D710&board=3D1&message=3D= 3110&thread=3D3109). Essentially either disconnecting or sending a logout is valid, however = disconnecting is considered more stable, while logging out is clearly = more informative. It seems to me that the configuration file should = give a session the choice how it wants to handle these situations. Currently disconnects are handled when an std::exception is thrown in = the Session, which results in a call to disconnect. If we start putting = text into these exceptions, we can have the session use it to label the = logout reason and send it if the session is setup for this behavior. -----Original Message----- From: Timothy Yates [mailto:ty...@pa...] Sent: Thu 2/26/2004 10:53 AM To: 'qui...@li...' Cc: William Todd; Lenny Shleymovich Subject: [Quickfix-developers] Bug in Session::sendRaw. There is an bug in Session::sendRaw, which may cause a sequence number = to be consumed without any message actually being sent. For example, session-level reject messages are not sent if the session = is not logged in. In such cases, an empty message (empty string) is = committed to the message store and the outbound sequence number is incremented. = This causes the session to be irretrievably broken. If the client asks for = the missing message, an exception is thrown on attempting to parse the empty message from the message store. In the current quickfix release, this = will cause the client's resend request to be ignored. The attached acceptance test definition illustrates this problem by = sending a logon message with a bad sending time. This seems like a slightly artificial test case. However, we have seen a large number of instances = of this problem which were caused by something other than bad sending time. = We are still trying to ascertain exactly which outbound messages were being suppressed. I am not certain what the correct behaviour should be for this test = case. Should the reject still be sent, or should it be suppressed? I think it should be suppressed because the normal way to reject a logon is either = with a logout or a disconnect. Ideally, the logout text should include the reason for the problem (i.e. sending time inaccuracy), otherwise it = could be very difficult for the client to ascertain. <<5000_STA.def>>=20 Tim Yates Lead Developer=20 Patsystems (US) LLC=20 141 West Jackson Boulevard Chicago 60604, USA=20 Tel +1 (312) 542-1336=20 www.patsystems.com=20 DISCLAIMER: This e-mail is confidential and may also be legally = privileged. If you are not the intended recipient, use of the information contained = in this e-mail (including disclosure, copying or distribution) is = prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender = and may not necessarily reflect the views of the Patsystems Group and no = member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal = or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems = Group comprises Patsystems plc and its subsidiary group of companies. |
|
From: Miller, O. <OM...@ri...> - 2004-02-27 15:46:14
|
I think what we have to determine is whether it is acceptable to send a = logout if a valid logon hasn't been recieved. I'm not sure that it is, = I think this is a good question to post at fixprotocol.org --oren -----Original Message----- From: Timothy Yates [mailto:ty...@pa...] Sent: Thu 2/26/2004 10:53 AM To: 'qui...@li...' Cc: William Todd; Lenny Shleymovich Subject: [Quickfix-developers] Bug in Session::sendRaw. There is an bug in Session::sendRaw, which may cause a sequence number = to be consumed without any message actually being sent. For example, session-level reject messages are not sent if the session = is not logged in. In such cases, an empty message (empty string) is = committed to the message store and the outbound sequence number is incremented. = This causes the session to be irretrievably broken. If the client asks for = the missing message, an exception is thrown on attempting to parse the empty message from the message store. In the current quickfix release, this = will cause the client's resend request to be ignored. The attached acceptance test definition illustrates this problem by = sending a logon message with a bad sending time. This seems like a slightly artificial test case. However, we have seen a large number of instances = of this problem which were caused by something other than bad sending time. = We are still trying to ascertain exactly which outbound messages were being suppressed. I am not certain what the correct behaviour should be for this test = case. Should the reject still be sent, or should it be suppressed? I think it should be suppressed because the normal way to reject a logon is either = with a logout or a disconnect. Ideally, the logout text should include the reason for the problem (i.e. sending time inaccuracy), otherwise it = could be very difficult for the client to ascertain. <<5000_STA.def>>=20 Tim Yates Lead Developer=20 Patsystems (US) LLC=20 141 West Jackson Boulevard Chicago 60604, USA=20 Tel +1 (312) 542-1336=20 www.patsystems.com=20 DISCLAIMER: This e-mail is confidential and may also be legally = privileged. If you are not the intended recipient, use of the information contained = in this e-mail (including disclosure, copying or distribution) is = prohibited and may be unlawful. Please inform the sender and delete the message immediately from your system. This e-mail is attributed to the sender = and may not necessarily reflect the views of the Patsystems Group and no = member of the Patsystems Group accepts any liability for any action taken in reliance on the contents of this e-mail (other than where it has a legal = or regulatory obligation to do so) or for the consequences of any computer viruses which may have been transmitted by this e-mail. The Patsystems = Group comprises Patsystems plc and its subsidiary group of companies. |
|
From: Howard E. <ho...@ex...> - 2004-02-27 13:13:12
|
Using qf 1.6.0.. I am trying to set up some scripts to archive + manage my fix session logs. I have noticed that if deleted the following files will be auto re-created by the qf library without requiring a re-start of my app: FIX.4.2-SBI0-SLGM0.body FIX.4.2-SBI0-SLGM0.header FIX.4.2-SBI0-SLGM0.seqnums FIX.4.2-SBI0-SLGM0.session However these files are not regenerated: FIX.4.2-SBI0-SLGM0.event FIX.4.2-SBI0-SLGM0.incoming FIX.4.2-SBI0-SLGM0.outgoing Is there a way that the .event, .incoming, .outgoing logs can be reset without having to restart my application? I am using the StartTime/EndTime settings in the config, does not seem to make much of a difference. Thanks, Howard |
|
From: Oren M. <ore...@ya...> - 2004-02-27 01:34:56
|
There's been occasional reports of this, but no ones demonstrated a repeatable system for making it appear. It would be great if you would check out the latest from the repository and verify if the problem still exists there. If not then good, if so then a description of you're testing scenario would be very helpful. Checkout instructions through anonymous CVS are available here: http://sourceforge.net/cvs/?group_id=37535 --oren --- Steve Smith <ss...@4t...> wrote: > Hi, > > In doing some stress testing with a lot of order > flow which was maxing the > CPU out, I noticed we were getting a few duplicate > MsgSeqNums. Has anyone > else seen this behavior? > > Also, the version of QuickFIX we are using is 1.6 > which was downloaded in > Nov 2003. Have there been any fixes since then? > > Thanks > > Steve Smith > > __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools |
|
From: Steve S. <ss...@4t...> - 2004-02-27 01:20:54
|
Hi, In doing some stress testing with a lot of order flow which was maxing the CPU out, I noticed we were getting a few duplicate MsgSeqNums. Has anyone else seen this behavior? Also, the version of QuickFIX we are using is 1.6 which was downloaded in Nov 2003. Have there been any fixes since then? Thanks Steve Smith |
|
From: James C. D. <jc...@co...> - 2004-02-26 22:31:38
|
PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjY0ODcuMSI+CjxUSVRMRT5bUXVpY2tmaXgtZGV2ZWxv cGVyc10gUHVyZSBKYXZhIFZlcnNpb248L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxE SVY+VmFtc2ksPC9ESVY+CjxESVY+VGhpcyBoYXMgYmVlbiB0YWxrZWQgYWJvdXQgZm9yIGEgd2hp bGUgbm93LCBidXQgbm90IHRvIG15IGtub3dsZWRnZSBoYXMgCmFueW9uZSBzdGVwcGVkIHVwIHRv IHVuZGVydGFrZSB0aGUgZWZmb3J0LiBIYXZpbmcgdGhlIGFjY2VwdGFuY2UgdGVzdHMgYW5kIHRo ZSAKdGVzdCBydW5uZXIgd291bGQgZ2l2ZSBhIG5pY2UganVtcCBzdGFydCB0byB0aGUgcHJvamVj dC48L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5KaW08L0RJVj4KPEJMT0NLUVVPVEUgZGly PWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPgogIDxESVY+PEZPTlQgc2l6ZT0yPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxCUj48Qj5Gcm9tOjwvQj4gCiAgcXVpY2tmaXgtZGV2ZWxv cGVycy1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQmbmJzcDtvbiBiZWhhbGYgb2YmbmJzcDtW YW1zaSAKICBLcmlzaG5hIDxCUj48Qj5TZW50OjwvQj4gVGh1IDIvMjYvMjAwNCA0OjA0IFBNIDxC Uj48Qj5Ubzo8L0I+ICdNaWxsZXIsIE9yZW4nOyAKICBxdWlja2ZpeC1kZXZlbG9wZXJzQGxpc3Rz LnNvdXJjZWZvcmdlLm5ldCA8QlI+PEI+Q2M6PC9CPiA8QlI+PEI+U3ViamVjdDo8L0I+IAogIFtR dWlja2ZpeC1kZXZlbG9wZXJzXSBQdXJlIEphdmEgVmVyc2lvbjxCUj48QlI+PC9GT05UPjwvRElW PjxCUj4KICA8UD48Rk9OVCBzaXplPTI+T3JlbjxCUj5JcyB0aGVyZSBhbiBlZmZvcnQgdG8gYnJp bmcgb3V0IHB1cmUgamF2YSB2ZXJzaW9uIG9mIAogIGZpeGVuZ2luZT88QlI+PEJSPjxCUj5UaGFu a3M8QlI+VmFtc2k8QlI+PEJSPjxCUj48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj5TRi5OZXQgCiAgaXMgc3BvbnNvcmVkIGJ5OiBT cGVlZCBTdGFydCBZb3VyIExpbnV4IEFwcHMgTm93LjxCUj5CdWlsZCBhbmQgZGVwbG95IGFwcHMg CiAgJmFtcDsgV2ViIHNlcnZpY2VzIGZvciBMaW51eCB3aXRoPEJSPmEgZnJlZSBEVkQgc29mdHdh cmUga2l0IGZyb20gSUJNLiBDbGljayAKICBOb3chPEJSPjxBIAogIGhyZWY9Imh0dHA6Ly9hZHMu b3Nkbi5jb20vP2FkX2lkPTEzNTYmYW1wO2FsbG9jX2lkPTM0MzgmYW1wO29wPWNsaWNrIj5odHRw Oi8vYWRzLm9zZG4uY29tLz9hZF9pZD0xMzU2JmFtcDthbGxvY19pZD0zNDM4JmFtcDtvcD1jbGlj azwvQT48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+UXVpY2tmaXgtZGV2ZWxvcGVycyAKICBtYWlsaW5nIGxpc3Q8QlI+UXVpY2tmaXgtZGV2ZWxv cGVyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ8QlI+PEEgCiAgaHJlZj0iaHR0cHM6Ly9saXN0cy5z b3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxvcGVycyI+aHR0cHM6 Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxvcGVy czwvQT48QlI+PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= |
98 messages has been excluded from this view by a project administrator.
