quickfix-developers Mailing List for QuickFIX (Page 203)
Brought to you by:
orenmnero
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: Joerg T. <Joe...@ma...> - 2005-05-31 08:54:17
|
Hi Heri,
> I just encountered an interesting thing with quickfix which is not on FIX protocol
> layer but TCP. we configured 3 counterparts in our settings file and quickfix tries to
> connect to them. if one of those counterparts filters and drops the TCP connection (no
> RST in reply to our SYN), quickfix is waiting and the other connections either dont get
> established or go down with "waiting for heartbeat message".
>
> i was yet not looking into the quickfix code but i assume its a problem with the engine
> not trying to set up connections in parallel - or maybe not having any timeout for
> opening net connections.
Actually this depends on which Initiator you use: if you use the ThreadedSocketInitiator,
every connection is setup in parallel in a separate thread: See the method doConnect()
in src/C++/ThreadedSocketInitiator.cpp. If you just use SocketInitiator, the method
doConnect() does the connection setup one by one.
So if you currently use SocketInitiator, please replace it by the threaded version and
give it another try.
If you are already using ThreadedSocketInitiator, then there may be another problem.
Anyway, I would give 1.9.4 a try.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: H. S. <st...@un...> - 2005-05-30 14:35:54
|
hi guys, I just encountered an interesting thing with quickfix which is not on FIX protocol layer but TCP. we configured 3 counterparts in our settings file and quickfix tries to connect to them. if one of those counterparts filters and drops the TCP connection (no RST in reply to our SYN), quickfix is waiting and the other connections either dont get established or go down with "waiting for heartbeat message". i was yet not looking into the quickfix code but i assume its a problem with the engine not trying to set up connections in parallel - or maybe not having any timeout for opening net connections. the problem with that is that counterparts can bring down other FIX connections by just ignoring SYN packets from us. did one of you guys ever see any similar problem? regards, heri p.s.: this is quickfix 1.9.2 on FreeBSD 5.3. Im just installing 1.9.4 for testing. -- 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: Alexey Z. <ale...@in...> - 2005-05-27 19:10:43
|
Hello, Sorry, my previous two mails were sent in a wrong format. So, I have two questions: 1. I want to run two fix servers (two acceptors) or two clients (two initiators) in one application (VC6). Are there know issues (like static objects) in quickfix? 2. I need to send a binary data in a message and I put RawDataLength and RawData fields. But sometimes I have a 'Could not convert field' exception during sending of the message. Is there a limitation on data (I mean is RawData can have ASCII characters < 128) or is there a known problem in quickfix? Thank you in advance. -- Regards, Alexey Zubko |
|
From: Alexey Z. <ale...@in...> - 2005-05-27 17:21:52
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000066"> <br> Hello,<br> <br> I want to run two fix servers (two acceptors) in one application (VC6).<br> Are there know issues (like static objects) in quickfix?<br> <br> Thank you in advance.<br> <br> Regards, Alexey.<br> </body> </html> |
|
From: Alexey Z. <ale...@in...> - 2005-05-27 17:15:19
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000066"> <br> Hello,<br> <br> I need to send a binary data in a message and I put RawDataLength and RawData fields.<br> But sometimes I have a 'Could not convert field' exception during sending of the message.<br> Is there a limitation on data or is there a known problem in quickfix?<br> <br> Thank you.<br> <br> </body> </html> |
|
From: Michael H. <mh...@li...> - 2005-05-27 16:39:18
|
Is there an example somewhere on how to implement this? Is it even possible? I use the C++ API in 1.9.4. =20 Thanks Michael Holm Liquid Capital Markets Ltd 11 Old Jewry London EC2R 8DU Tel:020 7726 3028 =20 |
|
From: Caleb E. <cal...@gm...> - 2005-05-26 16:35:10
|
On 5/26/05, Ananth <ans...@sp...> wrote: > I need the "OrderServer" to support many clients.............For this wha= t > we should specify in the settings file=20 You just put multiple [SESSION] sections, one for each client. Each one should have a unique SenderCompID/TargetCompID pair (broadly speaking) For example: [DEFAULT] <default settings here> [SESSION] BeginString=3DFIX.4.2 SenderCompID=3DTW TargetCompID=3DCLIENT1 [SESSION] BeginString=3DFIX.4.2 SenderCompID=3DTW TargetCompID=3DCLIENT2 --=20 Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Ananth <ans...@sp...> - 2005-05-26 16:20:47
|
<html>=0D <BR> <BR> <B><BR> </B>=0D <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: = 10pt; FONT-FAMILY: Arial">Hi,</SPAN></FONT><FONT face=3DArial size=3D2><SPA= N style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"> </SPAN></FONT></P>=0D <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: = 10pt; FONT-FAMILY: Arial">I am new to QuickFixEngine. I am developin an app= lication that is based on FIX4.2 protocol.<BR> </SPAN></FONT><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; F= ONT-FAMILY: Arial">I have studied QuickFix Docs and tried to run the Exampl= e Apllication =93TradeClient" and "OrderServer""</SPAN></FONT></P>=0D <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: = 10pt; FONT-FAMILY: Arial">I need the "OrderServer" to support many clients.= ............For this what we should specify in the settings file</SPAN></FO= NT></P>=0D <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: = 10pt; FONT-FAMILY: Arial">I mean how to sepcify many "TargetCompId" in sing= le file itself?</SPAN></FONT></P>=0D <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: = 10pt; FONT-FAMILY: Arial">Could anyone throw some light on it</SPAN></FONT>= <FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Ar= ial"> </SPAN></FONT></P>=0D <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: = 10pt; FONT-FAMILY: Arial">Thanks in Advance,<BR> </SPAN></FONT><FONT face=3DArial size=3D2><SPAN style=3D"FONT-SIZE: 10pt; F= ONT-FAMILY: Arial">Ananth</SPAN></FONT></P>=0D <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN style=3D= "FONT-SIZE: 12pt"></SPAN></FONT> </P><BR> =0D </html><BR> |
|
From: Guillermo A. A. <gar...@vi...> - 2005-05-25 06:46:17
|
CkhpIGd1eXMKCkkgdGhpbmsgZm9yIHlvdXIgbmVlZHMgQUNFIGlzIHRoZSBiZXN0IGNob2ljZS4g U3VyZSBpdCBoYXMgYSByb3VnaCBsZWFybmluZwpjdXJ2ZSwgYnV0IG9uY2UgeW91IG1hbmFnZSB3 aXRoIGl0LCBpcyB3b3J0aCB0aGUgZWZmb3J0LgoKR3VpbGxlcm1vLgoKLS0tLS1NZW5zYWplIG9y aWdpbmFsLS0tLS0KRGU6IHF1aWNrZml4LWRldmVsb3BlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9y Z2UubmV0ClttYWlsdG86cXVpY2tmaXgtZGV2ZWxvcGVycy1hZG1pbkBsaXN0cy5zb3VyY2Vmb3Jn ZS5uZXRdRW4gbm9tYnJlIGRlCkFudG9uaW8gQ2Fyb3NlbGxpCkVudmlhZG8gZWw6IG1p6XJjb2xl cywgMjUgZGUgbWF5byBkZSAyMDA1IDA6MTgKUGFyYTogQ2FsZWIgRXBzdGVpbjsgcXVpY2tmaXgt ZGV2ZWxvcGVyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQ7IFBhc3F1YWxlCmQnQWxvaXNlCkFzdW50 bzogUmU6IFtRdWlja2ZpeC1kZXZlbG9wZXJzXSBPcGVuLXNvdWNlIHBvcnRhYmxlIGxpYnJhcmll cyBmb3IKdGhyZWFkIG1hbmFnZW1lbnQKCgpRdWlja0ZJWCBEb2N1bWVudGF0aW9uOgpodHRwOi8v d3d3LnF1aWNrZml4ZW5naW5lLm9yZy9xdWlja2ZpeC9kb2MvaHRtbC9pbmRleC5odG1sClF1aWNr RklYIEZBUTogaHR0cDovL3d3dy5xdWlja2ZpeGVuZ2luZS5vcmcvd2lraWZpeC9pbmRleC5waHA/ UXVpY2tGaXhGQVEKUXVpY2tGSVggU3VwcG9ydDogaHR0cDovL3d3dy5xdWlja2ZpeGVuZ2luZS5v cmcvc2VydmljZXMuaHRtbAoKRGVhciBDYWxlYiwKCk9mIGNvdXJzZSwgd2UgdW5kZXJzdGFuZCB0 aGF0IHRoZSB0aHJlYWRpbmcgYW5kIHN5bmNocm9uaXphdGlvbgpwcmltaXRpdmVzIGluIFF1aWNr RklYIHdvcmsgZmluZSBvbiBtYW55IHBsYXRmb3Jtcy4gQW55d2F5IHRoZSBzZXJ2aWNlCnRoYXQg d2Ugd2FudCB0byBkZXNpZ24gYW5kIGltcGxlbWVudCB3aWxsIGVtYmVkIHRoZSBRdWlja0ZpeCBs aWJyYXJ5LApidXQgaXQgd2lsbCByZXF1aXJlIEEgTE9UIE1PUkUgb2YgbXVsdGl0aHJlYWRpbmcg Y29kZSBmb3Igb3VyIG93bgpwdXJwb3Nlcy4gU28gd2Ugd2lsbCBOT1QgY2hhbmdlIHRoZSBRdWlj a0ZpeCBsaWJyYXJ5IGF0IGFsbC4gV2Ugc2ltcGx5Cm5lZWQgdG8gd3JhcCBpdCBpbiBhIGxhcmdl IGFwcGxpY2F0aW9uIHdoaWNoIG5lZWRzIGJlIHdyaXR0ZW4uIEZvcgp0aGlzIG5ldyBwYXJ0IG9m IFNXIHdlIGFyZSB0cnlpbmcgdG8gbG9jYXRlIHRoZSBiZXN0IG9wZW4tc291cmNlCnBvcnRhYmxl IGxpYnJhcnkgdG8gaGFuZGxlIG11bHRpdGhyZWFkaW5nIGluIGEgd2F5IHRoYXQgd2lsbCBtYWtl IGl0CmVhc3kgdG8gY3JlYXRlIFNXIGZvciBXaW5kb3dzIDIwMDAsIFNVTiBTb2xhcmlzLCBMaW51 eCwgLi4uIC4KCkFnYWluLCB0aGFuayB5b3UgZm9yIHlvdXIgY29udHJpYnV0aW9uLgoKQnllLAoK QW50b25pbyBDYXJvc2VsbGkKR0FURSBUZWNub2xvZ2llIEluZm9ybWF0aWNoZSBTLnIubC4KCgoK PiBRdWlja0ZJWCBEb2N1bWVudGF0aW9uOgpodHRwOi8vd3d3LnF1aWNrZml4ZW5naW5lLm9yZy9x dWlja2ZpeC9kb2MvaHRtbC9pbmRleC5odG1sCj4gUXVpY2tGSVggRkFROiBodHRwOi8vd3d3LnF1 aWNrZml4ZW5naW5lLm9yZy93aWtpZml4L2luZGV4LnBocD8KUXVpY2tGaXhGQVEKPiBRdWlja0ZJ WCBTdXBwb3J0OiBodHRwOi8vd3d3LnF1aWNrZml4ZW5naW5lLm9yZy9zZXJ2aWNlcy5odG1sCj4K PiBPbiA1LzI0LzA1LCBBbnRvbmlvIENhcm9zZWxsaSA8YW50b25pby5jYXJvc2VsbGlAZ2F0ZWxh Yi5jb20+IHdyb3RlOgo+Cj4gPiBXZSB3YW50IHRvIGRlc2lnbiBhbmQgaW1wbGVtZW50IGFuIE9N UyBlbWJlZGRpbmcgUXVpY2tGaXgsIGJ1dCBhbHNvCj4gPiBpbXBsZW1lbnRpbmcgYSBjb21wbGV4 IGxvZ2l4IGZvciBvcmRlciBoYW5kbGluZy4gVGhlcmVmb3JlIHdlCnNoYWxsIG5lZWQgdG8KPiA+ IHJlbHkgb24gdGhyZWFkIG1nbXQuIGFuZCB0aGF0J3Mgd2h5IHdlIHdlcmUgYXNraW5nIHdoaWNo IGFyZSB0aGUKYmVzdCAoaS5lLgo+ID4gbW9zdCByb2J1c3QpIG9wZW4tc291cmNlIHBvcnRhYmxl IGxpYnJhcmllcyBpbiBvcmRlciB0byB3cml0ZSBhCnNpbmdsZQo+ID4gYXBwbGljYXRpb24gcnVu bmluZyB1bmRlciBXaW5kb3dzLCBMaW51eCwgU1VOIFNvbGFyaXMuCj4KPiBUaGUgdGhyZWFkaW5n IGFuZCBzeW5jaHJvbml6YXRpb24gcHJpbWl0aXZlcyBpbiBRdWlja0ZJWCB3b3JrIGZpbmUgb24K PiBhbGwgb2YgdGhlc2UgcGxhdGZvcm1zLCBidXQgSWYgeW91IHdhbnQgc29tZXRoaW5nIHdpdGgg bW9yZSBiZWxscyBhbmQKPiB3aGlzdGxlcywgSSdkIHJlY29tbWVuZCBBQ0UuCj4KPiAtLQo+IENh bGViIEVwc3RlaW4KPiBjYWxlYiBkb3QgZXBzdGVpbiBhdCBnbWFpbCBkb3QgY29tCj4KPgo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiBU aGlzIFNGLk5ldCBlbWFpbCBpcyBzcG9uc29yZWQgYnkgWWFob28uCj4gSW50cm9kdWNpbmcgWWFo b28hIFNlYXJjaCBEZXZlbG9wZXIgTmV0d29yayAtIENyZWF0ZSBhcHBzIHVzaW5nCllhaG9vIQo+ IFNlYXJjaCBBUElzIEZpbmQgb3V0IGhvdyB5b3UgY2FuIGJ1aWxkIFlhaG9vISBkaXJlY3RseSBp bnRvIHlvdXIgb3duCj4gQXBwbGljYXRpb25zIC0gdmlzaXQgaHR0cDovL2RldmVsb3Blci55YWhv by5uZXQvP2ZyPW9mZmFkLXlzZG4tb3N0Zy0KcTIyMDA1Cj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBRdWlja2ZpeC1kZXZlbG9wZXJzIG1haWxpbmcg bGlzdAo+IFF1aWNrZml4LWRldmVsb3BlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gaHR0cHM6 Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vcXVpY2tmaXgtZGV2ZWxvcGVy cwo+Cj4KCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KVGhpcyBTRi5OZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5IFlhaG9vLgpJbnRyb2R1 Y2luZyBZYWhvbyEgU2VhcmNoIERldmVsb3BlciBOZXR3b3JrIC0gQ3JlYXRlIGFwcHMgdXNpbmcg WWFob28hClNlYXJjaCBBUElzIEZpbmQgb3V0IGhvdyB5b3UgY2FuIGJ1aWxkIFlhaG9vISBkaXJl Y3RseSBpbnRvIHlvdXIgb3duCkFwcGxpY2F0aW9ucyAtIHZpc2l0IGh0dHA6Ly9kZXZlbG9wZXIu eWFob28ubmV0Lz9mcj1vZmZhZC15c2RuLW9zdGctcTIyMDA1Cl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fClF1aWNrZml4LWRldmVsb3BlcnMgbWFpbGluZyBs aXN0ClF1aWNrZml4LWRldmVsb3BlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0Cmh0dHBzOi8vbGlz dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3F1aWNrZml4LWRldmVsb3BlcnMKCgoq KioKCgoKKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIEFWSVNPIExFR0FMICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKgoKTGEgaW5mb3JtYWNp824gY29udGVuaWRhIGVuIGVzdGUg bWVuc2FqZSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgc3UgZGVzdGluYXRhcmlvLiBObyBkZWJl IGNvcGlhcnNlLCB0cmFuc21pdGlyc2UgYSB0ZXJjZXJvcyBuaSBndWFyZGFyc2UgcG9yIGVzdG9z IPpsdGltb3MsIHNhbHZvIGF1dG9yaXphY2nzbiBkZWwgcmVtaXRlbnRlLgoKUHVlZGUgY29udGVu ZXIgaW5mb3JtYWNp824gY29uZmlkZW5jaWFsIG8gbGVnYWxtZW50ZSBwcm90ZWdpZGEgY3V5byBy 6WdpbWVuIGxlZ2FsIGRlIHV0aWxpemFjafNuIG5vIHNlIHZlIGFmZWN0YWRvIHBvciBlbCBoZWNo byBkZSBxdWUgaGF5YSBzaWRvIGVudmlhZGEgcG9yIGNvcnJlbyBlbGVjdHLzbmljby4KClN1IGVu du1vIHBvciBlcnJvciBhIHVuYSBwZXJzb25hIGRpc3RpbnRhIGRlIHN1IGRlc3RpbmF0YXJpbyBy ZWFsIG5vIGltcGxpY2EgcXVlIHNlIGhheWEgbW9kaWZpY2FkbyB0YWwgZGVzdGluYXRhcmlvIG5p IHN1cG9uZSByZW51bmNpYSBhIHN1IGV2ZW50dWFsIGNhcuFjdGVyIGNvbmZpZGVuY2lhbCBvIGFs IHLpZ2ltZW4gbGVnYWwgcXVlIHJpamEgc3UgdXRpbGl6YWNp824uCgpDdWFscXVpZXIgb3Bpbmnz biBleHByZXNhZGEgZW4gZXN0ZSBtZW5zYWplIHZpbmN1bGFy4SBleGNsdXNpdmFtZW50ZSBhIGxh IHBlcnNvbmEgcXVlIGxvIGhheWEgcmVtaXRpZG8sIGV4Y2VwdG8gY3VhbmRvIGVsIG1lbnNhamUg ZXN0YWJsZXpjYSBsbyBjb250cmFyaW8geSBlbCByZW1pdGVudGUgZXN06SBhdXRvcml6YWRvIHBh cmEgZXN0YWJsZWNlciBxdWUgZGljaGFzIG9waW5pb25lcyB2aW5jdWxhcuFuIGEgZXN0YSBlbnRp ZGFkLiAKCkVuIGVsIHN1cHVlc3RvIGRlIHF1ZSBlc3RlIGNvcnJlbyBzZSByZWNpYmllcmEgcG9y IGVycm9yLCByb2dhbW9zIHByb2NlZGFuIGEgYm9ycmFybG8sIHNpbiByZWVudmlhcmxvIGEgdGVy Y2Vyb3MgbmkgY29uc2VydmFybG8gZW4gY3VhbHF1aWVyIHNvcG9ydGUgeSBub3MgaW5mb3JtZW4g aW5tZWRpYXRhbWVudGUgbGxhbWFuZG8gYWwgdGVs6WZvbm8gMzQgOTEgNTg5MjEyMyBvIGEgbGEg ZGlyZWNjafNuIGRlIGNvcnJlbyBlbGVjdHLzbmljbyByZW1pdGVudGUuIEdyYWNpYXMuCgoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKiogRElTQ0xBSU1FUiAqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioKClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIGlz IGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgbmFtZWQgcGVyc29uLiBJdCBjYW4gbm90IGJl IGNvcGllZCwgdHJhbnNtaXR0ZWQgdG8gdGhpcmQgcGFydGllcyBvciBzdG9yZWQgYnkgdGhlIGxh dHRlciwgZXhjZXB0IGlmIGF1dGhvcmlzZWQgYnkgdGhlIHNlbmRlci4KCkl0IG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBsZWdhbGx5IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gd2hvc2UgbGVn YWwgcmVnaW1lIGlzIG5vdCBhZmZlY3RlZCBieSB0aGUgZmFjdCB0aGF0IHRoaXMgaW5mb3JtYXRp b24gaGFzIGJlZW4gc2VudCBieSBlLW1haWwuIAoKSXRzIGVycm9uZW91cyB0cmFuc21pc3Npb24g dG8gYSBwZXJzb24gb3RoZXIgdGhhbiB0aGUgcmVhbCBuYW1lZCBwZXJzb24gbmVpdGhlciBpbXBs aWVzIGFueSBtb2RpZmljYXRpb24gb2YgdGhpcyBuYW1lZCBwZXJzb24gbm9yIGEgcmVudW5jaWF0 aW9uIG9mIHRoZSBldmVudHVhbCBjb25maWRlbnRpYWxpdHkgb3IgbGVnYWwgcmVnaW1lIGFmZmVj dGluZyB0aGUgdXNlIG9mIGNvbmNlcm5lZCBtZXNzYWdlLgogCkFueSB2aWV3cyBleHByZXNzZWQg aW4gdGhpcyBtZXNzYWdlIGFyZSBiaW5kaW5nIGV4Y2x1c2l2ZWx5IHVwb24gdGhlIGluZGl2aWR1 YWwgc2VuZGVyLCBleGNlcHQgd2hlcmUgdGhlIG1lc3NhZ2Ugc3RhdGVzIG90aGVyd2lzZSBhbmQg dGhlIHNlbmRlciBpcyBhdXRob3Jpc2VkIHRvIGJpbmQgdGhpcyBlbnRpdHkuIAoKSWYgeW91IHJl Y2VpdmUgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IHdpdGhvdXQgdHJh bnNtaXR0aW5nIGl0IHRvIGFueSB0aGlyZCBwYXJ0eSBvciBrZWVwaW5nIGl0IGluIGFueSBmb3Jt IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkgZWl0aGVyIGJ5IHBob25lICgzNCA5MSA1ODkyMTIz KSBvciB1c2luZyB0aGUgZS0gbWFpbCBhZGRyZXNzIG9mIHRoZSBzZW5kZXIuIFRoYW5rIFlvdS4K |
|
From: Antonio C. <ant...@ga...> - 2005-05-24 22:18:04
|
Dear Caleb, Of course, we understand that the threading and synchronization primitives in QuickFIX work fine on many platforms. Anyway the service that we want to design and implement will embed the QuickFix library, but it will require A LOT MORE of multithreading code for our own purposes. So we will NOT change the QuickFix library at all. We simply need to wrap it in a large application which needs be written. For this new part of SW we are trying to locate the best open-source portable library to handle multithreading in a way that will make it easy to create SW for Windows 2000, SUN Solaris, Linux, ... . Again, thank you for your contribution. Bye, Antonio Caroselli GATE Tecnologie Informatiche S.r.l. > 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 > > On 5/24/05, Antonio Caroselli <ant...@ga...> wrote: > > > We want to design and implement an OMS embedding QuickFix, but also > > implementing a complex logix for order handling. Therefore we shall need to > > rely on thread mgmt. and that's why we were asking which are the best (i.e. > > most robust) open-source portable libraries in order to write a single > > application running under Windows, Linux, SUN Solaris. > > The threading and synchronization primitives in QuickFIX work fine on > all of these platforms, but If you want something with more bells and > whistles, I'd recommend ACE. > > -- > Caleb Epstein > caleb dot epstein at gmail dot com > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg- q22005 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > |
|
From: Caleb E. <cal...@gm...> - 2005-05-24 20:11:58
|
On 5/24/05, Antonio Caroselli <ant...@ga...> wrote: > We want to design and implement an OMS embedding QuickFix, but also > implementing a complex logix for order handling. Therefore we shall need = to > rely on thread mgmt. and that's why we were asking which are the best (i.= e. > most robust) open-source portable libraries in order to write a single > application running under Windows, Linux, SUN Solaris. The threading and synchronization primitives in QuickFIX work fine on all of these platforms, but If you want something with more bells and whistles, I'd recommend ACE. --=20 Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Antonio C. <ant...@ga...> - 2005-05-24 19:30:50
|
Dear Caleb, We want to design and implement an OMS embedding QuickFix, but also implementing a complex logix for order handling. Therefore we shall need = to rely on thread mgmt. and that's why we were asking which are the best (i.= e. most robust) open-source portable libraries in order to write a single application running under Windows, Linux, SUN Solaris. Regards, Antonio Caroselli GATE Tecnologie Informatiche s.r.l. ----- Original Message ----- From: "Caleb Epstein" <cal...@gm...> To: "Antonio Caroselli" <ant...@ga...> Cc: <qui...@li...>; "Pasquale d'Aloise" <pas...@ga...> Sent: Friday, May 20, 2005 9:54 PM Subject: Re: [Quickfix-developers] Open-souce portable libraries for thre= ad management 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 On 5/20/05, Antonio Caroselli <ant...@ga...> wrote: > Has anybody used open-souce portable libraries for thread management to > build applications embedding QuickFix ? Could you please help me locate= a > few ? QuickFIX provides portable mechanisms for starting threads and doing synchronization, but if you want something more powerful, look at: * ACE - http://www.cs.wustl.edu/~schmidt/ACE-overview.html * Boost.Threads - http://www.boost.org/ * Apache Portable Runtime - http://apr.apache.org/ (C, not C++) Its not clear from what you're asking what thread management and embedding QuickFIX have to do with each other though. -- Caleb Epstein caleb dot epstein at gmail dot com ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Dale W. <wil...@oc...> - 2005-05-24 19:22:53
|
Hi Oren,
Oren Miller wrote:
> Dale,
>
> You can ask the session object for the expected sequence numbers.
Unfortunately that tells me what my local copy of QuickFIX expects, but
not what the FIX engine at the other end of the pipe is looking for.
This code:
std::cerr << "Expected sender num before logon: " <<
session_->getExpectedSenderNum() << std::endl;
std::cerr << "Expected target num before logon: " <<
session_->getExpectedTargetNum() << std::endl;
session_->logon();
and:
void
QuickFIXECNAdapter::Exchange::onLogout( const FIX::SessionID& sessionID )
{
std::cerr << "Expected sender num in onLogout: " <<
session_->getExpectedSenderNum() << std::endl;
std::cerr << "Expected target num in onLogout: " <<
session_->getExpectedTargetNum() << std::endl;
Produces this output:
Expected sender num before logon: 1
Expected target num before logon: 1
Expected sender num in onLogout: 2
Expected target num in onLogout: 1
Expected sender num in onLogout: 3
Expected target num in onLogout: 1
And here's the interpreted input log message:
============================================================
8=FIX.4.2 | BeginString = FIX.4.2
9=104 | BodyLength = 104
35=5 | MsgType = Logout
34=10 | MsgSeqNum = 10
49=EXSIM | SenderCompID = EXSIM
52=20050524-19:00:51.000
| SendingTime = 20050524-19:00:51.000
56=CLIENT | TargetCompID = CLIENT
----------------------------------------
58=MsgSeqNum too low, expecting 7 but received 1
| Text = MsgSeqNum too low, expecting 7 but
received 1
----------------------------------------
10=007 | CheckSum = 007
Notice that the local copy of QuickFIX *still* doesn't know that the
target is looking for sender sequence # 7. ( I wouldn't really expect
it to, that info is only available in the Text field which I'm planning
to parse if I can get my hands on it.)
One theory I have is that the test in Session::validLogonState is
incorrect, because a Logout message is a legitimate response to a
Logon. If validLoginState allowed this message to pass then presumably
both fromAdmin and onLogout would be called and I could capture the data
I need to fix things in fromAdmin, and the session would end up
correctly logged out. There may be other implications of making this
change that I'm missing, though so I haven't experimented yet.
Dale
>
> http://www.quickfixengine.org/quickfix/doc/html/class_f_i_x_1_1_session.html#a27
>
> --oren
>
> ----- Original Message -----
> *From:* Dale Wilson <mailto:wil...@oc...>
> *To:* qui...@li...
> <mailto:qui...@li...>
> *Sent:* Tuesday, May 24, 2005 12:53 PM
> *Subject:* [Quickfix-developers] Recovering from client side
> sequence number amnesia
>
>Due to some network problems, I may (or may not) have managed to send this message yesterday. Please forgive it if it's a duplicate.
>
>Dale
>
>Hi QuickFIX developers,
>
>I think I've run into a "you-can't-get-there-from-here" problem, but I'd like to be sure I'm not missing something.
>
>The situation I'm trying to handle happens when the client (initiator) is recovering from a significant failure and has lost track of the sequence number expected by the server (acceptor). The client sends logon message a sequence number that is less than the one expected by the server. The server responds, correctly, with a logout message. If the server is based on QuickFIX this logout message will contain a Text field giving the expected sequence number.
>
> i.e.: 58=MsgSeqNum too low, expecting 7 but received 1
>
>What I would like to do is detect this Logout message; inform the user of the situation; and allow them to verity that the sequence number should be reset.
>
>Unfortunately as far as I have been able to determine, the Logout message containig the expected sequence number never reaches the application code. QuickFIX determines that this is not a valid sequence of messages:
>
> [Session::verify calls Session::validLogonState and throws an exception when it returns false. ]
>
>and calls Application::onLogout() (twice, actually, but who's counting.) The body of the message containing the expected sequence number isn't available vis the onLogout call -- so I can't find a way to determine what sequence number is expected.
>
>My work around for this will be to read the log, identify the logout message, and parse it to find the expected sequence number -- unless, of course, someone tells me that there's a better way.
>
>Any suggestions would be appreciated,
>
>Dale
>
>
>
> --
> -----------------------------------------------------
> Dale Wilson, Senior Software Engineer
> Object Computing, Inc. (OCI)
> http://www.ociweb.com/ http://www.theaceorb.com/
> ----------------------------------------------------
>
--
-----------------------------------------------------
Dale Wilson, Senior Software Engineer
Object Computing, Inc. (OCI)
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------
|
|
From: Oren M. <or...@qu...> - 2005-05-24 18:01:58
|
Dale, You can ask the session object for the expected sequence numbers. http://www.quickfixengine.org/quickfix/doc/html/class_f_i_x_1_1_session.h= tml#a27 --oren ----- Original Message -----=20 From: Dale Wilson=20 To: qui...@li...=20 Sent: Tuesday, May 24, 2005 12:53 PM Subject: [Quickfix-developers] Recovering from client side sequence = number amnesia Due to some network problems, I may (or may not) have managed to send = this message yesterday. Please forgive it if it's a duplicate. Dale Hi QuickFIX developers, I think I've run into a "you-can't-get-there-from-here" problem, but I'd = like to be sure I'm not missing something. The situation I'm trying to handle happens when the client (initiator) = is recovering from a significant failure and has lost track of the = sequence number expected by the server (acceptor). The client sends = logon message a sequence number that is less than the one expected by = the server. The server responds, correctly, with a logout message. If = the server is based on QuickFIX this logout message will contain a Text = field giving the expected sequence number.=20 i.e.: 58=3DMsgSeqNum too low, expecting 7 but received 1 What I would like to do is detect this Logout message; inform the user = of the situation; and allow them to verity that the sequence number = should be reset. Unfortunately as far as I have been able to determine, the Logout = message containig the expected sequence number never reaches the = application code. QuickFIX determines that this is not a valid sequence = of messages: [Session::verify calls Session::validLogonState and throws an = exception when it returns false. ]=20 and calls Application::onLogout() (twice, actually, but who's = counting.) The body of the message containing the expected sequence = number isn't available vis the onLogout call -- so I can't find a way to = determine what sequence number is expected. My work around for this will be to read the log, identify the logout = message, and parse it to find the expected sequence number -- unless, of = course, someone tells me that there's a better way. Any suggestions would be appreciated, Dale --=20 ----------------------------------------------------- Dale Wilson, Senior Software Engineer=20 Object Computing, Inc. (OCI) http://www.ociweb.com/ http://www.theaceorb.com/ ---------------------------------------------------- |
|
From: Dale W. <wil...@oc...> - 2005-05-24 17:53:15
|
Due to some network problems, I may (or may not) have managed to send this message yesterday. Please forgive it if it's a duplicate. Dale Hi QuickFIX developers, I think I've run into a "you-can't-get-there-from-here" problem, but I'd like to be sure I'm not missing something. The situation I'm trying to handle happens when the client (initiator) is recovering from a significant failure and has lost track of the sequence number expected by the server (acceptor). The client sends logon message a sequence number that is less than the one expected by the server. The server responds, correctly, with a logout message. If the server is based on QuickFIX this logout message will contain a Text field giving the expected sequence number. i.e.: 58=MsgSeqNum too low, expecting 7 but received 1 What I would like to do is detect this Logout message; inform the user of the situation; and allow them to verity that the sequence number should be reset. Unfortunately as far as I have been able to determine, the Logout message containig the expected sequence number never reaches the application code. QuickFIX determines that this is not a valid sequence of messages: [Session::verify calls Session::validLogonState and throws an exception when it returns false. ] and calls Application::onLogout() (twice, actually, but who's counting.) The body of the message containing the expected sequence number isn't available vis the onLogout call -- so I can't find a way to determine what sequence number is expected. My work around for this will be to read the log, identify the logout message, and parse it to find the expected sequence number -- unless, of course, someone tells me that there's a better way. Any suggestions would be appreciated, Dale -- ----------------------------------------------------- Dale Wilson, Senior Software Engineer Object Computing, Inc. (OCI) http://www.ociweb.com/ http://www.theaceorb.com/ ---------------------------------------------------- |
|
From: Oren M. <or...@qu...> - 2005-05-24 03:10:53
|
You can post patches to this list if you like. Alternatively you can use the bugtracker (http://www.quickfixengine.org/bugtracker/). For new functionality, add it as a feature request and then attach your source files. --oren On May 23, 2005, at 10:02 PM, Fanshteyn, Timur wrote: > Is there a place to contribute to the project? I have a MS-SQL > Message and Log Store done as a separate project (based on the > MYSQL code). Nothing complicated, but it might save someone a few > hours of coding. Is there a place to contribute code like this? > > Timur > |
|
From: Fanshteyn, T. <tfa...@bo...> - 2005-05-24 03:02:27
|
Is there a place to contribute to the project? I have a MS-SQL Message and Log Store done as a separate project (based on the MYSQL code). Nothing complicated, but it might save someone a few hours of coding. Is there a place to contribute code like this? Timur |
|
From: Fanshteyn, T. <tfa...@bo...> - 2005-05-24 03:00:28
|
How can I get the code to retrieve session_qualifier incorporated into the main tree (I have the 5 lines of code done, but would not want to merge it into the trunk at the next release ) Is there a way I can submit the changes for review (and inclusion) Timur |
|
From: Dale W. <wil...@oc...> - 2005-05-23 15:04:36
|
Hi QuickFIX developers,
I think I've run into a "you-can't-get-there-from-here" problem, but I'd
like to be sure I'm not missing something.
The situation I'm trying to handle happens when the client (initiator)
is recovering from a significant failure and has lost track of the
sequence number expected by the server (acceptor).
The client sends logon message a sequence number that is less than the
one expected by the server. The server responds, correctly, with a
logout message. If the server is based on QuickFIX this logout message
will contain a Text field giving the expected sequence number.
i.e.: 58=MsgSeqNum too low, expecting 7 but received 1
What I would like to do is detect this Logout message; inform the user
of the situation; and allow them to verity that the sequence number
should be reset.
Unfortunately as far as I have been able to determine, the Logout
message containig the expected sequence number never reaches the
application code. QuickFIX determines that this is not a valid sequence
of messages:
[ Session::verify calls Session::validLogonState and throws an
exception when it returns false. ]
and calls Application::onLogout() (twice, actually, but who's counting.)
The body of the message containing the expected sequence number isn't
available vis the onLogout call -- so I can't find a way to determine
what sequence number is expected.
My work around for this will be to read the log, identify the logout
message, and parse it to find the expected sequence number -- unless, of
course, someone tells me that there's a better way.
Any suggestions would be appreciated,
Dale
--
-----------------------------------------------------
Dale Wilson, Senior Software Engineer
Object Computing, Inc. (OCI)
http://www.ociweb.com/ http://www.theaceorb.com/
----------------------------------------------------
|
|
From: Emil V. <que...@ho...> - 2005-05-22 08:47:31
|
Hi Oren, here it is, cheers, Emil >From: "Oren Miller" <or...@qu...> >To: "Emil Vladov" ><que...@ho...>,<qui...@li...> >Subject: Re: [Quickfix-developers] StartTime or EndTime parsing error >message >Date: Wed, 18 May 2005 15:57:34 -0500 >MIME-Version: 1.0 >Received: from smtpout02-04.prod.mesa1.secureserver.net ([64.202.165.194]) >by mc9-f7.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 May >2005 13:57:32 -0700 >Received: (qmail 4362 invoked from network); 18 May 2005 20:57:32 -0000 >Received: from unknown (66.134.230.34) by >smtpout02-04.prod.mesa1.secureserver.net (64.202.165.194) with ESMTP; 18 >May 2005 20:57:31 -0000 >X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8= >References: <BAY...@ph...> >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook Express 6.00.2900.2180 >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 >Return-Path: or...@qu... >X-OriginalArrivalTime: 18 May 2005 20:57:33.0036 (UTC) >FILETIME=[363DDAC0:01C55BEC] > >Thanks Emil, > >Sure, if you have a patch for this we would be glad to take a look at it >and consider integrating it into a future release. > >--oren > >----- Original Message ----- From: "Emil Vladov" <que...@ho...> >To: <qui...@li...> >Sent: Tuesday, May 17, 2005 3:24 AM >Subject: [Quickfix-developers] StartTime or EndTime parsing error message > > >>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 Oren, >> >>Seems that if the StartTime or EndTime can't be parsed the error message >>is lost when rethrowing the FieldConvert exception in >>SessionFactory::create. >> >>I could fix this and submit a change if you think it's appropriate - I >>propose adding one method to the Dictionary class - getTime for example >>and encoding the field name in the exception text as the remaining >>members. >> >>Cheers, Emil >> >>(The SourceForge's search facility isn't working so sorry if I'm >>duplicating anything.) >> >>_________________________________________________________________ >>Express yourself instantly with MSN Messenger! Download today it's FREE! >>http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by Oracle Space Sweepstakes >>Want to be the first software developer in space? >>Enter now for the Oracle Space Sweepstakes! >>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >>_______________________________________________ >>Quickfix-developers mailing list >>Qui...@li... >>https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> > _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
|
From: Caleb E. <cal...@gm...> - 2005-05-20 19:54:43
|
On 5/20/05, Antonio Caroselli <ant...@ga...> wrote: > Has anybody used open-souce portable libraries for thread management to > build applications embedding QuickFix ? Could you please help me locate a > few ?=20 QuickFIX provides portable mechanisms for starting threads and doing synchronization, but if you want something more powerful, look at: * ACE - http://www.cs.wustl.edu/~schmidt/ACE-overview.html * Boost.Threads - http://www.boost.org/ * Apache Portable Runtime - http://apr.apache.org/ (C, not C++) Its not clear from what you're asking what thread management and embedding QuickFIX have to do with each other though. --=20 Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Oren M. <or...@qu...> - 2005-05-20 18:44:00
|
Did you include quickfix/fix42/NewOrderSingle.h? --oren ----- Original Message ----- From: "Nickolai Dobrynin" <n_d...@ya...> To: <qui...@li...> Sent: Friday, May 20, 2005 1:19 PM Subject: [Quickfix-developers] Strange compile error: getHeader undeclared > 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 to everyone! > > Anybody could please help me make sense of the > following. > > The last line in the code below produces a compile > error: `getHeader' undeclared. Anybody can tell me > why? Obviously, this method *is* declared in > FIX42::Message from which FIX42::NewOrderSingle > inherits. > > void btgateway::ClientsApplication::onMessage(const > FIX42::NewOrderSingle& nos, const FIX::SessionID& sid) > { > const FIX42::Header& header = nos.getHeader(); > > I'm using gcc 3.3.4 on Solaris 8. > > > Many thanks, > > Nickolai > > > > __________________________________ > Do you Yahoo!? > Make Yahoo! your home page > http://www.yahoo.com/r/hs > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Nickolai D. <n_d...@ya...> - 2005-05-20 18:19:49
|
Hi to everyone!
Anybody could please help me make sense of the
following.
The last line in the code below produces a compile
error: `getHeader' undeclared. Anybody can tell me
why? Obviously, this method *is* declared in
FIX42::Message from which FIX42::NewOrderSingle
inherits.
void btgateway::ClientsApplication::onMessage(const
FIX42::NewOrderSingle& nos, const FIX::SessionID& sid)
{
const FIX42::Header& header = nos.getHeader();
I'm using gcc 3.3.4 on Solaris 8.
Many thanks,
Nickolai
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
|
|
From: Antonio C. <ant...@ga...> - 2005-05-20 16:45:54
|
Has anybody used open-souce portable libraries for thread management to = build applications embedding QuickFix ? Could you please help me locate = a few ? Regards, Antonio Caroselli GATE Tecnologie Informatiche s.r.l. |
|
From: Oren M. <or...@qu...> - 2005-05-18 21:02:39
|
We will take a look at this. I don't think it will make it to the next =
release, but we may put this or something like it into one of the =
following releases.
--oren
----- Original Message -----=20
From: Pasquale d'Aloise=20
To: qui...@li...=20
Sent: Tuesday, May 17, 2005 12:41 PM
Subject: [Quickfix-developers] Multiple FIX acceptor servers
Hi,
I have the need to start two FIX acceptors on two different machines =
letting an initiator connect alternatively to both ones. This scenario =
is useful to implement fault-tolerant services.
With the current release of QuickFIX library (1.9.4) I have the =
problem of maintaining the sequence numbers synchronized, even if I use =
the database storing; QuickFIX, in fact, keeps an internal copy of =
sequence numbers that it uses to validate the incoming messages and to =
set the outgoing ones.
So I have worked around the problem by adding the virtual method =
ReloadSeqNums() to the class MessageStore and to its derived MySQLStore. =
The MySQLStore implementation of this method is:
void MySQLStore::ReloadSeqNums() { populateCache(); }
I call the above mentioned method in void Session::nextLogon( const =
Message& logon ) by means of the following statement:
m_state.store()->ReloadSeqNums();
Do you think this update could be extended to future versions of the =
QuickFIX library?
If you have any concerns about my update, please let me know.
Regards,
Pasquale d'Aloise
GATE Tecnologie Informatiche s.r.l.
|