quickfix-developers Mailing List for QuickFIX (Page 48)
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: Malinka R. <ael...@gm...> - 2009-10-16 17:50:51
|
On Fri, Oct 16, 2009 at 13:31, ch...@gm... <ch...@gm...> wrote: > here is my config file of qfix the defut part one rest is same.. > > default settings for sessions > > [DEFAULT] > ConnectionType=initiator > ReconnectInterval=20 > > LogonTimeout=30 > StartTime=00:00:00 > EndTime=23:00:00 > HeartBtInt=10 > #SocketConnectHost=localhost > SocketConnectHost=127.0.0.1 I see no socket connect port, but according to your fix logs it's getting somehow > > FileLogPath=c:\qfixlogs\ > FileStorePath=c:\qfixstore\ > > > here is my Stunnel config > > ; Use it for client mode > client = yes > debug = 7 please turn logging level down some this makes it difficult to sort through the stunnel logs > output = stunnel.log > [https] > accept = 127.0.0.1:9000 in log you're connecting from 192.168.2.3? accept = 9000 will allow connections from anywhere > connect = 84.219.221.89:443 > ;TIMEOUTclose = 0 > personally i would try telnet on each individual piece until you find the part that isn't playing well, and start trying to change things there until it works. just like trouble shooting anything else break it down to what you can prove works or doesn't and then slowly add the complexity back in p.s. also when dealing with mailing lists it's best to make sure that you're at least cc'ing the mailing list still on a reply so that everyone still gets the relevant information |
|
From: <ch...@gm...> - 2009-10-16 17:35:09
|
here are my Stunnel logs for 2009.10.16 23:14:16 LOG7[5484:5436]: https connecting 84.219.221.89:443 2009.10.16 23:14:16 LOG7[5484:5436]: connect_wait: waiting 10 seconds 2009.10.16 23:14:17 LOG7[5484:5436]: connect_wait: connected 2009.10.16 23:14:17 LOG5[5484:5436]: https connected remote server from 192.168.2.3:3199 2009.10.16 23:14:17 LOG7[5484:5436]: Remote FD=368 initialized 2009.10.16 23:14:17 LOG7[5484:5436]: TCP_NODELAY option set on remote socket 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): before/connect initialization 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 write client hello A 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 read server hello A 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 read server certificate A 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 read server done A 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 write client key exchange A 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 write change cipher spec A 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 write finished A 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 flush data 2009.10.16 23:14:17 LOG7[5484:5436]: SSL state (connect): SSLv3 read finished A 2009.10.16 23:14:17 LOG7[5484:5436]: 1 items in the session cache 2009.10.16 23:14:17 LOG7[5484:5436]: 1 client connects (SSL_connect()) 2009.10.16 23:14:17 LOG7[5484:5436]: 1 client connects that finished 2009.10.16 23:14:17 LOG7[5484:5436]: 0 client renegotiations requested 2009.10.16 23:14:17 LOG7[5484:5436]: 0 server connects (SSL_accept()) 2009.10.16 23:14:17 LOG7[5484:5436]: 0 server connects that finished 2009.10.16 23:14:17 LOG7[5484:5436]: 0 server renegotiations requested 2009.10.16 23:14:17 LOG7[5484:5436]: 0 session cache hits 2009.10.16 23:14:17 LOG7[5484:5436]: 0 session cache misses 2009.10.16 23:14:17 LOG7[5484:5436]: 0 session cache timeouts ch...@gm... wrote: > > HI, sorry i copied the config file from wrong looaction . in the config > file i am sending data to localhost. Stunnel is sending data out correctly > i have checked the logs. > > here is my config file of qfix the defut part one rest is same.. > > default settings for sessions > > [DEFAULT] > ConnectionType=initiator > ReconnectInterval=20 > > LogonTimeout=30 > StartTime=00:00:00 > EndTime=23:00:00 > HeartBtInt=10 > #SocketConnectHost=localhost > SocketConnectHost=127.0.0.1 > > FileLogPath=c:\qfixlogs\ > FileStorePath=c:\qfixstore\ > > > here is my Stunnel config > > ; Use it for client mode > client = yes > debug = 7 > output = stunnel.log > [https] > accept = 127.0.0.1:9000 > connect = 84.219.221.89:443 > ;TIMEOUTclose = 0 > > Please suggest. > > Malinka Rellikwodahs wrote: >> >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> On Fri, Oct 16, 2009 at 12:54, ch...@gm... <ch...@gm...> >> wrote: >>> QuickFIX Documentation: >>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>> QuickFIX Support: http://www.quickfixengine.org/services.html >>> >>> >>> Hi i am trying to connect to FIX server..... I am using Stunnel for >>> SSL. but >>> i am got getting loged on. >>> Below is my log file.... >> >> your config and your logs don't match, and we'd need to see your >> stunnel config, but off the top of my head stunnel is either not >> running or not configured right >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> > > -- View this message in context: http://www.nabble.com/Re%3A-getting-connection-error....-Socket-Error%3A-Connection-reset-by-peer.-tp25929021p25929382.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: <ch...@gm...> - 2009-10-16 17:31:58
|
HI, sorry i copied the config file from wrong looaction . in the config file i am sending data to localhost. Stunnel is sending data out correctly i have checked the logs. here is my config file of qfix the defut part one rest is same.. default settings for sessions [DEFAULT] ConnectionType=initiator ReconnectInterval=20 LogonTimeout=30 StartTime=00:00:00 EndTime=23:00:00 HeartBtInt=10 #SocketConnectHost=localhost SocketConnectHost=127.0.0.1 FileLogPath=c:\qfixlogs\ FileStorePath=c:\qfixstore\ here is my Stunnel config ; Use it for client mode client = yes debug = 7 output = stunnel.log [https] accept = 127.0.0.1:9000 connect = 84.219.221.89:443 ;TIMEOUTclose = 0 Please suggest. Malinka Rellikwodahs wrote: > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > On Fri, Oct 16, 2009 at 12:54, ch...@gm... <ch...@gm...> > wrote: >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> >> Hi i am trying to connect to FIX server..... I am using Stunnel for SSL. >> but >> i am got getting loged on. >> Below is my log file.... > > your config and your logs don't match, and we'd need to see your > stunnel config, but off the top of my head stunnel is either not > running or not configured right > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- View this message in context: http://www.nabble.com/Re%3A-getting-connection-error....-Socket-Error%3A-Connection-reset-by-peer.-tp25929021p25929334.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: Malinka R. <ael...@gm...> - 2009-10-16 17:12:19
|
On Fri, Oct 16, 2009 at 12:54, ch...@gm... <ch...@gm...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > Hi i am trying to connect to FIX server..... I am using Stunnel for SSL. but > i am got getting loged on. > Below is my log file.... your config and your logs don't match, and we'd need to see your stunnel config, but off the top of my head stunnel is either not running or not configured right |
|
From: <ch...@gm...> - 2009-10-16 17:10:25
|
Hi i am trying to connect to FIX server..... I am using Stunnel for SSL. but i am got getting loged on. Below is my log file.... 20091014-16:28:18 : Created session 20091014-16:28:20 : Connecting to 127.0.0.1 on port 9000 20091014-16:28:20 : Initiated logon request 20091014-16:28:21 : Socket Error: Connection reset by peer. 20091014-16:28:21 : Disconnecting 20091014-16:28:41 : Connecting to 127.0.0.1 on port 9000 20091014-16:28:41 : Initiated logon request 20091014-16:28:42 : Socket Error: Connection reset by peer. 20091014-16:28:42 : Disconnecting Config file setting are as follows.. [DEFAULT] ConnectionType=initiator ReconnectInterval=20 StartTime=12:00:00 EndTime=23:00:00 SenderCompID=TW SenderSubID=user1 HeartBtInt=10 SocketConnectPort=443 SocketConnectHost=ssl://84.219.221.89 FileLogPath=c:\qfixlogs\ FileStorePath=c:\qfixstore\ # session definition [SESSION] # inherit ConnectionType, ReconnectInterval and SenderCompID from default BeginString=FIX.4.4 TargetCompID=ISLD TargetSubID=qftrade HeartBtInt=10 FileLogPath=c:\qfixlogs\ FileStorePath=c:\qfixstore\ DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml here are The messages in the message log.... 8=FIX.4.4 9=90 35=A 34=1 49=TW 50=user1 52=20091014-16:28:20.420 56=ISLD 96=1234567 98=0 108=10 10=041 8=FIX.4.4 9=90 35=A 34=2 49=TW 50=User1 52=20091014-16:28:41.416 56=ISLD 96=1234567 98=0 108=10 10=050 Please guide me whats the issue in this???? -- View this message in context: http://www.nabble.com/getting-connection-error....-Socket-Error%3A-Connection-reset-by-peer.-tp25928930p25928930.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: <ch...@gm...> - 2009-10-16 16:54:29
|
Hi i am trying to connect to FIX server..... I am using Stunnel for SSL. but i am got getting loged on. Below is my log file.... 20091014-16:28:18 : Created session 20091014-16:28:20 : Connecting to 127.0.0.1 on port 9000 20091014-16:28:20 : Initiated logon request 20091014-16:28:21 : Socket Error: Connection reset by peer. 20091014-16:28:21 : Disconnecting 20091014-16:28:41 : Connecting to 127.0.0.1 on port 9000 20091014-16:28:41 : Initiated logon request 20091014-16:28:42 : Socket Error: Connection reset by peer. 20091014-16:28:42 : Disconnecting Config file setting are as follows.. [DEFAULT] ConnectionType=initiator ReconnectInterval=20 StartTime=12:00:00 EndTime=23:00:00 SenderCompID=TW SenderSubID=user1 HeartBtInt=10 SocketConnectPort=443 SocketConnectHost=ssl://84.219.221.89 FileLogPath=c:\qfixlogs\ FileStorePath=c:\qfixstore\ # session definition [SESSION] # inherit ConnectionType, ReconnectInterval and SenderCompID from default BeginString=FIX.4.4 TargetCompID=ISLD TargetSubID=qftrade HeartBtInt=10 FileLogPath=c:\qfixlogs\ FileStorePath=c:\qfixstore\ DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml here are The messages in the message log.... 8=FIX.4.49=9035=A34=149=inttest50=trader152=20091014-16:28:20.42056=FXALL96=fxall12398=0108=1010=041 8=FIX.4.49=9035=A34=249=inttest50=trader152=20091014-16:28:41.41656=FXALL96=fxall12398=0108=1010=050 Please guide me whats the issue in this???? -- View this message in context: http://www.nabble.com/getting-connection-error....-Socket-Error%3A-Connection-reset-by-peer.-tp25928657p25928657.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: George H. <ge...@so...> - 2009-10-16 02:02:13
|
Kenny, This is true. However I don't always have access to those. With this code, I can get a bunch of fix messages (from anywhere) and re-run them. I wonder what else am I missing? I mean, is this all I would need? It was too simple. On Oct 15, 2009, at 9:46 PM, Kenny Stone wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > You could also use the file store or logs that QuickFIX creates. > > On Thu, Oct 15, 2009 at 8:16 PM, George Hrysanthopoulos <ge...@so... > > wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Andrei, > > Thank you for the quick and very helpful reply. > > Just as you said, "QuickFIX::Message.toString()" did the trick. > > Here is my test code to get a string from a message and back again: > > > 52 void Application::fromApp( const FIX::Message& message, const > FIX::SessionID& sessionID ) > 53 throw( FIX::FieldNotFound, FIX::IncorrectDataFormat, > FIX::IncorrectTagValue, FIX::UnsupportedMessageType ) > 54 { > 55 struct timeval tv; > 56 struct timezone tz; > 57 struct tm *tm; > 58 std::string RawMessage; > 59 std::string RawMessageXL; > 60 > 61 FIX::MsgType msgtype; > 62 FIX::Message quickFixMessage; > 63 > 64 crack( message, sessionID ); > 65 message.getHeader().getField( msgtype ); > 66 > 67 gettimeofday(&tv, &tz); > 68 tm=localtime(&tv.tv_sec); > 69 myLog(VERBOSE_L1, "Ticket Incoming: %d:%02d:%02d.%d\n", tm- > >tm_hour, tm->tm_min, tm->tm_sec, (int)tv.tv_usec); > 70 > 71 // > 72 // > 73 // Here is the "message" -> string -> "message" again > 74 // > 75 message.toString(RawMessage); > 76 > 77 myLogV(VERBOSE_L2, "MSG Type: %s\n", msgtype); > 78 myLog(VERBOSE_L2, "Incoming Data:\n\t\t%s\n", > RawMessage.c_str()); > 79 // > 80 // > 81 // > 82 FIX::Session* pSession = > FIX::Session::lookupSession( sessionID ); > 83 FIX::DataDictionary dict; > 84 dict = pSession->getDataDictionary(); > 85 try > 86 { > 87 quickFixMessage = FIX::Message( RawMessage, > dict ); > 88 } > 89 catch ( std::exception & e ) > 90 { > 91 myLogV(ALWAYS_PRINT, "\"fromApp\" Exception: %s > \n", e.what()); > 92 } > 93 myLogV(ALWAYS_PRINT, "\"XLData\":\n\t\t%s\n", > quickFixMessage); > ... > ... > > > You might as why bother? Well, with the outgoing messages in their > original format (in a file) > I can replay/resend a bunch of messages (in case of problems). > > Again, many thanks, > > George > > > On Oct 15, 2009, at 3:02 PM, Andrei Goldchleger wrote: > > > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > On Thu, Oct 15, 2009 at 1:43 PM, George Hrysanthopoulos > > <ge...@so...> wrote: > >> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > >> QuickFIX Support: http://www.quickfixengine.org/services.html > >> > >> Hello everyone, > >> > >> Quick question: > >> > >> From my acceptor app, I want to get the raw data stream for a > >> message > >> (session or otherwise) > >> including all field separators (0x01), etc. > >> > >> I want to dump this to a file later. > >> > >> How do I get this raw message? > >> > >> Many thanks, > >> > >> George Hrysanthopoulos > > > > Use the QuickFIX::Message.toString() in the fromApp() and > fromAdmin() > > callbacks. > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart > > your > > developing skills, take BlackBerry mobile applications to market and > > stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register > now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > -- > Kenny Stone > Connamara Systems, LLC > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference_______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Kenny S. <ks...@co...> - 2009-10-16 01:47:05
|
You could also use the file store or logs that QuickFIX creates. On Thu, Oct 15, 2009 at 8:16 PM, George Hrysanthopoulos < ge...@so...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Andrei, > > Thank you for the quick and very helpful reply. > > Just as you said, "QuickFIX::Message.toString()" did the trick. > > Here is my test code to get a string from a message and back again: > > > 52 void Application::fromApp( const FIX::Message& message, const > FIX::SessionID& sessionID ) > 53 throw( FIX::FieldNotFound, FIX::IncorrectDataFormat, > FIX::IncorrectTagValue, FIX::UnsupportedMessageType ) > 54 { > 55 struct timeval tv; > 56 struct timezone tz; > 57 struct tm *tm; > 58 std::string RawMessage; > 59 std::string RawMessageXL; > 60 > 61 FIX::MsgType msgtype; > 62 FIX::Message quickFixMessage; > 63 > 64 crack( message, sessionID ); > 65 message.getHeader().getField( msgtype ); > 66 > 67 gettimeofday(&tv, &tz); > 68 tm=localtime(&tv.tv_sec); > 69 myLog(VERBOSE_L1, "Ticket Incoming: %d:%02d:%02d.%d\n", tm- > >tm_hour, tm->tm_min, tm->tm_sec, (int)tv.tv_usec); > 70 > 71 // > 72 // > 73 // Here is the "message" -> string -> "message" again > 74 // > 75 message.toString(RawMessage); > 76 > 77 myLogV(VERBOSE_L2, "MSG Type: %s\n", msgtype); > 78 myLog(VERBOSE_L2, "Incoming Data:\n\t\t%s\n", > RawMessage.c_str()); > 79 // > 80 // > 81 // > 82 FIX::Session* pSession = > FIX::Session::lookupSession( sessionID ); > 83 FIX::DataDictionary dict; > 84 dict = pSession->getDataDictionary(); > 85 try > 86 { > 87 quickFixMessage = FIX::Message( RawMessage, dict ); > 88 } > 89 catch ( std::exception & e ) > 90 { > 91 myLogV(ALWAYS_PRINT, "\"fromApp\" Exception: %s > \n", e.what()); > 92 } > 93 myLogV(ALWAYS_PRINT, "\"XLData\":\n\t\t%s\n", > quickFixMessage); > ... > ... > > > You might as why bother? Well, with the outgoing messages in their > original format (in a file) > I can replay/resend a bunch of messages (in case of problems). > > Again, many thanks, > > George > > > On Oct 15, 2009, at 3:02 PM, Andrei Goldchleger wrote: > > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > On Thu, Oct 15, 2009 at 1:43 PM, George Hrysanthopoulos > > <ge...@so...> wrote: > >> QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > >> QuickFIX Support: http://www.quickfixengine.org/services.html > >> > >> Hello everyone, > >> > >> Quick question: > >> > >> From my acceptor app, I want to get the raw data stream for a > >> message > >> (session or otherwise) > >> including all field separators (0x01), etc. > >> > >> I want to dump this to a file later. > >> > >> How do I get this raw message? > >> > >> Many thanks, > >> > >> George Hrysanthopoulos > > > > Use the QuickFIX::Message.toString() in the fromApp() and fromAdmin() > > callbacks. > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart > > your > > developing skills, take BlackBerry mobile applications to market and > > stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > -- Kenny Stone Connamara Systems, LLC |
|
From: George H. <ge...@so...> - 2009-10-16 01:16:53
|
Andrei,
Thank you for the quick and very helpful reply.
Just as you said, "QuickFIX::Message.toString()" did the trick.
Here is my test code to get a string from a message and back again:
52 void Application::fromApp( const FIX::Message& message, const
FIX::SessionID& sessionID )
53 throw( FIX::FieldNotFound, FIX::IncorrectDataFormat,
FIX::IncorrectTagValue, FIX::UnsupportedMessageType )
54 {
55 struct timeval tv;
56 struct timezone tz;
57 struct tm *tm;
58 std::string RawMessage;
59 std::string RawMessageXL;
60
61 FIX::MsgType msgtype;
62 FIX::Message quickFixMessage;
63
64 crack( message, sessionID );
65 message.getHeader().getField( msgtype );
66
67 gettimeofday(&tv, &tz);
68 tm=localtime(&tv.tv_sec);
69 myLog(VERBOSE_L1, "Ticket Incoming: %d:%02d:%02d.%d\n", tm-
>tm_hour, tm->tm_min, tm->tm_sec, (int)tv.tv_usec);
70
71 //
72 //
73 // Here is the "message" -> string -> "message" again
74 //
75 message.toString(RawMessage);
76
77 myLogV(VERBOSE_L2, "MSG Type: %s\n", msgtype);
78 myLog(VERBOSE_L2, "Incoming Data:\n\t\t%s\n",
RawMessage.c_str());
79 //
80 //
81 //
82 FIX::Session* pSession =
FIX::Session::lookupSession( sessionID );
83 FIX::DataDictionary dict;
84 dict = pSession->getDataDictionary();
85 try
86 {
87 quickFixMessage = FIX::Message( RawMessage, dict );
88 }
89 catch ( std::exception & e )
90 {
91 myLogV(ALWAYS_PRINT, "\"fromApp\" Exception: %s
\n", e.what());
92 }
93 myLogV(ALWAYS_PRINT, "\"XLData\":\n\t\t%s\n",
quickFixMessage);
...
...
You might as why bother? Well, with the outgoing messages in their
original format (in a file)
I can replay/resend a bunch of messages (in case of problems).
Again, many thanks,
George
On Oct 15, 2009, at 3:02 PM, Andrei Goldchleger wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> On Thu, Oct 15, 2009 at 1:43 PM, George Hrysanthopoulos
> <ge...@so...> wrote:
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hello everyone,
>>
>> Quick question:
>>
>> From my acceptor app, I want to get the raw data stream for a
>> message
>> (session or otherwise)
>> including all field separators (0x01), etc.
>>
>> I want to dump this to a file later.
>>
>> How do I get this raw message?
>>
>> Many thanks,
>>
>> George Hrysanthopoulos
>
> Use the QuickFIX::Message.toString() in the fromApp() and fromAdmin()
> callbacks.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Rick L. <ric...@gm...> - 2009-10-15 21:54:07
|
Thanks again for everyones' input.
I feel that the easiest way to change my TestRequest behavior was to modify
the QuickFix code -- I feel that I can do this with two simple modifications
in the SessionState.h file. I am hoping someone who is familiar with the
source will tell me if they see anything horribly wrong with what I'm
proposing -- the last thing I want to do is muck around in the QF code, but
this might save me a lot of headaches trying to do it in my code callbacks.
I'm modifying two functions timedOut() and needTestRequest(). Basically,
I'm trying to get QF to issue a TestRequest after no responses for
1.2*HeartBtInt, and then issue *another *TestRequest after 1.4*HeartBtInt --
in other words, much more rapidly than it does by default (and then issue a
disconnect after 2 TestRequests).
bool needTestRequest() const
{
UtcTimeStamp now;
// testRequest() will be 0 for the first occurrence, and 1 for the 2nd
occurrence.
if(testRequest() < 2){
return (now - lastReceivedTime() >= (1 + (0.2*(testRequest()+1))) *
(double)heartBtInt());
}
return false;
}
Basically I'm saying "if I haven't sent 2 TestRequests already then if it's
been at least 1.2 times the HeartBtInt I should send a TestRequest (or 1.4 *
HeartBtInt if this is the 2nd TestRequest).
And then the other function I modify (to log off after 2 unanswered
TestRequests):
bool timedOut() const
{
UtcTimeStamp now;
return ( now - lastReceivedTime() ) >= (1.6 * (double)heartBtInt());
}
I will return true if at least 1.6 * HeartBtInt seconds have transpired.
Does anyone see anything bad with this approach?
Thanks,
Rick
On Thu, Oct 15, 2009 at 3:11 PM, John Vatianou <jva...@co...>wrote:
>
>
> On Thu, Oct 15, 2009 at 2:53 PM, Rick Lane <ric...@gm...> wrote:
>
>> John,
>> Thanks for the response.
>>
>> So you're suggesting I manually send the TestRequest messages? I was
>> under the assumption the out-of-the-box QuickFix build would handle this
>> situation for me. Is there a setting to denote how long to wait before
>> sending the second TestRequest?
>>
>> You mentioned the CME would send a TestRequest if I wait the HeartBeatInt
>> -- why would they? I thought they only sent it when I waited *longer* than
>> the HeartBeatInt?
>>
>> Thanks again for your input.
>>
>> Rick
>>
>> On Thu, Oct 15, 2009 at 11:26 AM, John Vatianou <jva...@co...>wrote:
>>
>>>
>>> I'm actually on Autocert+ as we speak. Here's a Heartbeat example from a
>>> couple minutes ago...
>>>
>>> 20091015-16:17:54.473 :
>>> 8=FIX.4.2|9=106|35=0|34=701|49=9G19Z1N|50=apama_user|52=20091015-16:17:54.469|56=CME|57=G|142=CHICAGO|112=ID1255623474437|10=134|
>>> 20091015-16:18:24.941 :
>>> 8=FIX.4.2|9=86|35=0|34=702|49=9G19Z1N|50=apama_user|52=20091015-16:18:24.941|56=CME|57=G|142=CHICAGO|10=083|
>>> 20091015-16:18:25.238 :
>>> 8=FIX.4.2|9=82|35=0|34=742|369=702|52=20091015-16:18:25.221|49=CME|50=G|56=9G19Z1N|57=apama_user|10=001|
>>> 20091015-16:18:54.950 :
>>> 8=FIX.4.2|9=86|35=0|34=703|49=9G19Z1N|50=apama_user|52=20091015-16:18:54.950|56=CME|57=G|142=CHICAGO|10=087|
>>> 20091015-16:18:55.297 :
>>> 8=FIX.4.2|9=82|35=0|34=743|369=703|52=20091015-16:18:55.280|49=CME|50=G|56=9G19Z1N|57=apama_user|10=011|
>>> 20091015-16:19:24.953 :
>>> 8=FIX.4.2|9=86|35=0|34=704|49=9G19Z1N|50=apama_user|52=20091015-16:19:24.953|56=CME|57=G|142=CHICAGO|10=089|
>>>
>>> So no, it's not exactly 30 seconds, but the CME is not complaining.
>>>
>>> We had some problems getting by this test too. According to CSET, you do
>>> not have to wait a Heartbeat interval to send your two Test Requests and
>>> Logout messages. The CME-side is going to be totally unresponsive during
>>> this test, so your system has to drive the messaging to get past this test
>>> suite.
>>>
>>> If you wait for the Heartbeat interval, you'll get the behavior that is
>>> happening to you, where the CME sends a Test Request because the CME thinks
>>> you're not there anymore.
>>>
>>>
>>> On Thu, Oct 15, 2009 at 11:20 AM, Rick Lane <ric...@gm...> wrote:
>>>
>>>> John,
>>>> I'm failing the *Verify Test Request Procedure/Methodology* test
>>>> because the CME is sending me a TestRequest (because my heartbeat interval
>>>> is 30, but there's a gap between my individual heartbeats that is 30.060 (so
>>>> 30 seconds plus 60 milliseconds). The CME then sends me a TestRequest
>>>> because 30 seconds have gone by and they didn't get a heartbeat.
>>>>
>>>> You're saying in your log files if you just let your connection
>>>> heartbeat, the gap (in tag 52) between your heartbeat messages is exactly
>>>> HeartBeatInt seconds?
>>>>
>>>> Rick
>>>>
>>>>
>>>> On Thu, Oct 15, 2009 at 11:06 AM, John Vatianou <
>>>> jva...@co...> wrote:
>>>>
>>>>>
>>>>> Connamara just went through the Drop Copy certification and we're
>>>>> currently going through one for an order-sending adapter. We're using
>>>>> QuickFIX C++ and have not had any such issues. I'm curious, which Autocert+
>>>>> test are you having a problem with? Many of the tests require Heartbeats at
>>>>> the end, but I don't know of a specific Heartbeat test.
>>>>>
>>>>> John Vatianou
>>>>> Connamara Systems, LLC
>>>>> 200 West Jackson Boulevard, Suite 1340
>>>>> Chicago, Illinois 60606
>>>>> Direct: 312-235-6772
>>>>> Email: jva...@co...
>>>>> www.connamara.com
>>>>>
>>>>>
>>>>> On Thu, Oct 15, 2009 at 10:46 AM, Rick Lane <ric...@gm...>wrote:
>>>>>
>>>>>> QuickFIX Documentation:
>>>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> Greetings,
>>>>>> I'm still having issues with my HeartBeatInt (and it's also affecting
>>>>>> my TestRequest sending). The body of my toAdmin() function is below.
>>>>>>
>>>>>> So I thought that on my development laptop the 3 conditionals and the
>>>>>> three calls to setField() might be adding some extra time, but 40
>>>>>> milliseconds??? So I tested this out on my production environment -- 8-core
>>>>>> (nehalem) Dell R610, and sure enough, I'm still seeing these gaps.
>>>>>>
>>>>>> Unfortunately, there's no way I can test the speed if I *don't* make
>>>>>> those 3 calls to setField() because the CME will reject the message w/out
>>>>>> these fields. I sincerely hope that making these three calls isn't adding
>>>>>> this much time. Does anyone have any thoughts? Does anyone see similar
>>>>>> behavior (I would think that the gap between heartbeats should be
>>>>>> HeartBeatInt plus *maybe *1 or 2 ms). Is this simply the result of
>>>>>> .NET managed to unmanaged calls within QuickFix (please say no)?
>>>>>>
>>>>>> public void toAdmin(QuickFix.Message __p1, SessionID __p2)
>>>>>> {
>>>>>> if (__p1 is Logon) {
>>>>>> ILinkSession session = null;
>>>>>> if (m_SessionMap.TryGetValue(__p2.getSenderCompID(), out
>>>>>> session)) {
>>>>>> __p1.setField(new IntField(95,
>>>>>> session.sessionPassword.Length));
>>>>>> __p1.setField(new StringField(96,
>>>>>> session.sessionPassword));
>>>>>> }
>>>>>> } else if (__p1 is ResendRequest) {
>>>>>> ResendRequest request = (ResendRequest)__p1;
>>>>>> Session session = Session.lookupSession(__p2);
>>>>>> if(session != null){
>>>>>> int expectedNext = session.getExpectedTargetNum();
>>>>>>
>>>>>> }
>>>>>> MainFrame.AddStatusMessage("requesting iLink sequence numbers
>>>>>> " + request.getBeginSeqNo().getValue() + " through " +
>>>>>> request.getEndSeqNo().getValue());
>>>>>> m_LastResendRequestSeqNum = __p1.getHeader().getInt(34);
>>>>>> if (__p1.isSetField(369)) {
>>>>>> __p1.removeField(369); // in using the CME's "basic
>>>>>> resend" functionality, tag 369 cannot be present.
>>>>>> }
>>>>>> } else if (__p1 is Logout) {
>>>>>> if (!__p1.isSetField(789)) {
>>>>>> Session userSession = Session.lookupSession(__p2);
>>>>>> if (userSession != null) {
>>>>>> __p1.setInt(789, userSession.getExpectedTargetNum());
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>> if (!__p1.getHeader().isSetField(50)) {
>>>>>> __p1.getHeader().setField(new StringField(50, m_ServerID));
>>>>>> }
>>>>>> __p1.getHeader().setField(new CharField(57, 'G'));
>>>>>> __p1.getHeader().setField(new StringField(142, m_ServerID));
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11295 | 369=871 |
>>>>>> 52=20091015-15:10:31.355 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=124
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=872 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:10:50.771* | 56=CME | 57=G | 142=JBM152 | 10=229 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11296 | 369=872 |
>>>>>> 52=20091015-15:10:51.394 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=131
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=873 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:11:10.812* | 56=CME | 57=G | 142=JBM152 | 10=223 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11297 | 369=873 |
>>>>>> 52=20091015-15:11:11.435 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=874 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:11:30.852* | 56=CME | 57=G | 142=JBM152 | 10=230 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11298 | 369=874 |
>>>>>> 52=20091015-15:11:31.476 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=875 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:11:50.892* | 56=CME | 57=G | 142=JBM152 | 10=237 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11299 | 369=875 |
>>>>>> 52=20091015-15:11:51.517 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=876 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:12:10.934* | 56=CME | 57=G | 142=JBM152 | 10=232 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11300 | 369=876 |
>>>>>> 52=20091015-15:12:11.560 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=114
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=877 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:12:30.978* | 56=CME | 57=G | 142=JBM152 | 10=243 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11301 | 369=877 |
>>>>>> 52=20091015-15:12:31.600 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=113
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=878 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:12:50.018* | 56=CME | 57=G | 142=JBM152 | 10=231 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11302 | 369=878 |
>>>>>> 52=20091015-15:12:51.641 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=879 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:13:10.060* | 56=CME | 57=G | 142=JBM152 | 10=226 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11303 | 369=879 |
>>>>>> 52=20091015-15:13:11.683 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=127
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=880 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:13:30.102* | 56=CME | 57=G | 142=JBM152 | 10=217 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11304 | 369=880 |
>>>>>> 52=20091015-15:13:31.723 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=117
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=881 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:13:50.142* | 56=CME | 57=G | 142=JBM152 | 10=224 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11305 | 369=881 |
>>>>>> 52=20091015-15:13:51.764 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=882 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:14:10.184* | 56=CME | 57=G | 142=JBM152 | 10=228 |
>>>>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11306 | 369=882 |
>>>>>> 52=20091015-15:14:11.806 | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122
>>>>>> |
>>>>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=883 | 49=XXXXXXN | 50=JBM152 |
>>>>>> 52=20091015-*15:14:30.226* | 56=CME | 57=G | 142=JBM152 | 10=228 |
>>>>>>
>>>>>> On Wed, Oct 14, 2009 at 10:06 AM, Rick Lane <ric...@gm...>wrote:
>>>>>>
>>>>>>> Greetings,
>>>>>>> I'm attempting to do some certification on the CME (I like to
>>>>>>> re-certify every year or so to ensure no new changes break any parts of our
>>>>>>> platform), and they've introduced a new certification environment that is
>>>>>>> more sensitive than prior systems. There is an issue I'm seeing that seems
>>>>>>> to be causing a particular test to fail, and the issue is that the gap
>>>>>>> between my heartbeats is slightly over my pre-determined heartbeat interval,
>>>>>>> sometimes by 2 or 3 ms, but other times by 50-100 ms. What could be causing
>>>>>>> this delay?
>>>>>>>
>>>>>>> At first I thought maybe it was my file logging of messages, so I
>>>>>>> turned that off and the CME was still seeing this gap. It can't be a
>>>>>>> connection thing because the timestamps on my messages (when I have logging
>>>>>>> turned on) show gaps wider than 30 seconds, so it's something that's
>>>>>>> happening *before *the message leaves my box.
>>>>>>>
>>>>>>> Any thoughts?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rick
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>>>>> is the only developer event you need to attend this year. Jumpstart
>>>>>> your
>>>>>> developing skills, take BlackBerry mobile applications to market and
>>>>>> stay
>>>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>>>>> http://p.sf.net/sfu/devconference
>>>>>> _______________________________________________
>>>>>> Quickfix-developers mailing list
>>>>>> Qui...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Rick L. <ric...@gm...> - 2009-10-15 19:53:59
|
John, Thanks for the response. So you're suggesting I manually send the TestRequest messages? I was under the assumption the out-of-the-box QuickFix build would handle this situation for me. Is there a setting to denote how long to wait before sending the second TestRequest? You mentioned the CME would send a TestRequest if I wait the HeartBeatInt -- why would they? I thought they only sent it when I waited *longer* than the HeartBeatInt? Thanks again for your input. Rick On Thu, Oct 15, 2009 at 11:26 AM, John Vatianou <jva...@co...>wrote: > > I'm actually on Autocert+ as we speak. Here's a Heartbeat example from a > couple minutes ago... > > 20091015-16:17:54.473 : > 8=FIX.4.2|9=106|35=0|34=701|49=9G19Z1N|50=apama_user|52=20091015-16:17:54.469|56=CME|57=G|142=CHICAGO|112=ID1255623474437|10=134| > 20091015-16:18:24.941 : > 8=FIX.4.2|9=86|35=0|34=702|49=9G19Z1N|50=apama_user|52=20091015-16:18:24.941|56=CME|57=G|142=CHICAGO|10=083| > 20091015-16:18:25.238 : > 8=FIX.4.2|9=82|35=0|34=742|369=702|52=20091015-16:18:25.221|49=CME|50=G|56=9G19Z1N|57=apama_user|10=001| > 20091015-16:18:54.950 : > 8=FIX.4.2|9=86|35=0|34=703|49=9G19Z1N|50=apama_user|52=20091015-16:18:54.950|56=CME|57=G|142=CHICAGO|10=087| > 20091015-16:18:55.297 : > 8=FIX.4.2|9=82|35=0|34=743|369=703|52=20091015-16:18:55.280|49=CME|50=G|56=9G19Z1N|57=apama_user|10=011| > 20091015-16:19:24.953 : > 8=FIX.4.2|9=86|35=0|34=704|49=9G19Z1N|50=apama_user|52=20091015-16:19:24.953|56=CME|57=G|142=CHICAGO|10=089| > > So no, it's not exactly 30 seconds, but the CME is not complaining. > > We had some problems getting by this test too. According to CSET, you do > not have to wait a Heartbeat interval to send your two Test Requests and > Logout messages. The CME-side is going to be totally unresponsive during > this test, so your system has to drive the messaging to get past this test > suite. > > If you wait for the Heartbeat interval, you'll get the behavior that is > happening to you, where the CME sends a Test Request because the CME thinks > you're not there anymore. > > > On Thu, Oct 15, 2009 at 11:20 AM, Rick Lane <ric...@gm...> wrote: > >> John, >> I'm failing the *Verify Test Request Procedure/Methodology* test because >> the CME is sending me a TestRequest (because my heartbeat interval is 30, >> but there's a gap between my individual heartbeats that is 30.060 (so 30 >> seconds plus 60 milliseconds). The CME then sends me a TestRequest because >> 30 seconds have gone by and they didn't get a heartbeat. >> >> You're saying in your log files if you just let your connection heartbeat, >> the gap (in tag 52) between your heartbeat messages is exactly HeartBeatInt >> seconds? >> >> Rick >> >> >> On Thu, Oct 15, 2009 at 11:06 AM, John Vatianou <jva...@co...>wrote: >> >>> >>> Connamara just went through the Drop Copy certification and we're >>> currently going through one for an order-sending adapter. We're using >>> QuickFIX C++ and have not had any such issues. I'm curious, which Autocert+ >>> test are you having a problem with? Many of the tests require Heartbeats at >>> the end, but I don't know of a specific Heartbeat test. >>> >>> John Vatianou >>> Connamara Systems, LLC >>> 200 West Jackson Boulevard, Suite 1340 >>> Chicago, Illinois 60606 >>> Direct: 312-235-6772 >>> Email: jva...@co... >>> www.connamara.com >>> >>> >>> On Thu, Oct 15, 2009 at 10:46 AM, Rick Lane <ric...@gm...> wrote: >>> >>>> QuickFIX Documentation: >>>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>>> QuickFIX Support: http://www.quickfixengine.org/services.html >>>> >>>> >>>> >>>> Greetings, >>>> I'm still having issues with my HeartBeatInt (and it's also affecting my >>>> TestRequest sending). The body of my toAdmin() function is below. >>>> >>>> So I thought that on my development laptop the 3 conditionals and the >>>> three calls to setField() might be adding some extra time, but 40 >>>> milliseconds??? So I tested this out on my production environment -- 8-core >>>> (nehalem) Dell R610, and sure enough, I'm still seeing these gaps. >>>> >>>> Unfortunately, there's no way I can test the speed if I *don't* make >>>> those 3 calls to setField() because the CME will reject the message w/out >>>> these fields. I sincerely hope that making these three calls isn't adding >>>> this much time. Does anyone have any thoughts? Does anyone see similar >>>> behavior (I would think that the gap between heartbeats should be >>>> HeartBeatInt plus *maybe *1 or 2 ms). Is this simply the result of >>>> .NET managed to unmanaged calls within QuickFix (please say no)? >>>> >>>> public void toAdmin(QuickFix.Message __p1, SessionID __p2) >>>> { >>>> if (__p1 is Logon) { >>>> ILinkSession session = null; >>>> if (m_SessionMap.TryGetValue(__p2.getSenderCompID(), out >>>> session)) { >>>> __p1.setField(new IntField(95, >>>> session.sessionPassword.Length)); >>>> __p1.setField(new StringField(96, session.sessionPassword)); >>>> } >>>> } else if (__p1 is ResendRequest) { >>>> ResendRequest request = (ResendRequest)__p1; >>>> Session session = Session.lookupSession(__p2); >>>> if(session != null){ >>>> int expectedNext = session.getExpectedTargetNum(); >>>> >>>> } >>>> MainFrame.AddStatusMessage("requesting iLink sequence numbers " >>>> + request.getBeginSeqNo().getValue() + " through " + >>>> request.getEndSeqNo().getValue()); >>>> m_LastResendRequestSeqNum = __p1.getHeader().getInt(34); >>>> if (__p1.isSetField(369)) { >>>> __p1.removeField(369); // in using the CME's "basic resend" >>>> functionality, tag 369 cannot be present. >>>> } >>>> } else if (__p1 is Logout) { >>>> if (!__p1.isSetField(789)) { >>>> Session userSession = Session.lookupSession(__p2); >>>> if (userSession != null) { >>>> __p1.setInt(789, userSession.getExpectedTargetNum()); >>>> } >>>> } >>>> } >>>> if (!__p1.getHeader().isSetField(50)) { >>>> __p1.getHeader().setField(new StringField(50, m_ServerID)); >>>> } >>>> __p1.getHeader().setField(new CharField(57, 'G')); >>>> __p1.getHeader().setField(new StringField(142, m_ServerID)); >>>> } >>>> >>>> >>>> >>>> >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11295 | 369=871 | 52=20091015-15:10:31.355 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=124 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=872 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:10:50.771* | 56=CME | 57=G | 142=JBM152 | 10=229 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11296 | 369=872 | 52=20091015-15:10:51.394 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=131 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=873 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:11:10.812* | 56=CME | 57=G | 142=JBM152 | 10=223 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11297 | 369=873 | 52=20091015-15:11:11.435 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=874 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:11:30.852* | 56=CME | 57=G | 142=JBM152 | 10=230 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11298 | 369=874 | 52=20091015-15:11:31.476 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=875 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:11:50.892* | 56=CME | 57=G | 142=JBM152 | 10=237 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11299 | 369=875 | 52=20091015-15:11:51.517 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=876 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:12:10.934* | 56=CME | 57=G | 142=JBM152 | 10=232 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11300 | 369=876 | 52=20091015-15:12:11.560 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=114 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=877 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:12:30.978* | 56=CME | 57=G | 142=JBM152 | 10=243 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11301 | 369=877 | 52=20091015-15:12:31.600 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=113 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=878 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:12:50.018* | 56=CME | 57=G | 142=JBM152 | 10=231 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11302 | 369=878 | 52=20091015-15:12:51.641 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=879 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:13:10.060* | 56=CME | 57=G | 142=JBM152 | 10=226 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11303 | 369=879 | 52=20091015-15:13:11.683 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=127 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=880 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:13:30.102* | 56=CME | 57=G | 142=JBM152 | 10=217 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11304 | 369=880 | 52=20091015-15:13:31.723 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=117 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=881 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:13:50.142* | 56=CME | 57=G | 142=JBM152 | 10=224 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11305 | 369=881 | 52=20091015-15:13:51.764 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=882 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:14:10.184* | 56=CME | 57=G | 142=JBM152 | 10=228 | >>>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11306 | 369=882 | 52=20091015-15:14:11.806 >>>> | 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | >>>> 8=FIX.4.2 | 9=81 | 35=0 | 34=883 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>>> *15:14:30.226* | 56=CME | 57=G | 142=JBM152 | 10=228 | >>>> >>>> On Wed, Oct 14, 2009 at 10:06 AM, Rick Lane <ric...@gm...>wrote: >>>> >>>>> Greetings, >>>>> I'm attempting to do some certification on the CME (I like to >>>>> re-certify every year or so to ensure no new changes break any parts of our >>>>> platform), and they've introduced a new certification environment that is >>>>> more sensitive than prior systems. There is an issue I'm seeing that seems >>>>> to be causing a particular test to fail, and the issue is that the gap >>>>> between my heartbeats is slightly over my pre-determined heartbeat interval, >>>>> sometimes by 2 or 3 ms, but other times by 50-100 ms. What could be causing >>>>> this delay? >>>>> >>>>> At first I thought maybe it was my file logging of messages, so I >>>>> turned that off and the CME was still seeing this gap. It can't be a >>>>> connection thing because the timestamps on my messages (when I have logging >>>>> turned on) show gaps wider than 30 seconds, so it's something that's >>>>> happening *before *the message leaves my box. >>>>> >>>>> Any thoughts? >>>>> >>>>> Thanks, >>>>> Rick >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and >>>> stay >>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>> http://p.sf.net/sfu/devconference >>>> _______________________________________________ >>>> Quickfix-developers mailing list >>>> Qui...@li... >>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>>> >>> >>> >> > |
|
From: Andrei G. <an...@gm...> - 2009-10-15 19:03:09
|
On Thu, Oct 15, 2009 at 1:43 PM, George Hrysanthopoulos <ge...@so...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hello everyone, > > Quick question: > > From my acceptor app, I want to get the raw data stream for a message > (session or otherwise) > including all field separators (0x01), etc. > > I want to dump this to a file later. > > How do I get this raw message? > > Many thanks, > > George Hrysanthopoulos Use the QuickFIX::Message.toString() in the fromApp() and fromAdmin() callbacks. |
|
From: George H. <ge...@so...> - 2009-10-15 17:10:12
|
Hello everyone, Quick question: From my acceptor app, I want to get the raw data stream for a message (session or otherwise) including all field separators (0x01), etc. I want to dump this to a file later. How do I get this raw message? Many thanks, George Hrysanthopoulos |
|
From: John V. <jva...@co...> - 2009-10-15 17:06:34
|
Connamara just went through the Drop Copy certification and we're currently going through one for an order-sending adapter. We're using QuickFIX C++ and have not had any such issues. I'm curious, which Autocert+ test are you having a problem with? Many of the tests require Heartbeats at the end, but I don't know of a specific Heartbeat test. John Vatianou Connamara Systems, LLC 200 West Jackson Boulevard, Suite 1340 Chicago, Illinois 60606 Direct: 312-235-6772 Email: jva...@co... www.connamara.com On Thu, Oct 15, 2009 at 10:46 AM, Rick Lane <ric...@gm...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > Greetings, > I'm still having issues with my HeartBeatInt (and it's also affecting my > TestRequest sending). The body of my toAdmin() function is below. > > So I thought that on my development laptop the 3 conditionals and the three > calls to setField() might be adding some extra time, but 40 milliseconds??? > So I tested this out on my production environment -- 8-core (nehalem) Dell > R610, and sure enough, I'm still seeing these gaps. > > Unfortunately, there's no way I can test the speed if I *don't* make those > 3 calls to setField() because the CME will reject the message w/out these > fields. I sincerely hope that making these three calls isn't adding this > much time. Does anyone have any thoughts? Does anyone see similar behavior > (I would think that the gap between heartbeats should be HeartBeatInt plus > *maybe *1 or 2 ms). Is this simply the result of .NET managed to > unmanaged calls within QuickFix (please say no)? > > public void toAdmin(QuickFix.Message __p1, SessionID __p2) > { > if (__p1 is Logon) { > ILinkSession session = null; > if (m_SessionMap.TryGetValue(__p2.getSenderCompID(), out session)) > { > __p1.setField(new IntField(95, > session.sessionPassword.Length)); > __p1.setField(new StringField(96, session.sessionPassword)); > } > } else if (__p1 is ResendRequest) { > ResendRequest request = (ResendRequest)__p1; > Session session = Session.lookupSession(__p2); > if(session != null){ > int expectedNext = session.getExpectedTargetNum(); > > } > MainFrame.AddStatusMessage("requesting iLink sequence numbers " + > request.getBeginSeqNo().getValue() + " through " + > request.getEndSeqNo().getValue()); > m_LastResendRequestSeqNum = __p1.getHeader().getInt(34); > if (__p1.isSetField(369)) { > __p1.removeField(369); // in using the CME's "basic resend" > functionality, tag 369 cannot be present. > } > } else if (__p1 is Logout) { > if (!__p1.isSetField(789)) { > Session userSession = Session.lookupSession(__p2); > if (userSession != null) { > __p1.setInt(789, userSession.getExpectedTargetNum()); > } > } > } > if (!__p1.getHeader().isSetField(50)) { > __p1.getHeader().setField(new StringField(50, m_ServerID)); > } > __p1.getHeader().setField(new CharField(57, 'G')); > __p1.getHeader().setField(new StringField(142, m_ServerID)); > } > > > > > 8=FIX.4.2 | 9=80 | 35=0 | 34=11295 | 369=871 | 52=20091015-15:10:31.355 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=124 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=872 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:10:50.771* | 56=CME | 57=G | 142=JBM152 | 10=229 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11296 | 369=872 | 52=20091015-15:10:51.394 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=131 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=873 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:11:10.812* | 56=CME | 57=G | 142=JBM152 | 10=223 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11297 | 369=873 | 52=20091015-15:11:11.435 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=874 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:11:30.852* | 56=CME | 57=G | 142=JBM152 | 10=230 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11298 | 369=874 | 52=20091015-15:11:31.476 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=875 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:11:50.892* | 56=CME | 57=G | 142=JBM152 | 10=237 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11299 | 369=875 | 52=20091015-15:11:51.517 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=876 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:12:10.934* | 56=CME | 57=G | 142=JBM152 | 10=232 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11300 | 369=876 | 52=20091015-15:12:11.560 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=114 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=877 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:12:30.978* | 56=CME | 57=G | 142=JBM152 | 10=243 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11301 | 369=877 | 52=20091015-15:12:31.600 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=113 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=878 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:12:50.018* | 56=CME | 57=G | 142=JBM152 | 10=231 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11302 | 369=878 | 52=20091015-15:12:51.641 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=879 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:13:10.060* | 56=CME | 57=G | 142=JBM152 | 10=226 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11303 | 369=879 | 52=20091015-15:13:11.683 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=127 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=880 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:13:30.102* | 56=CME | 57=G | 142=JBM152 | 10=217 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11304 | 369=880 | 52=20091015-15:13:31.723 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=117 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=881 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:13:50.142* | 56=CME | 57=G | 142=JBM152 | 10=224 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11305 | 369=881 | 52=20091015-15:13:51.764 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=882 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:14:10.184* | 56=CME | 57=G | 142=JBM152 | 10=228 | > 8=FIX.4.2 | 9=80 | 35=0 | 34=11306 | 369=882 | 52=20091015-15:14:11.806 | > 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | > 8=FIX.4.2 | 9=81 | 35=0 | 34=883 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* > 15:14:30.226* | 56=CME | 57=G | 142=JBM152 | 10=228 | > > On Wed, Oct 14, 2009 at 10:06 AM, Rick Lane <ric...@gm...> wrote: > >> Greetings, >> I'm attempting to do some certification on the CME (I like to re-certify >> every year or so to ensure no new changes break any parts of our platform), >> and they've introduced a new certification environment that is more >> sensitive than prior systems. There is an issue I'm seeing that seems to be >> causing a particular test to fail, and the issue is that the gap between my >> heartbeats is slightly over my pre-determined heartbeat interval, sometimes >> by 2 or 3 ms, but other times by 50-100 ms. What could be causing this >> delay? >> >> At first I thought maybe it was my file logging of messages, so I turned >> that off and the CME was still seeing this gap. It can't be a connection >> thing because the timestamps on my messages (when I have logging turned on) >> show gaps wider than 30 seconds, so it's something that's happening *before >> *the message leaves my box. >> >> Any thoughts? >> >> Thanks, >> Rick >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: John V. <jva...@co...> - 2009-10-15 16:49:55
|
I'm actually on Autocert+ as we speak. Here's a Heartbeat example from a couple minutes ago... 20091015-16:17:54.473 : 8=FIX.4.2|9=106|35=0|34=701|49=9G19Z1N|50=apama_user|52=20091015-16:17:54.469|56=CME|57=G|142=CHICAGO|112=ID1255623474437|10=134| 20091015-16:18:24.941 : 8=FIX.4.2|9=86|35=0|34=702|49=9G19Z1N|50=apama_user|52=20091015-16:18:24.941|56=CME|57=G|142=CHICAGO|10=083| 20091015-16:18:25.238 : 8=FIX.4.2|9=82|35=0|34=742|369=702|52=20091015-16:18:25.221|49=CME|50=G|56=9G19Z1N|57=apama_user|10=001| 20091015-16:18:54.950 : 8=FIX.4.2|9=86|35=0|34=703|49=9G19Z1N|50=apama_user|52=20091015-16:18:54.950|56=CME|57=G|142=CHICAGO|10=087| 20091015-16:18:55.297 : 8=FIX.4.2|9=82|35=0|34=743|369=703|52=20091015-16:18:55.280|49=CME|50=G|56=9G19Z1N|57=apama_user|10=011| 20091015-16:19:24.953 : 8=FIX.4.2|9=86|35=0|34=704|49=9G19Z1N|50=apama_user|52=20091015-16:19:24.953|56=CME|57=G|142=CHICAGO|10=089| So no, it's not exactly 30 seconds, but the CME is not complaining. We had some problems getting by this test too. According to CSET, you do not have to wait a Heartbeat interval to send your two Test Requests and Logout messages. The CME-side is going to be totally unresponsive during this test, so your system has to drive the messaging to get past this test suite. If you wait for the Heartbeat interval, you'll get the behavior that is happening to you, where the CME sends a Test Request because the CME thinks you're not there anymore. On Thu, Oct 15, 2009 at 11:20 AM, Rick Lane <ric...@gm...> wrote: > John, > I'm failing the *Verify Test Request Procedure/Methodology* test because > the CME is sending me a TestRequest (because my heartbeat interval is 30, > but there's a gap between my individual heartbeats that is 30.060 (so 30 > seconds plus 60 milliseconds). The CME then sends me a TestRequest because > 30 seconds have gone by and they didn't get a heartbeat. > > You're saying in your log files if you just let your connection heartbeat, > the gap (in tag 52) between your heartbeat messages is exactly HeartBeatInt > seconds? > > Rick > > > On Thu, Oct 15, 2009 at 11:06 AM, John Vatianou <jva...@co...>wrote: > >> >> Connamara just went through the Drop Copy certification and we're >> currently going through one for an order-sending adapter. We're using >> QuickFIX C++ and have not had any such issues. I'm curious, which Autocert+ >> test are you having a problem with? Many of the tests require Heartbeats at >> the end, but I don't know of a specific Heartbeat test. >> >> John Vatianou >> Connamara Systems, LLC >> 200 West Jackson Boulevard, Suite 1340 >> Chicago, Illinois 60606 >> Direct: 312-235-6772 >> Email: jva...@co... >> www.connamara.com >> >> >> On Thu, Oct 15, 2009 at 10:46 AM, Rick Lane <ric...@gm...> wrote: >> >>> QuickFIX Documentation: >>> http://www.quickfixengine.org/quickfix/doc/html/index.html >>> QuickFIX Support: http://www.quickfixengine.org/services.html >>> >>> >>> >>> Greetings, >>> I'm still having issues with my HeartBeatInt (and it's also affecting my >>> TestRequest sending). The body of my toAdmin() function is below. >>> >>> So I thought that on my development laptop the 3 conditionals and the >>> three calls to setField() might be adding some extra time, but 40 >>> milliseconds??? So I tested this out on my production environment -- 8-core >>> (nehalem) Dell R610, and sure enough, I'm still seeing these gaps. >>> >>> Unfortunately, there's no way I can test the speed if I *don't* make >>> those 3 calls to setField() because the CME will reject the message w/out >>> these fields. I sincerely hope that making these three calls isn't adding >>> this much time. Does anyone have any thoughts? Does anyone see similar >>> behavior (I would think that the gap between heartbeats should be >>> HeartBeatInt plus *maybe *1 or 2 ms). Is this simply the result of .NET >>> managed to unmanaged calls within QuickFix (please say no)? >>> >>> public void toAdmin(QuickFix.Message __p1, SessionID __p2) >>> { >>> if (__p1 is Logon) { >>> ILinkSession session = null; >>> if (m_SessionMap.TryGetValue(__p2.getSenderCompID(), out >>> session)) { >>> __p1.setField(new IntField(95, >>> session.sessionPassword.Length)); >>> __p1.setField(new StringField(96, session.sessionPassword)); >>> } >>> } else if (__p1 is ResendRequest) { >>> ResendRequest request = (ResendRequest)__p1; >>> Session session = Session.lookupSession(__p2); >>> if(session != null){ >>> int expectedNext = session.getExpectedTargetNum(); >>> >>> } >>> MainFrame.AddStatusMessage("requesting iLink sequence numbers " + >>> request.getBeginSeqNo().getValue() + " through " + >>> request.getEndSeqNo().getValue()); >>> m_LastResendRequestSeqNum = __p1.getHeader().getInt(34); >>> if (__p1.isSetField(369)) { >>> __p1.removeField(369); // in using the CME's "basic resend" >>> functionality, tag 369 cannot be present. >>> } >>> } else if (__p1 is Logout) { >>> if (!__p1.isSetField(789)) { >>> Session userSession = Session.lookupSession(__p2); >>> if (userSession != null) { >>> __p1.setInt(789, userSession.getExpectedTargetNum()); >>> } >>> } >>> } >>> if (!__p1.getHeader().isSetField(50)) { >>> __p1.getHeader().setField(new StringField(50, m_ServerID)); >>> } >>> __p1.getHeader().setField(new CharField(57, 'G')); >>> __p1.getHeader().setField(new StringField(142, m_ServerID)); >>> } >>> >>> >>> >>> >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11295 | 369=871 | 52=20091015-15:10:31.355 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=124 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=872 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:10:50.771* | 56=CME | 57=G | 142=JBM152 | 10=229 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11296 | 369=872 | 52=20091015-15:10:51.394 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=131 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=873 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:11:10.812* | 56=CME | 57=G | 142=JBM152 | 10=223 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11297 | 369=873 | 52=20091015-15:11:11.435 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=874 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:11:30.852* | 56=CME | 57=G | 142=JBM152 | 10=230 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11298 | 369=874 | 52=20091015-15:11:31.476 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=875 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:11:50.892* | 56=CME | 57=G | 142=JBM152 | 10=237 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11299 | 369=875 | 52=20091015-15:11:51.517 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=876 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:12:10.934* | 56=CME | 57=G | 142=JBM152 | 10=232 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11300 | 369=876 | 52=20091015-15:12:11.560 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=114 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=877 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:12:30.978* | 56=CME | 57=G | 142=JBM152 | 10=243 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11301 | 369=877 | 52=20091015-15:12:31.600 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=113 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=878 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:12:50.018* | 56=CME | 57=G | 142=JBM152 | 10=231 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11302 | 369=878 | 52=20091015-15:12:51.641 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=879 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:13:10.060* | 56=CME | 57=G | 142=JBM152 | 10=226 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11303 | 369=879 | 52=20091015-15:13:11.683 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=127 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=880 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:13:30.102* | 56=CME | 57=G | 142=JBM152 | 10=217 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11304 | 369=880 | 52=20091015-15:13:31.723 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=117 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=881 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:13:50.142* | 56=CME | 57=G | 142=JBM152 | 10=224 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11305 | 369=881 | 52=20091015-15:13:51.764 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=882 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:14:10.184* | 56=CME | 57=G | 142=JBM152 | 10=228 | >>> 8=FIX.4.2 | 9=80 | 35=0 | 34=11306 | 369=882 | 52=20091015-15:14:11.806 | >>> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | >>> 8=FIX.4.2 | 9=81 | 35=0 | 34=883 | 49=XXXXXXN | 50=JBM152 | 52=20091015- >>> *15:14:30.226* | 56=CME | 57=G | 142=JBM152 | 10=228 | >>> >>> On Wed, Oct 14, 2009 at 10:06 AM, Rick Lane <ric...@gm...> wrote: >>> >>>> Greetings, >>>> I'm attempting to do some certification on the CME (I like to re-certify >>>> every year or so to ensure no new changes break any parts of our platform), >>>> and they've introduced a new certification environment that is more >>>> sensitive than prior systems. There is an issue I'm seeing that seems to be >>>> causing a particular test to fail, and the issue is that the gap between my >>>> heartbeats is slightly over my pre-determined heartbeat interval, sometimes >>>> by 2 or 3 ms, but other times by 50-100 ms. What could be causing this >>>> delay? >>>> >>>> At first I thought maybe it was my file logging of messages, so I turned >>>> that off and the CME was still seeing this gap. It can't be a connection >>>> thing because the timestamps on my messages (when I have logging turned on) >>>> show gaps wider than 30 seconds, so it's something that's happening *before >>>> *the message leaves my box. >>>> >>>> Any thoughts? >>>> >>>> Thanks, >>>> Rick >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> Quickfix-developers mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>> >> >> > |
|
From: Rick L. <ric...@gm...> - 2009-10-15 16:20:53
|
John, I'm failing the *Verify Test Request Procedure/Methodology* test because the CME is sending me a TestRequest (because my heartbeat interval is 30, but there's a gap between my individual heartbeats that is 30.060 (so 30 seconds plus 60 milliseconds). The CME then sends me a TestRequest because 30 seconds have gone by and they didn't get a heartbeat. You're saying in your log files if you just let your connection heartbeat, the gap (in tag 52) between your heartbeat messages is exactly HeartBeatInt seconds? Rick On Thu, Oct 15, 2009 at 11:06 AM, John Vatianou <jva...@co...>wrote: > > Connamara just went through the Drop Copy certification and we're currently > going through one for an order-sending adapter. We're using QuickFIX C++ > and have not had any such issues. I'm curious, which Autocert+ test are you > having a problem with? Many of the tests require Heartbeats at the end, but > I don't know of a specific Heartbeat test. > > John Vatianou > Connamara Systems, LLC > 200 West Jackson Boulevard, Suite 1340 > Chicago, Illinois 60606 > Direct: 312-235-6772 > Email: jva...@co... > www.connamara.com > > > On Thu, Oct 15, 2009 at 10:46 AM, Rick Lane <ric...@gm...> wrote: > >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> >> >> Greetings, >> I'm still having issues with my HeartBeatInt (and it's also affecting my >> TestRequest sending). The body of my toAdmin() function is below. >> >> So I thought that on my development laptop the 3 conditionals and the >> three calls to setField() might be adding some extra time, but 40 >> milliseconds??? So I tested this out on my production environment -- 8-core >> (nehalem) Dell R610, and sure enough, I'm still seeing these gaps. >> >> Unfortunately, there's no way I can test the speed if I *don't* make those >> 3 calls to setField() because the CME will reject the message w/out these >> fields. I sincerely hope that making these three calls isn't adding this >> much time. Does anyone have any thoughts? Does anyone see similar behavior >> (I would think that the gap between heartbeats should be HeartBeatInt plus >> *maybe *1 or 2 ms). Is this simply the result of .NET managed to >> unmanaged calls within QuickFix (please say no)? >> >> public void toAdmin(QuickFix.Message __p1, SessionID __p2) >> { >> if (__p1 is Logon) { >> ILinkSession session = null; >> if (m_SessionMap.TryGetValue(__p2.getSenderCompID(), out session)) >> { >> __p1.setField(new IntField(95, >> session.sessionPassword.Length)); >> __p1.setField(new StringField(96, session.sessionPassword)); >> } >> } else if (__p1 is ResendRequest) { >> ResendRequest request = (ResendRequest)__p1; >> Session session = Session.lookupSession(__p2); >> if(session != null){ >> int expectedNext = session.getExpectedTargetNum(); >> >> } >> MainFrame.AddStatusMessage("requesting iLink sequence numbers " + >> request.getBeginSeqNo().getValue() + " through " + >> request.getEndSeqNo().getValue()); >> m_LastResendRequestSeqNum = __p1.getHeader().getInt(34); >> if (__p1.isSetField(369)) { >> __p1.removeField(369); // in using the CME's "basic resend" >> functionality, tag 369 cannot be present. >> } >> } else if (__p1 is Logout) { >> if (!__p1.isSetField(789)) { >> Session userSession = Session.lookupSession(__p2); >> if (userSession != null) { >> __p1.setInt(789, userSession.getExpectedTargetNum()); >> } >> } >> } >> if (!__p1.getHeader().isSetField(50)) { >> __p1.getHeader().setField(new StringField(50, m_ServerID)); >> } >> __p1.getHeader().setField(new CharField(57, 'G')); >> __p1.getHeader().setField(new StringField(142, m_ServerID)); >> } >> >> >> >> >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11295 | 369=871 | 52=20091015-15:10:31.355 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=124 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=872 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:10:50.771* | 56=CME | 57=G | 142=JBM152 | 10=229 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11296 | 369=872 | 52=20091015-15:10:51.394 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=131 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=873 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:11:10.812* | 56=CME | 57=G | 142=JBM152 | 10=223 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11297 | 369=873 | 52=20091015-15:11:11.435 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=874 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:11:30.852* | 56=CME | 57=G | 142=JBM152 | 10=230 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11298 | 369=874 | 52=20091015-15:11:31.476 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=875 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:11:50.892* | 56=CME | 57=G | 142=JBM152 | 10=237 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11299 | 369=875 | 52=20091015-15:11:51.517 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=876 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:12:10.934* | 56=CME | 57=G | 142=JBM152 | 10=232 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11300 | 369=876 | 52=20091015-15:12:11.560 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=114 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=877 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:12:30.978* | 56=CME | 57=G | 142=JBM152 | 10=243 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11301 | 369=877 | 52=20091015-15:12:31.600 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=113 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=878 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:12:50.018* | 56=CME | 57=G | 142=JBM152 | 10=231 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11302 | 369=878 | 52=20091015-15:12:51.641 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=879 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:13:10.060* | 56=CME | 57=G | 142=JBM152 | 10=226 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11303 | 369=879 | 52=20091015-15:13:11.683 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=127 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=880 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:13:30.102* | 56=CME | 57=G | 142=JBM152 | 10=217 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11304 | 369=880 | 52=20091015-15:13:31.723 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=117 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=881 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:13:50.142* | 56=CME | 57=G | 142=JBM152 | 10=224 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11305 | 369=881 | 52=20091015-15:13:51.764 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=882 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:14:10.184* | 56=CME | 57=G | 142=JBM152 | 10=228 | >> 8=FIX.4.2 | 9=80 | 35=0 | 34=11306 | 369=882 | 52=20091015-15:14:11.806 | >> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 | >> 8=FIX.4.2 | 9=81 | 35=0 | 34=883 | 49=XXXXXXN | 50=JBM152 | 52=20091015-* >> 15:14:30.226* | 56=CME | 57=G | 142=JBM152 | 10=228 | >> >> On Wed, Oct 14, 2009 at 10:06 AM, Rick Lane <ric...@gm...> wrote: >> >>> Greetings, >>> I'm attempting to do some certification on the CME (I like to re-certify >>> every year or so to ensure no new changes break any parts of our platform), >>> and they've introduced a new certification environment that is more >>> sensitive than prior systems. There is an issue I'm seeing that seems to be >>> causing a particular test to fail, and the issue is that the gap between my >>> heartbeats is slightly over my pre-determined heartbeat interval, sometimes >>> by 2 or 3 ms, but other times by 50-100 ms. What could be causing this >>> delay? >>> >>> At first I thought maybe it was my file logging of messages, so I turned >>> that off and the CME was still seeing this gap. It can't be a connection >>> thing because the timestamps on my messages (when I have logging turned on) >>> show gaps wider than 30 seconds, so it's something that's happening *before >>> *the message leaves my box. >>> >>> Any thoughts? >>> >>> Thanks, >>> Rick >>> >> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> > > |
|
From: Rick L. <ric...@gm...> - 2009-10-15 15:53:45
|
One thing to note (and I suppose I should've done this sooner), but if I
time the toAdmin() function, it's definitely not taking 40ms -- in fact it's
immeasurable. It's not scientific, but I'm measuring the time using
DateTime and getting 0 total milliseconds.
On Thu, Oct 15, 2009 at 10:46 AM, Rick Lane <ric...@gm...> wrote:
> Greetings,
> I'm still having issues with my HeartBeatInt (and it's also affecting my
> TestRequest sending). The body of my toAdmin() function is below.
>
> So I thought that on my development laptop the 3 conditionals and the three
> calls to setField() might be adding some extra time, but 40 milliseconds???
> So I tested this out on my production environment -- 8-core (nehalem) Dell
> R610, and sure enough, I'm still seeing these gaps.
>
> Unfortunately, there's no way I can test the speed if I *don't* make those
> 3 calls to setField() because the CME will reject the message w/out these
> fields. I sincerely hope that making these three calls isn't adding this
> much time. Does anyone have any thoughts? Does anyone see similar behavior
> (I would think that the gap between heartbeats should be HeartBeatInt plus
> *maybe *1 or 2 ms). Is this simply the result of .NET managed to
> unmanaged calls within QuickFix (please say no)?
>
> public void toAdmin(QuickFix.Message __p1, SessionID __p2)
> {
> if (__p1 is Logon) {
> ILinkSession session = null;
> if (m_SessionMap.TryGetValue(__p2.getSenderCompID(), out session))
> {
> __p1.setField(new IntField(95,
> session.sessionPassword.Length));
> __p1.setField(new StringField(96, session.sessionPassword));
> }
> } else if (__p1 is ResendRequest) {
> ResendRequest request = (ResendRequest)__p1;
> Session session = Session.lookupSession(__p2);
> if(session != null){
> int expectedNext = session.getExpectedTargetNum();
>
> }
> MainFrame.AddStatusMessage("requesting iLink sequence numbers " +
> request.getBeginSeqNo().getValue() + " through " +
> request.getEndSeqNo().getValue());
> m_LastResendRequestSeqNum = __p1.getHeader().getInt(34);
> if (__p1.isSetField(369)) {
> __p1.removeField(369); // in using the CME's "basic resend"
> functionality, tag 369 cannot be present.
> }
> } else if (__p1 is Logout) {
> if (!__p1.isSetField(789)) {
> Session userSession = Session.lookupSession(__p2);
> if (userSession != null) {
> __p1.setInt(789, userSession.getExpectedTargetNum());
> }
> }
> }
> if (!__p1.getHeader().isSetField(50)) {
> __p1.getHeader().setField(new StringField(50, m_ServerID));
> }
> __p1.getHeader().setField(new CharField(57, 'G'));
> __p1.getHeader().setField(new StringField(142, m_ServerID));
> }
>
>
>
>
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11295 | 369=871 | 52=20091015-15:10:31.355 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=124 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=872 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:10:50.771* | 56=CME | 57=G | 142=JBM152 | 10=229 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11296 | 369=872 | 52=20091015-15:10:51.394 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=131 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=873 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:11:10.812* | 56=CME | 57=G | 142=JBM152 | 10=223 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11297 | 369=873 | 52=20091015-15:11:11.435 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=874 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:11:30.852* | 56=CME | 57=G | 142=JBM152 | 10=230 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11298 | 369=874 | 52=20091015-15:11:31.476 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=875 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:11:50.892* | 56=CME | 57=G | 142=JBM152 | 10=237 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11299 | 369=875 | 52=20091015-15:11:51.517 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=876 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:12:10.934* | 56=CME | 57=G | 142=JBM152 | 10=232 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11300 | 369=876 | 52=20091015-15:12:11.560 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=114 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=877 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:12:30.978* | 56=CME | 57=G | 142=JBM152 | 10=243 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11301 | 369=877 | 52=20091015-15:12:31.600 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=113 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=878 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:12:50.018* | 56=CME | 57=G | 142=JBM152 | 10=231 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11302 | 369=878 | 52=20091015-15:12:51.641 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=879 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:13:10.060* | 56=CME | 57=G | 142=JBM152 | 10=226 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11303 | 369=879 | 52=20091015-15:13:11.683 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=127 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=880 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:13:30.102* | 56=CME | 57=G | 142=JBM152 | 10=217 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11304 | 369=880 | 52=20091015-15:13:31.723 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=117 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=881 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:13:50.142* | 56=CME | 57=G | 142=JBM152 | 10=224 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11305 | 369=881 | 52=20091015-15:13:51.764 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=882 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:14:10.184* | 56=CME | 57=G | 142=JBM152 | 10=228 |
> 8=FIX.4.2 | 9=80 | 35=0 | 34=11306 | 369=882 | 52=20091015-15:14:11.806 |
> 49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 |
> 8=FIX.4.2 | 9=81 | 35=0 | 34=883 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
> 15:14:30.226* | 56=CME | 57=G | 142=JBM152 | 10=228 |
>
> On Wed, Oct 14, 2009 at 10:06 AM, Rick Lane <ric...@gm...> wrote:
>
>> Greetings,
>> I'm attempting to do some certification on the CME (I like to re-certify
>> every year or so to ensure no new changes break any parts of our platform),
>> and they've introduced a new certification environment that is more
>> sensitive than prior systems. There is an issue I'm seeing that seems to be
>> causing a particular test to fail, and the issue is that the gap between my
>> heartbeats is slightly over my pre-determined heartbeat interval, sometimes
>> by 2 or 3 ms, but other times by 50-100 ms. What could be causing this
>> delay?
>>
>> At first I thought maybe it was my file logging of messages, so I turned
>> that off and the CME was still seeing this gap. It can't be a connection
>> thing because the timestamps on my messages (when I have logging turned on)
>> show gaps wider than 30 seconds, so it's something that's happening *before
>> *the message leaves my box.
>>
>> Any thoughts?
>>
>> Thanks,
>> Rick
>>
>
>
|
|
From: Rick L. <ric...@gm...> - 2009-10-15 15:47:24
|
Greetings,
I'm still having issues with my HeartBeatInt (and it's also affecting my
TestRequest sending). The body of my toAdmin() function is below.
So I thought that on my development laptop the 3 conditionals and the three
calls to setField() might be adding some extra time, but 40 milliseconds???
So I tested this out on my production environment -- 8-core (nehalem) Dell
R610, and sure enough, I'm still seeing these gaps.
Unfortunately, there's no way I can test the speed if I *don't* make those 3
calls to setField() because the CME will reject the message w/out these
fields. I sincerely hope that making these three calls isn't adding this
much time. Does anyone have any thoughts? Does anyone see similar behavior
(I would think that the gap between heartbeats should be HeartBeatInt plus *
maybe *1 or 2 ms). Is this simply the result of .NET managed to unmanaged
calls within QuickFix (please say no)?
public void toAdmin(QuickFix.Message __p1, SessionID __p2)
{
if (__p1 is Logon) {
ILinkSession session = null;
if (m_SessionMap.TryGetValue(__p2.getSenderCompID(), out session)) {
__p1.setField(new IntField(95, session.sessionPassword.Length));
__p1.setField(new StringField(96, session.sessionPassword));
}
} else if (__p1 is ResendRequest) {
ResendRequest request = (ResendRequest)__p1;
Session session = Session.lookupSession(__p2);
if(session != null){
int expectedNext = session.getExpectedTargetNum();
}
MainFrame.AddStatusMessage("requesting iLink sequence numbers " +
request.getBeginSeqNo().getValue() + " through " +
request.getEndSeqNo().getValue());
m_LastResendRequestSeqNum = __p1.getHeader().getInt(34);
if (__p1.isSetField(369)) {
__p1.removeField(369); // in using the CME's "basic resend"
functionality, tag 369 cannot be present.
}
} else if (__p1 is Logout) {
if (!__p1.isSetField(789)) {
Session userSession = Session.lookupSession(__p2);
if (userSession != null) {
__p1.setInt(789, userSession.getExpectedTargetNum());
}
}
}
if (!__p1.getHeader().isSetField(50)) {
__p1.getHeader().setField(new StringField(50, m_ServerID));
}
__p1.getHeader().setField(new CharField(57, 'G'));
__p1.getHeader().setField(new StringField(142, m_ServerID));
}
8=FIX.4.2 | 9=80 | 35=0 | 34=11295 | 369=871 | 52=20091015-15:10:31.355 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=124 |
8=FIX.4.2 | 9=81 | 35=0 | 34=872 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:10:50.771* | 56=CME | 57=G | 142=JBM152 | 10=229 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11296 | 369=872 | 52=20091015-15:10:51.394 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=131 |
8=FIX.4.2 | 9=81 | 35=0 | 34=873 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:11:10.812* | 56=CME | 57=G | 142=JBM152 | 10=223 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11297 | 369=873 | 52=20091015-15:11:11.435 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 |
8=FIX.4.2 | 9=81 | 35=0 | 34=874 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:11:30.852* | 56=CME | 57=G | 142=JBM152 | 10=230 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11298 | 369=874 | 52=20091015-15:11:31.476 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 |
8=FIX.4.2 | 9=81 | 35=0 | 34=875 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:11:50.892* | 56=CME | 57=G | 142=JBM152 | 10=237 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11299 | 369=875 | 52=20091015-15:11:51.517 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=135 |
8=FIX.4.2 | 9=81 | 35=0 | 34=876 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:12:10.934* | 56=CME | 57=G | 142=JBM152 | 10=232 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11300 | 369=876 | 52=20091015-15:12:11.560 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=114 |
8=FIX.4.2 | 9=81 | 35=0 | 34=877 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:12:30.978* | 56=CME | 57=G | 142=JBM152 | 10=243 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11301 | 369=877 | 52=20091015-15:12:31.600 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=113 |
8=FIX.4.2 | 9=81 | 35=0 | 34=878 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:12:50.018* | 56=CME | 57=G | 142=JBM152 | 10=231 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11302 | 369=878 | 52=20091015-15:12:51.641 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 |
8=FIX.4.2 | 9=81 | 35=0 | 34=879 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:13:10.060* | 56=CME | 57=G | 142=JBM152 | 10=226 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11303 | 369=879 | 52=20091015-15:13:11.683 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=127 |
8=FIX.4.2 | 9=81 | 35=0 | 34=880 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:13:30.102* | 56=CME | 57=G | 142=JBM152 | 10=217 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11304 | 369=880 | 52=20091015-15:13:31.723 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=117 |
8=FIX.4.2 | 9=81 | 35=0 | 34=881 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:13:50.142* | 56=CME | 57=G | 142=JBM152 | 10=224 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11305 | 369=881 | 52=20091015-15:13:51.764 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=126 |
8=FIX.4.2 | 9=81 | 35=0 | 34=882 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:14:10.184* | 56=CME | 57=G | 142=JBM152 | 10=228 |
8=FIX.4.2 | 9=80 | 35=0 | 34=11306 | 369=882 | 52=20091015-15:14:11.806 |
49=CME | 50=G | 56=XXXXXXN | 57=JBM152 | 10=122 |
8=FIX.4.2 | 9=81 | 35=0 | 34=883 | 49=XXXXXXN | 50=JBM152 | 52=20091015-*
15:14:30.226* | 56=CME | 57=G | 142=JBM152 | 10=228 |
On Wed, Oct 14, 2009 at 10:06 AM, Rick Lane <ric...@gm...> wrote:
> Greetings,
> I'm attempting to do some certification on the CME (I like to re-certify
> every year or so to ensure no new changes break any parts of our platform),
> and they've introduced a new certification environment that is more
> sensitive than prior systems. There is an issue I'm seeing that seems to be
> causing a particular test to fail, and the issue is that the gap between my
> heartbeats is slightly over my pre-determined heartbeat interval, sometimes
> by 2 or 3 ms, but other times by 50-100 ms. What could be causing this
> delay?
>
> At first I thought maybe it was my file logging of messages, so I turned
> that off and the CME was still seeing this gap. It can't be a connection
> thing because the timestamps on my messages (when I have logging turned on)
> show gaps wider than 30 seconds, so it's something that's happening *before
> *the message leaves my box.
>
> Any thoughts?
>
> Thanks,
> Rick
>
|
|
From: Rick L. <ric...@gm...> - 2009-10-14 15:07:32
|
Greetings, I'm attempting to do some certification on the CME (I like to re-certify every year or so to ensure no new changes break any parts of our platform), and they've introduced a new certification environment that is more sensitive than prior systems. There is an issue I'm seeing that seems to be causing a particular test to fail, and the issue is that the gap between my heartbeats is slightly over my pre-determined heartbeat interval, sometimes by 2 or 3 ms, but other times by 50-100 ms. What could be causing this delay? At first I thought maybe it was my file logging of messages, so I turned that off and the CME was still seeing this gap. It can't be a connection thing because the timestamps on my messages (when I have logging turned on) show gaps wider than 30 seconds, so it's something that's happening *before *the message leaves my box. Any thoughts? Thanks, Rick |
|
From: <ch...@gm...> - 2009-10-13 03:37:56
|
Hi, i am using Stunnel to send quickfix messages on SSL to FIX server. I am struck with some errors. In the STUNNEL log i am getting the follow error: 2009.10.13 08:57:05 LOG3[4028:2532]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_ HELLO:unknown protocol And in the Quickfix Logs are also shown below: 20091013-02:57:01 : Created session 20091013-02:57:05 : Connecting to 127.0.0.1 on port 9000 20091013-02:57:05 : Initiated logon request 20091013-02:57:05 : Socket Error: An existing connection was forcibly closed by the remote host. 20091013-02:57:05 : Disconnecting 20091013-02:57:06 : Connecting to 127.0.0.1 on port 9000 20091013-02:57:06 : Initiated logon request 20091013-02:57:06 : Socket Error: An existing connection was forcibly closed by the remote host. 20091013-02:57:06 : Disconnecting 20091013-02:57:26 : Connecting to 127.0.0.1 on port 9000 20091013-02:57:26 : Initiated logon request 20091013-02:57:26 : Socket Error: An existing connection was forcibly closed by the remote host. Can any one Guide me what is causing porblem in this?? -- View this message in context: http://www.nabble.com/Unable-to-create-connection-on-SSL-with-FIX-Server-tp25866720p25866720.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: <ch...@gm...> - 2009-10-13 03:31:47
|
Hi, i am using Stunnel to send quickfix messages on SSL to FIX server. I am struck with some errors. In the SSL log i am getting the follow error: 2009.10.13 08:57:05 LOG3[4028:2532]: SSL_accept: 140760FC: error:140760FC:SSL routines:SSL23_GET_CLIENT_ HELLO:unknown protocol And in the Quickfix Logs are also shown below: 20091013-02:57:01 : Created session 20091013-02:57:05 : Connecting to 127.0.0.1 on port 9000 20091013-02:57:05 : Initiated logon request 20091013-02:57:05 : Socket Error: An existing connection was forcibly closed by the remote host. 20091013-02:57:05 : Disconnecting 20091013-02:57:06 : Connecting to 127.0.0.1 on port 9000 20091013-02:57:06 : Initiated logon request 20091013-02:57:06 : Socket Error: An existing connection was forcibly closed by the remote host. 20091013-02:57:06 : Disconnecting 20091013-02:57:26 : Connecting to 127.0.0.1 on port 9000 20091013-02:57:26 : Initiated logon request 20091013-02:57:26 : Socket Error: An existing connection was forcibly closed by the remote host. Can any one Guide me what is causing porblem in this?? -- View this message in context: http://www.nabble.com/Unable-to-create-connection-on-SSL-with-FIX-Server-tp25866681p25866681.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: Fabio R. <FRe...@1e...> - 2009-10-12 13:52:06
|
Hi Together I try to use quickfix within an application i want to sign, that i can use it from the GAC. But i can't build my solution, because of the quickfix assemblies, which aren't signed. Did anyone have the same problem and can give me a quick solution please? Thank you. Best regards Fabio |
|
From: <ch...@gm...> - 2009-10-11 12:40:26
|
I am continuously getting the logout response for my LOGON message. Below are the log files. can any one tel me whats the possible issue that i am not getting LOGON? Also when i write the IP address with SLL like "ssl://72.217.201.89" for SocketConnectHost in the config file message it the log file it struck at "Connecting to ssl://72.217.201.89 on port 443" and no response is coming back. below are my log file. 20091011-12:07:43 : Created session 20091011-12:07:45 : Connecting to 72.217.201.89 on port 443 20091011-12:07:45 : Initiated logon request 20091011-12:07:46 : Socket Error: An established connection was aborted by the software in your host machine. 20091011-12:07:46 : Disconnecting 20091011-12:07:46 : Connecting to 72.217.201.89 on port 443 20091011-12:07:46 : Initiated logon request 20091011-12:07:47 : Socket Error: An established connection was aborted by the software in your host machine. -- View this message in context: http://www.nabble.com/Is-Quickfix-SSL-enabled-------tp25842996p25842996.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: VP M. IT A. E. T. <ass...@gm...> - 2009-10-10 19:22:45
|
The counterparty rejected the subsequent login requests with sequence number too low. Is there a way to specify the starting sequence number rather than 1. regards On Fri, Oct 9, 2009 at 10:07 AM, Grant Birchmeier <gbi...@co... > wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Your approach is quite off track. Have you looked at the example programs? > http://quickfixengine.org/quickfix/doc/html/examples.html > > Also, there are instructions for how to create messages here. You can > see how this is quite different than your approach. > http://quickfixengine.org/quickfix/doc/html/sending_messages.html > > Note that you should NOT be creating a Logon message this way, as > QuickFIX does a lot of this automatically. At most, you might insert > username and password fields, but not much else. > > Please see the example programs that are included in the QF download. > They will help you greatly. > > -Grant > > > On Fri, Oct 9, 2009 at 1:48 AM, ch...@gm... <ch...@gm...> > wrote: > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > > > Hi i want to send LOGON message to FIX. > > here is my logon method. > > > > > > void Application::fxlogin() > > { > > FIX::Message message; > > > > message.getHeader().setField(35, "A"); > > message.getHeader().setField(96, "12345678"); > > message.getHeader().setField(108,"10"); > > FIX::Session::sendToTarget(message); > > > > > > } > > Config file setting are as follows.. > > > > [DEFAULT] > > ConnectionType=initiator > > ReconnectInterval=20 > > StartTime=12:00:00 > > EndTime=23:00:00 > > SenderCompID=TW > > SenderSubID=user1 > > HeartBtInt=10 > > SocketConnectPort=443 > > SocketConnectHost=ssl://84.219.221.89 > > FileLogPath=c:\qfixlogs\ > > FileStorePath=c:\qfixstore\ > > > > # session definition > > [SESSION] > > # inherit ConnectionType, ReconnectInterval and SenderCompID from default > > BeginString=FIX.4.4 > > TargetCompID=ISLD > > TargetSubID=qftrade > > HeartBtInt=10 > > FileLogPath=c:\qfixlogs\ > > FileStorePath=c:\qfixstore\ > > DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml > > > > Can any one help me how we can send it? > > or If you can send your code with me for logon message so that i can > figure > > it out. > > thanks. > > Asad. > > -- > > View this message in context: > http://www.nabble.com/unable-to-send-LOGON-message-to-FIX-tp25816265p25816265.html > > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > > is the only developer event you need to attend this year. Jumpstart your > > developing skills, take BlackBerry mobile applications to market and stay > > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Grant B. <gbi...@co...> - 2009-10-09 14:07:54
|
Your approach is quite off track. Have you looked at the example programs? http://quickfixengine.org/quickfix/doc/html/examples.html Also, there are instructions for how to create messages here. You can see how this is quite different than your approach. http://quickfixengine.org/quickfix/doc/html/sending_messages.html Note that you should NOT be creating a Logon message this way, as QuickFIX does a lot of this automatically. At most, you might insert username and password fields, but not much else. Please see the example programs that are included in the QF download. They will help you greatly. -Grant On Fri, Oct 9, 2009 at 1:48 AM, ch...@gm... <ch...@gm...> wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > Hi i want to send LOGON message to FIX. > here is my logon method. > > > void Application::fxlogin() > { > FIX::Message message; > > message.getHeader().setField(35, "A"); > message.getHeader().setField(96, "12345678"); > message.getHeader().setField(108,"10"); > FIX::Session::sendToTarget(message); > > > } > Config file setting are as follows.. > > [DEFAULT] > ConnectionType=initiator > ReconnectInterval=20 > StartTime=12:00:00 > EndTime=23:00:00 > SenderCompID=TW > SenderSubID=user1 > HeartBtInt=10 > SocketConnectPort=443 > SocketConnectHost=ssl://84.219.221.89 > FileLogPath=c:\qfixlogs\ > FileStorePath=c:\qfixstore\ > > # session definition > [SESSION] > # inherit ConnectionType, ReconnectInterval and SenderCompID from default > BeginString=FIX.4.4 > TargetCompID=ISLD > TargetSubID=qftrade > HeartBtInt=10 > FileLogPath=c:\qfixlogs\ > FileStorePath=c:\qfixstore\ > DataDictionary=C:\quickfix-1.12.4\quickfix\spec\FIX44.xml > > Can any one help me how we can send it? > or If you can send your code with me for logon message so that i can figure > it out. > thanks. > Asad. > -- > View this message in context: http://www.nabble.com/unable-to-send-LOGON-message-to-FIX-tp25816265p25816265.html > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
98 messages has been excluded from this view by a project administrator.
