quickfix-users Mailing List for QuickFIX (Page 2)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-users — QuickFIX user support
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(4) |
Mar
(6) |
Apr
(2) |
May
(4) |
Jun
(1) |
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(3) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(7) |
Feb
(3) |
Mar
(10) |
Apr
(40) |
May
(63) |
Jun
(12) |
Jul
(26) |
Aug
(13) |
Sep
(6) |
Oct
(13) |
Nov
(17) |
Dec
(28) |
| 2004 |
Jan
(13) |
Feb
(6) |
Mar
(9) |
Apr
(20) |
May
(15) |
Jun
(29) |
Jul
(22) |
Aug
(11) |
Sep
(32) |
Oct
(34) |
Nov
(22) |
Dec
(33) |
| 2005 |
Jan
(17) |
Feb
(8) |
Mar
(3) |
Apr
(20) |
May
(19) |
Jun
(29) |
Jul
(30) |
Aug
(10) |
Sep
(24) |
Oct
|
Nov
(17) |
Dec
(11) |
| 2006 |
Jan
(32) |
Feb
(54) |
Mar
(34) |
Apr
(43) |
May
(14) |
Jun
(11) |
Jul
(10) |
Aug
(43) |
Sep
(37) |
Oct
(44) |
Nov
(16) |
Dec
(11) |
| 2007 |
Jan
(26) |
Feb
(5) |
Mar
(23) |
Apr
(3) |
May
(22) |
Jun
(17) |
Jul
(22) |
Aug
(34) |
Sep
(17) |
Oct
(18) |
Nov
(4) |
Dec
(8) |
| 2008 |
Jan
(28) |
Feb
(28) |
Mar
(23) |
Apr
(37) |
May
(53) |
Jun
(20) |
Jul
(30) |
Aug
(12) |
Sep
(19) |
Oct
(16) |
Nov
(15) |
Dec
(10) |
| 2009 |
Jan
(19) |
Feb
(8) |
Mar
(21) |
Apr
(8) |
May
(15) |
Jun
(22) |
Jul
(34) |
Aug
(18) |
Sep
(23) |
Oct
(26) |
Nov
(16) |
Dec
(13) |
| 2010 |
Jan
(38) |
Feb
(17) |
Mar
(39) |
Apr
(34) |
May
(5) |
Jun
(15) |
Jul
(7) |
Aug
(18) |
Sep
(4) |
Oct
(16) |
Nov
(3) |
Dec
(17) |
| 2011 |
Jan
(28) |
Feb
(12) |
Mar
(36) |
Apr
(9) |
May
(26) |
Jun
(27) |
Jul
(6) |
Aug
(10) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(9) |
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(9) |
Nov
(10) |
Dec
(8) |
| 2013 |
Jan
(3) |
Feb
(2) |
Mar
(7) |
Apr
(2) |
May
|
Jun
(7) |
Jul
(22) |
Aug
(5) |
Sep
(3) |
Oct
(3) |
Nov
(3) |
Dec
(2) |
| 2014 |
Jan
(4) |
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(4) |
Dec
|
| 2016 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mihkel T. <mih...@gm...> - 2016-07-12 09:41:21
|
Hi, Thanks for the answer. Unfortunately I already tried adding this line to the FIX44 file, but I still get the error. Mihkel On Tue, Jul 12, 2016 at 12:37 PM Joaquin Gracia <jo...@eu...> wrote: > Maybe the value “111” is not in the list of possible values defined in the > dictionary. Something like: > > <field number=“22” name=“IDSource” type=“STRING”> > <value enum=“111” descrption=“WHATEVER”> > … > </field> > > Hope that helps. > > > Joaquín Gracia > Eurosigma S.A. > > El 12/7/2016, a las 11:23, Mihkel Tali <mih...@gm...> escribió: > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > Hi, > I'm relatively new to FIX protocol and just made my first interface/app. I > have a problem with sending orders, more specifically the broker that I'm > connecting to requires that to identify a symbol tags 48 and 22 be used as > well. When I try to send and order my app sends a toadmin message right > after the order message which has in it 58=Value is incorrect (out of > range) for this tag , referring to tag 22, but tag 22 is a constant value > of 111 which is required by the broker. What may be the problem? > > Thanks for your help, > Mihkel > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports. > http://sdm.link/zohodev2dev_______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > > > |
|
From: Mihkel T. <mih...@gm...> - 2016-07-12 09:23:53
|
Hi, I'm relatively new to FIX protocol and just made my first interface/app. I have a problem with sending orders, more specifically the broker that I'm connecting to requires that to identify a symbol tags 48 and 22 be used as well. When I try to send and order my app sends a toadmin message right after the order message which has in it 58=Value is incorrect (out of range) for this tag , referring to tag 22, but tag 22 is a constant value of 111 which is required by the broker. What may be the problem? Thanks for your help, Mihkel |
|
From: James B. <jam...@ho...> - 2016-03-15 19:29:45
|
Hi, Im looking some simple ideas to implement to make the quickFix adaptor Im using to run a little faster. Im not looking for anything drastic, just of their are any tricks that Im missing that are easy to implement. To give some info, a) the adaptor will only be responsible for essentially uni directional communication. b) Id be willing to accept changes that make the adaptor "less safe" for cases thata re 99.999 % unlikely to happen. Eg wrong check sum, if it would give an easy win. c) I looked at the "validate fields out of order" setting. I can turn it off, but will that save a certain amount of overhead? d)Im willing to recompile the libs if needed. Regards, James |
|
From: Eric S. <esh...@hi...> - 2016-03-14 15:35:31
|
Crashes my software upon exit! On 03/11/2016 01:49 PM, Eric Shulman wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > Salutations! > > Shouldn't it be *logoff()* on line 227 of Acceptor.cpp > <https://github.com/quickfix/quickfix/blob/master/src/C%2B%2B/Acceptor.cpp>, > instead of *logon()*? > > Gr., > -- > *Eric Shulman* > > T +31 (0)20 261 3056 > I www.hiqinvest.nl <http://www.hiqinvest.nl/> > > *hiqinvest.nl* <http://hiqinvest.nl/> > Rembrandt Tower - 9th Floor > Amstelplein 1 > 1096 HA Amsterdam > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > > > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users -- *Eric Shulman* T +31 (0)20 261 3056 I www.hiqinvest.nl <http://www.hiqinvest.nl/> *hiqinvest.nl* <http://hiqinvest.nl/> Rembrandt Tower - 9th Floor Amstelplein 1 1096 HA Amsterdam |
|
From: Eric S. <esh...@hi...> - 2016-03-11 13:06:28
|
Salutations! Shouldn't it be *logoff()* on line 227 of Acceptor.cpp <https://github.com/quickfix/quickfix/blob/master/src/C%2B%2B/Acceptor.cpp>, instead of *logon()*? Gr., -- *Eric Shulman* T +31 (0)20 261 3056 I www.hiqinvest.nl <http://www.hiqinvest.nl/> *hiqinvest.nl* <http://hiqinvest.nl/> Rembrandt Tower - 9th Floor Amstelplein 1 1096 HA Amsterdam |
|
From: Harwinder S. <har...@ut...> - 2015-11-12 12:35:05
|
Please ignore the previous email... this error was due to my naivete :-( I had code like the following: FIX::MDEntryPx price; if (mdEntry.isSetField( FIX::FIELD::MDEntryPx )) mdEntry.get( price ); And, somewhere at the bottom of the function, I had a naked get, which did not check if the field exists: someotherfunction( price ); However, when the price field (MDEntryPx, tag 270) was not set, this would result in an exception, which sent the reject message to the counterparty, saying "Incorrect data format for value". On Thu, Nov 12, 2015 at 4:00 PM, Harwinder Sidhu < har...@ut...> wrote: > Hi, > > I'm facing a weird error, where my FIX application is rejecting a > MarketData - Incremental Refresh (MsgType=X) message on a particular > production machine. > > The error is - Incorrect data format for value:270. Tag 270 is Price tag > and it looks okay to me in the message below for all the MD entries. > > So, I copied the message from the production machine, built a small > counterparty application which would send this message to my particular > application. And, the application works fine on my development machine. > > Again, I copied the counterparty app and my FIX application on the > production machine and the error is reproducible, which is strange. > > I have checked for the obvious: same FIX44.xml file, same settings file, > the checksum of the libquickfix.so.14.0.0 is same on both the machines. > > Any other obvious issue, which I might be overlooking here? > > Thanks. > > > 8=FIX.4.4^A9=833^A35=X^A34=5^A49=BCSG^A52=20151112-10:17:35.257^A56=BTFOREXCERT^A262=3^A268=10^A279=0^A269=5^A55=AGUAS-A^A167=CS^A207=XSGO^A270=362.62^A290=1 > > ^A279=0^A269=7^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A279=0^A269=8^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A279=0^A269=4^A55=AGUAS-A^A167=CS^A207=XSGO^A270=362.62^A290=1^A279=0^A269=A^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A811=0^A451=0^A279=0^A269=B^A55=AGUAS-A^A167=CS^A207=XSGO^A271=3139^A290=1^A279=0^A269=9^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A279=0^A269=D^A55=AGUAS-A^A167=CS^A207=XSGO^A270=1172641^A290=1^A279=0^A269=2^A278=217519^A55=AGUAS-A^A48=AGUAS-A^A22=8^A167=CS^A207=XSGO^A466=|||^A270=381.27^A271=13^A273=16:34:55.348^A336=2^A277=C^A282=1155116634^A288=048^A289=054^A290=1^A811=4957^A58=20151112^A5463=217519^A279=2^A269=0^A278=49-381.27^A55=AGUAS-A^A48=CL0000000035^A22=4^A167=CS^A207=XSGO^A876=S^A466=|||^A270=381.27^A271=13^A273=16:33:49.192^A277=C^A18=A^A346=1^A290=1^A10124=564^A10=203^A > |
|
From: Harwinder S. <har...@ut...> - 2015-11-12 11:00:40
|
Hi, I'm facing a weird error, where my FIX application is rejecting a MarketData - Incremental Refresh (MsgType=X) message on a particular production machine. The error is - Incorrect data format for value:270. Tag 270 is Price tag and it looks okay to me in the message below for all the MD entries. So, I copied the message from the production machine, built a small counterparty application which would send this message to my particular application. And, the application works fine on my development machine. Again, I copied the counterparty app and my FIX application on the production machine and the error is reproducible, which is strange. I have checked for the obvious: same FIX44.xml file, same settings file, the checksum of the libquickfix.so.14.0.0 is same on both the machines. Any other obvious issue, which I might be overlooking here? Thanks. 8=FIX.4.4^A9=833^A35=X^A34=5^A49=BCSG^A52=20151112-10:17:35.257^A56=BTFOREXCERT^A262=3^A268=10^A279=0^A269=5^A55=AGUAS-A^A167=CS^A207=XSGO^A270=362.62^A290=1 ^A279=0^A269=7^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A279=0^A269=8^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A279=0^A269=4^A55=AGUAS-A^A167=CS^A207=XSGO^A270=362.62^A290=1^A279=0^A269=A^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A811=0^A451=0^A279=0^A269=B^A55=AGUAS-A^A167=CS^A207=XSGO^A271=3139^A290=1^A279=0^A269=9^A55=AGUAS-A^A167=CS^A207=XSGO^A290=1^A279=0^A269=D^A55=AGUAS-A^A167=CS^A207=XSGO^A270=1172641^A290=1^A279=0^A269=2^A278=217519^A55=AGUAS-A^A48=AGUAS-A^A22=8^A167=CS^A207=XSGO^A466=|||^A270=381.27^A271=13^A273=16:34:55.348^A336=2^A277=C^A282=1155116634^A288=048^A289=054^A290=1^A811=4957^A58=20151112^A5463=217519^A279=2^A269=0^A278=49-381.27^A55=AGUAS-A^A48=CL0000000035^A22=4^A167=CS^A207=XSGO^A876=S^A466=|||^A270=381.27^A271=13^A273=16:33:49.192^A277=C^A18=A^A346=1^A290=1^A10124=564^A10=203^A |
|
From: Harwinder S. <har...@ut...> - 2015-11-10 11:28:21
|
I tried upgrading to quickfix 1.14.3 and I am getting a similar crash:
(gdb) bt
#0 0x00007f8af46214b6 in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::~basic_string() () from /usr/lib64/libstdc++.so.6
#1 0x0000000000575132 in FIX::FieldBase::~FieldBase (this=0x7f8ae0004f08,
__in_chrg=<value optimized out>) at
/home/hss/quickinstall14/include/quickfix/Field.h:91
#2 0x000000000060be1e in std::pair<int const, FIX::FieldBase>::~pair
(this=0x7f8ae0004f00, __in_chrg=<value optimized out>)
at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_pair.h:68
#3 0x0000000000616292 in __gnu_cxx::new_allocator<std::pair<int const,
FIX::FieldBase> >::destroy (this=0x7f8aee5a947f, __p=0x7f8ae0004f00)
at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/ext/new_allocator.h:115
#4 0x00000000006131eb in std::_Rb_tree<int, std::pair<int const,
FIX::FieldBase>, std::_Select1st<std::pair<int const, FIX::FieldBase> >,
FIX::message_order, std::allocator<std::pair<int const, FIX::FieldBase> >
>::_M_destroy_node (this=0x7f8ae00044c8, __p=0x7f8ae0004ee0) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:383
#5 0x0000000000610f39 in std::_Rb_tree<int, std::pair<int const,
FIX::FieldBase>, std::_Select1st<std::pair<int const, FIX::FieldBase> >,
FIX::message_order, std::allocator<std::pair<int const, FIX::FieldBase> >
>::_M_erase (this=0x7f8ae00044c8, __x=0x7f8ae0004ee0) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:972
#6 0x0000000000610f16 in std::_Rb_tree<int, std::pair<int const,
FIX::FieldBase>, std::_Select1st<std::pair<int const, FIX::FieldBase> >,
FIX::message_order, std::allocator<std::pair<int const, FIX::FieldBase> >
>::_M_erase (this=0x7f8ae00044c8, __x=0x7f8ae00045e0) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:970
#7 0x00007f8af4eaa7de in clear (this=<value optimized out>) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:726
#8 clear (this=<value optimized out>) at
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_multimap.h:562
#9 FIX::FieldMap::clear (this=<value optimized out>) at FieldMap.cpp:145
#10 0x00007f8af4eaaf6e in FIX::FieldMap::~FieldMap (this=0x7f8ae00044c0,
__in_chrg=<value optimized out>) at FieldMap.cpp:35
#11 0x000000000060cca1 in FIX::Group::~Group (this=0x7f8ae00044c0,
__in_chrg=<value optimized out>) at
/home/hss/quickinstall14/include/quickfix/fix44/../Group.h:41
#12 0x000000000060ccd0 in FIX::Group::~Group (this=0x7f8ae00044c0,
__in_chrg=<value optimized out>) at
/home/hss/quickinstall14/include/quickfix/fix44/../Group.h:41
#13 0x00007f8af4eaa827 in FIX::FieldMap::clear (this=0x7f8aee5a9640) at
FieldMap.cpp:152
#14 0x00007f8af4eaaf6e in FIX::FieldMap::~FieldMap (this=0x7f8aee5a9640,
__in_chrg=<value optimized out>) at FieldMap.cpp:35
#15 0x0000000000633ddc in FIX::Message::~Message (this=0x7f8aee5a9640,
__in_chrg=<value optimized out>) at
/home/hss/quickinstall14/include/quickfix/Message.h:68
#16 0x00007f8af4e5b2cf in FIX::Session::next (this=0x1374fd0, msg=
"8=FIX.4.4\001\071=166622\001\063\065=W\001\063\064=3\001\064\071=BCSG\001\065\062=20151110-11:24:45.464\001\065\066=BTFOREXCERT\001\065\065=LAN\001\061\066\067=CS\001\062\060\067=XSGO\001\062\066\062=2\001\062\066\070=938\001\062\066\071=5\001\062\067\060=3998.8\001\062\067\062=20151109\001\062\070\066=6\001\062\071\060=1\001\062\066\071=7\001\062\067\060=4150\001\062\071\060=1\001\062\066\071=8\001\062\067\060=3950.1\001\062\071\060=1\001"...,
timeStamp=..., queued=<value optimized out>) at Session.cpp:1189
#17 0x00007f8af4e8238c in FIX::SocketConnection::readMessages
(this=0x7f8ae0000fd0, s=...) at SocketConnection.cpp:224
#18 0x00007f8af4e82575 in FIX::SocketConnection::read (this=0x7f8ae0000fd0,
s=...) at SocketConnection.cpp:113
#19 0x00007f8af4e73241 in FIX::ConnectorWrapper::onEvent
(this=0x7f8aee5a9d60, socket=19) at SocketConnector.cpp:59
#20 0x00007f8af4e8092d in FIX::SocketMonitor::processReadSet
(this=0xeee5e0, strategy=..., readSet=...) at SocketMonitor.cpp:260
#21 0x00007f8af4e8148d in FIX::SocketMonitor::block (this=0xeee5e0,
strategy=..., poll=false, timeout=<value optimized out>) at
SocketMonitor.cpp:219
#22 0x00007f8af4e730d8 in FIX::SocketConnector::block (this=<value
optimized out>, strategy=<value optimized out>, poll=<value optimized out>,
timeout=<value optimized out>)
at SocketConnector.cpp:114
#23 0x00007f8af4e7cc55 in FIX::SocketInitiator::onStart (this=0xeee330) at
SocketInitiator.cpp:92
#24 0x00007f8af4e7643a in FIX::Initiator::startThread (p=<value optimized
out>) at Initiator.cpp:286
#25 0x00007f8af48919d1 in start_thread () from /lib64/libpthread.so.0
#26 0x00007f8af3e3e8fd in clone () from /lib64/libc.so.6
On Tue, Nov 10, 2015 at 1:38 PM, Harwinder Sidhu <
har...@ut...> wrote:
> Hi,
>
> We are facing a crash in the quickfix library, when we are receivng a very
> large message from the counterparty. I put a debug build on the machine and
> the crash dump is below the message.
>
> I am using quickfix version 1.13.3, gcc 4.4.7 on CentOS 6.x and when I
> looked at FieldMap:174, it is a delete statement.
>
> A similar issue with allocators is probably reported here:
> http://sourceforge.net/p/quickfix/mailman/message/10833533/
>
> which seems to be have been fixed in 1.12.4. However, since I’m using a
> later version, this should not be the case here.
>
> The configure script on my machine gives the following output related to
> the allocators:
>
> checking for boost::pool_allocator... yes
> checking for boost::fast_pool_allocator... yes
> checking __gnu_cxx::__pool_alloc... yes
> checking __gnu_cxx::__mt_alloc... yes
> checking __gnu_cxx::bitmap_allocator... yes
>
> Any pointers on how can I go about fixing this issue?
>
> Best Regards,
> Harwinder
>
>
> Stack Trace:
>
> (gdb) bt
> #0 0x00007ffff6858084 in FIX::FieldMap::clear (this=0x7ffff5271630) at
> FieldMap.cpp:174
> #1 0x00007ffff6858a49 in FIX::FieldMap::~FieldMap (this=0x7ffff5271630,
> __in_chrg=<value optimized out>) at FieldMap.cpp:35
> #2 0x000000000061bf66 in FIX::Message::~Message (this=0x7ffff5271630,
> __in_chrg=<value optimized out>)
> at /usr/local/include/quickfix/Message.h:58
> #3 0x00007ffff6806d14 in FIX::Session::next (this=0x9c6480, msg=
> "8=FIX.4.4\001\071=166387\001\063\065=W\001\063\064=3\001\064\071=BCSGATEWAY\001\065\062=20151109-21:10:23.243\001\065\066=MDFOREX\001\065\065=LAN\001\061\066\067=CS\001\062\060\067=XSGO\001\062\066\062=1\001\062\066\070=935\001\062\066\071=5\001\062\067\060=3998.8\001\062\067\062=20151109\001\062\070\066=6\001\062\071\060=1\001\062\066\071=7\001\062\067\060=4150\001\062\071\060=1\001\062\066\071=8\001\062\067\060=3950.1\001\062\071\060="...,
> timeStamp=..., queued=<value optimized out>) at Session.cpp:1309
> #4 0x00007ffff682fecc in FIX::SocketConnection::readMessages
> (this=0x7fffe8000f90, s=...) at SocketConnection.cpp:234
> #5 0x00007ffff682fff5 in FIX::SocketConnection::read
> (this=0x7fffe8000f90, s=...) at SocketConnection.cpp:124
> #6 0x00007ffff6821e51 in FIX::ConnectorWrapper::onEvent
> (this=0x7ffff5271d60, socket=23) at SocketConnector.cpp:67
> #7 0x00007ffff682e03d in FIX::SocketMonitor::processReadSet
> (this=0x9cb0a0, strategy=..., readSet=...) at SocketMonitor.cpp:287
> #8 0x00007ffff682edcd in FIX::SocketMonitor::block (this=0x9cb0a0,
> strategy=..., poll=false, timeout=<value optimized out>)
> at SocketMonitor.cpp:243
> #9 0x00007ffff6821cc8 in FIX::SocketConnector::block (this=<value
> optimized out>, strategy=<value optimized out>,
> poll=<value optimized out>, timeout=<value optimized out>) at
> SocketConnector.cpp:144
> #10 0x00007ffff682b021 in FIX::SocketInitiator::onStart (this=0x9cadf0) at
> SocketInitiator.cpp:96
> #11 0x00007ffff68247fa in FIX::Initiator::startThread (p=<value optimized
> out>) at Initiator.cpp:336
> #12 0x0000003284c07a51 in start_thread () from /lib64/libpthread.so.0
> #13 0x00000032848e893d in clone () from /lib64/libc.so.6
>
> (gdb)
>
>
|
|
From: Harwinder S. <har...@ut...> - 2015-11-10 08:40:24
|
Hi, We are facing a crash in the quickfix library, when we are receivng a very large message from the counterparty. I put a debug build on the machine and the crash dump is below the message. I am using quickfix version 1.13.3, gcc 4.4.7 on CentOS 6.x and when I looked at FieldMap:174, it is a delete statement. A similar issue with allocators is probably reported here: http://sourceforge.net/p/quickfix/mailman/message/10833533/ which seems to be have been fixed in 1.12.4. However, since I’m using a later version, this should not be the case here. The configure script on my machine gives the following output related to the allocators: checking for boost::pool_allocator... yes checking for boost::fast_pool_allocator... yes checking __gnu_cxx::__pool_alloc... yes checking __gnu_cxx::__mt_alloc... yes checking __gnu_cxx::bitmap_allocator... yes Any pointers on how can I go about fixing this issue? Best Regards, Harwinder Stack Trace: (gdb) bt #0 0x00007ffff6858084 in FIX::FieldMap::clear (this=0x7ffff5271630) at FieldMap.cpp:174 #1 0x00007ffff6858a49 in FIX::FieldMap::~FieldMap (this=0x7ffff5271630, __in_chrg=<value optimized out>) at FieldMap.cpp:35 #2 0x000000000061bf66 in FIX::Message::~Message (this=0x7ffff5271630, __in_chrg=<value optimized out>) at /usr/local/include/quickfix/Message.h:58 #3 0x00007ffff6806d14 in FIX::Session::next (this=0x9c6480, msg= "8=FIX.4.4\001\071=166387\001\063\065=W\001\063\064=3\001\064\071=BCSGATEWAY\001\065\062=20151109-21:10:23.243\001\065\066=MDFOREX\001\065\065=LAN\001\061\066\067=CS\001\062\060\067=XSGO\001\062\066\062=1\001\062\066\070=935\001\062\066\071=5\001\062\067\060=3998.8\001\062\067\062=20151109\001\062\070\066=6\001\062\071\060=1\001\062\066\071=7\001\062\067\060=4150\001\062\071\060=1\001\062\066\071=8\001\062\067\060=3950.1\001\062\071\060="..., timeStamp=..., queued=<value optimized out>) at Session.cpp:1309 #4 0x00007ffff682fecc in FIX::SocketConnection::readMessages (this=0x7fffe8000f90, s=...) at SocketConnection.cpp:234 #5 0x00007ffff682fff5 in FIX::SocketConnection::read (this=0x7fffe8000f90, s=...) at SocketConnection.cpp:124 #6 0x00007ffff6821e51 in FIX::ConnectorWrapper::onEvent (this=0x7ffff5271d60, socket=23) at SocketConnector.cpp:67 #7 0x00007ffff682e03d in FIX::SocketMonitor::processReadSet (this=0x9cb0a0, strategy=..., readSet=...) at SocketMonitor.cpp:287 #8 0x00007ffff682edcd in FIX::SocketMonitor::block (this=0x9cb0a0, strategy=..., poll=false, timeout=<value optimized out>) at SocketMonitor.cpp:243 #9 0x00007ffff6821cc8 in FIX::SocketConnector::block (this=<value optimized out>, strategy=<value optimized out>, poll=<value optimized out>, timeout=<value optimized out>) at SocketConnector.cpp:144 #10 0x00007ffff682b021 in FIX::SocketInitiator::onStart (this=0x9cadf0) at SocketInitiator.cpp:96 #11 0x00007ffff68247fa in FIX::Initiator::startThread (p=<value optimized out>) at Initiator.cpp:336 #12 0x0000003284c07a51 in start_thread () from /lib64/libpthread.so.0 #13 0x00000032848e893d in clone () from /lib64/libc.so.6 (gdb) |
|
From: Grant B. <gbi...@co...> - 2015-10-26 19:28:04
|
Michal, looks like you are using QF/j, which means you are on the wrong list. This list is for the original C++ QF. Please see quickfixj.org for the correct list. On Wed, Oct 14, 2015 at 5:03 AM, Michal JACYKIEWICZ < Mic...@uk...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi > > What's the best way to get notified in my application about this please: > > 2015-10-14 11:00:47,039 ERROR QFJ Timer quickfixj.errorEvent > FIXT.1.1:BNPP01SSTEST->NEPTUNECERT: java.net.ConnectException: > java.net.ConnectException: Connection refused: no further information (Next > retry in 60000 milliseconds) > > Regards > Michal Jacykiewicz > > > ___________________________________________________________ > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and delete this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is prohibited. > > Please refer to http://www.bnpparibas.co.uk/en/email-disclaimer/ for > additional disclosures. > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com |
|
From: Michal J. <Mic...@uk...> - 2015-10-14 10:18:36
|
Hi What's the best way to get notified in my application about this please: 2015-10-14 11:00:47,039 ERROR QFJ Timer quickfixj.errorEvent FIXT.1.1:BNPP01SSTEST->NEPTUNECERT: java.net.ConnectException: java.net.ConnectException: Connection refused: no further information (Next retry in 60000 milliseconds) Regards Michal Jacykiewicz ___________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited. Please refer to http://www.bnpparibas.co.uk/en/email-disclaimer/ for additional disclosures. |
|
From: Grant B. <gbi...@co...> - 2015-10-06 18:32:16
|
This is the C++ QF list. I think you want the Quickfix/J mailing list. See here: http://quickfixj.org/support/ In general, though, the way you're thinking sounds pretty wrong. Do not screw with the QF message store. You should make your own storage structure and operate it at the application layer. On Tue, Oct 6, 2015 at 4:15 AM, Mihai <mih...@ya...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > I want to be able from my acceptor to store messages sent to a manually > created sessionID, and when the initiator connects to send all these > messages. > > Currently I'm able to store the messages, but when the initiator connects, > it overwrites the .event file instead of resending everything from there. > It > looks to me as if the sessionID I've created and the sessionID created when > the initiator connects are somehow different. > > The only solution I can think of is to get hold of the message store and > when the initiator connects intercept the onLogon and manually resend > everything I have stored up to that point. > > I'm creating the sessionID using the constructor with BeginString, > SenderCompID and TargetCompID parameters. > > > > -- > View this message in context: > http://quickfix.13857.n7.nabble.com/QuickfixJ-acceptor-sending-stored-messages-to-manually-created-session-tp6768.html > Sent from the QuickFIX - User mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com |
|
From: Mihai <mih...@ya...> - 2015-10-06 09:52:04
|
I want to be able from my acceptor to store messages sent to a manually created sessionID, and when the initiator connects to send all these messages. Currently I'm able to store the messages, but when the initiator connects, it overwrites the .event file instead of resending everything from there. It looks to me as if the sessionID I've created and the sessionID created when the initiator connects are somehow different. The only solution I can think of is to get hold of the message store and when the initiator connects intercept the onLogon and manually resend everything I have stored up to that point. I'm creating the sessionID using the constructor with BeginString, SenderCompID and TargetCompID parameters. -- View this message in context: http://quickfix.13857.n7.nabble.com/QuickfixJ-acceptor-sending-stored-messages-to-manually-created-session-tp6768.html Sent from the QuickFIX - User mailing list archive at Nabble.com. |
|
From: SZ Li <is...@gm...> - 2015-06-01 21:11:17
|
Thanks! I found the patch for old version of Quickfix C++ in Reuter's document release. This is very helpful! Thank you! Best, Simon On Mon, Jun 1, 2015 at 3:57 PM, Gabriel Ricardo <gab...@gm...> wrote: > Reuters Matching API provides a sample client program with a tag 789 > Quickfix patch. At least they did a couple years ago, so it might be for > an older version of Quickfix (1.13.3). > If you have trouble finding the Reuters client samples, send me an email > and I might be able to dig up the link to the Reuters Customer zone. > > On Mon, Jun 1, 2015 at 11:48 AM, SZ Li <is...@gm...> wrote: > >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> >> >> Hello, >> As far as I know Quickfix C++ version does not support tag 789 >> NextExepectedMsgSeqnum. There is a patch for Quickfix/J ( >> http://www.quickfixj.org/jira/browse/QFJ-567). I am wondering if there >> is any patch for the C++ version. The purpose is to support Reuters >> Matching API, which requires to use tag 789 to trigger message replays. >> Quickfix hides session level operations to the users, so it seems that we >> have to patch Quickfix. >> Any idea or suggestions are also welcome! >> >> Thanks, >> Simon >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Quickfix-users mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-users >> >> > |
|
From: Gabriel R. <gab...@gm...> - 2015-06-01 19:57:24
|
Reuters Matching API provides a sample client program with a tag 789 Quickfix patch. At least they did a couple years ago, so it might be for an older version of Quickfix (1.13.3). If you have trouble finding the Reuters client samples, send me an email and I might be able to dig up the link to the Reuters Customer zone. On Mon, Jun 1, 2015 at 11:48 AM, SZ Li <is...@gm...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > Hello, > As far as I know Quickfix C++ version does not support tag 789 > NextExepectedMsgSeqnum. There is a patch for Quickfix/J ( > http://www.quickfixj.org/jira/browse/QFJ-567). I am wondering if there is > any patch for the C++ version. The purpose is to support Reuters Matching > API, which requires to use tag 789 to trigger message replays. Quickfix > hides session level operations to the users, so it seems that we have to > patch Quickfix. > Any idea or suggestions are also welcome! > > Thanks, > Simon > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > > |
|
From: SZ Li <is...@gm...> - 2015-06-01 18:48:41
|
Hello, As far as I know Quickfix C++ version does not support tag 789 NextExepectedMsgSeqnum. There is a patch for Quickfix/J ( http://www.quickfixj.org/jira/browse/QFJ-567). I am wondering if there is any patch for the C++ version. The purpose is to support Reuters Matching API, which requires to use tag 789 to trigger message replays. Quickfix hides session level operations to the users, so it seems that we have to patch Quickfix. Any idea or suggestions are also welcome! Thanks, Simon |
|
From: Neeraj R. <rn...@ya...> - 2015-03-21 01:56:50
|
I sent this email to quickfix users list on Mar 10 but it doesn't show up on the archives.
On Tuesday, March 10, 2015 11:40 PM, Neeraj Rai <rn...@ya...> wrote:
Hi, I have used quickfix for quite some time as a user and roughly familiar with socketAcceptor etc.I need to embed quickfix in my eventloop.I would like to take the sockets and add it to my select/epoll.When the data is received, I would like to call functions that trigger onApp / crack/onMessage etc.I would add my own timer and send heartbeat when it triggers (which func to call)I would add my own timer to detect missed heartbeat and disconnect FIX sessionsWhat's the best way to detect resendReq in this scenario. What's the best way to go about this ?Any pointers would be appreciated. thanksNeeraj
|
|
From: Tim S. <Tim...@bl...> - 2015-03-16 19:10:19
|
Igor Seleznev <selez@...> writes: > > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > Hi, > It could be due to custom tags 6138 and 6215. > Please double-check that they are both defined for W and registered in proper places: 6318 should go before the repeating group NoMDEntries and 6215 should be a part of it. > > Not sure about the latest version of QuickFIX but the previous one (1.12.4) makes a misleading diagnosis when validating incoming messages with repeating groups. > > Kind regards, > Igor > > > On Apr 24, 2012, at 2:29 PM, Davide Anastasia wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.htmlQuickFIX Support: http://www.quickfixengine.org/services.html<!-- > /* Font Definitions */ > <at> font-face > {font-family:Calibri; > panose-1:2 15 5 2 2 2 4 3 2 4;} > /* Style Definitions */ > p.MsoNormal, li.MsoNormal, div.MsoNormal > {margin:0cm; > margin-bottom:.0001pt; > font-size:11.0pt; > font-family:"Calibri","sans-serif"; > mso-fareast-language:EN-US;} > a:link, span.MsoHyperlink > {mso-style-priority:99; > color:blue; > text-decoration:underline;} > a:visited, span.MsoHyperlinkFollowed > {mso-style-priority:99; > color:purple; > text-decoration:underline;} > span.EmailStyle17 > {mso-style-type:personal-compose; > font-family:"Arial","sans-serif"; > color:black;} > .MsoChpDefault > {mso-style-type:export-only; > font-family:"Calibri","sans-serif"; > mso-fareast-language:EN-US;} > <at> page WordSection1 > {size:612.0pt 792.0pt; > margin:72.0pt 72.0pt 72.0pt 72.0pt;} > div.WordSection1 > {page:WordSection1;} > --> > Hi all, > I’ve been experiencing a problem in parsing correctly a Market Data Snapshot Full Refresh Message (Type = W). > Just below a log of the communication, with the error: > > <20120424-10:23:33.363, FIX.4.4:UAT.QCM_P.FIX->ABFX, outgoing> > (8=FIX.4.4_9=129_35=3_34=624_49=UAT.QCM_P.FIX_52=20120424- 10:23:33.363_56=ABFX_45=513_58=Tag not defined for this message type_371=15_372=W_373=2_10=085_) > <20120424-10:23:33.720, FIX.4.4:UAT.QCM_P.FIX->ABFX, incoming> > (8=FIX.4.4_9=240_35=W_34=514_49=ABFX_52=20120424- 10:23:33.418_56=UAT.QCM_P.FIX_55=EUR/USD_262=EUR/USD/SPOT/1234_6138=0.00 001_268=2_269=0_270=1.31528_15=EUR_271=100000_272=20120426_276=A_6215=SP _269=1_270=1.31543_15=EUR_271=100000_272=20120426_276=A_6215=SP_10=225_) > <20120424-10:23:33.720, FIX.4.4:UAT.QCM_P.FIX->ABFX, event> > (Message 514 Rejected: Tag not defined for this message type:15) > <20120424-10:23:33.720, FIX.4.4:UAT.QCM_P.FIX->ABFX, outgoing> > > I cannot understand where the error is: 15 is the “Currency” Tag, defined in the FIX 4.4 standard (a long before too). The incoming message looks fine to me, but it gets rejected: does anybody have an idea of why this happens? > Best regards, > > Davide AnastasiaAnalyst, Research & Development > Quality Capital Management Ltd.QCM House • Horizon Business VillageNo. 1 Brooklands RoadWeybridge • Surrey KT13 0TJUnited KingdomTel: +44 (0) 1932 334 400Fax: +44 (0) 1932 334 415Email: Davide.Anastasia- BtC...@pu... > > This email and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Quality Capital Management Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, printing, forwarding or copying of this email is strictly prohibited. Please contact the sender if you have received this email in error. You should also be aware that emails are susceptible to interference and you should not assume that the contents of this email originated from the sender above or that they have been accurately reproduced in their original form. Quality Capital Management Ltd is authorised and regulated by the Financial Services Authority in the UK and is a member of the National Futures Association in the US. > > > ---------------------------------------------------------------------- --------Live Security Virtual ConferenceExclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________ ________________________________Quickfix-users mailing listQuickfix- users <at> lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/quickf ix-users > > > > > > > ---------------------------------------------------------------------- -------- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > Quickfix-users mailing list > Quickfix-users@... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > Igor is correct, Incorrect reporting of the error. It is necessary to define the userdefined fields in the FIX4?.xml Define the fields in the <fields> section and add them to the appropriate message as well Thanks Igor |
|
From: Neeraj R. <rn...@ya...> - 2015-03-11 03:40:18
|
Hi, I have used quickfix for quite some time as a user and roughly familiar with socketAcceptor etc.I need to embed quickfix in my eventloop.I would like to take the sockets and add it to my select/epoll.When the data is received, I would like to call functions that trigger onApp / crack/onMessage etc.I would add my own timer and send heartbeat when it triggers (which func to call)I would add my own timer to detect missed heartbeat and disconnect FIX sessionsWhat's the best way to detect resendReq in this scenario. What's the best way to go about this ?Any pointers would be appreciated. thanksNeeraj |
|
From: Hei C. <str...@ya...> - 2014-12-15 11:21:28
|
Hi, Does quickfix/doc/html/python contain all the document for QuickFIX Python? I would like to use QuickFIX Python to parse a raw FIX message, and then use QuickFIX's interface to access the fields. If there is an example, it would be great (I can't find it in the example folder neither). I am not very familiar with SWIG. It seems like the SWIG template only tries to expose just some C++ interfaces in Python? Thanks in advance. Cheers, Hei |
|
From: <or...@qu...> - 2014-09-08 17:08:06
|
QuickFIX 1.14.0 is available at http://www.quickfixengine.org Release notes at http://www.quickfixengine.org/NEWS Hello all, This release has really been out for about a month, but just getting the word out now. Many performance improvements here. Special thanks to Viktor Pogrebnyak for his contributions. Check the release notes for a full list of changes, but some things to note. The .NET wrapper is now superseded but QuickFIX/n. This is the same process we went through when we removed the JNI wrapper in favor of QuickFIX/J. Like QuickFIX/J, QuickFIX/n has been in production for quite some time, is a native implementation, and has a great company supporting it, in this case Connamara Systems. Visual Studio support is available for VS10, VS11, and VS12. So now it supports the latest public releases. Older versions have been dropped. We are now only supporting versions of Visual Studio that Microsoft distributes with a freely available version of Visual Studio Express. If you want to continue using older legacy versions of Visual Studio you will need to maintain your own solutions, or use an older version of QuickFIX. Out website has been redesigned. It is now just one landing page and has all the same basic information. Check it out, I think you'll find it much easier to find what you need. The documentation has been heavily reformatted and simplified. The idea is to make it a little easier for new users to get going. This tagged release and all previous releases can also be pulled from github. Enjoy! And thank you to the FIX protocol organization for honoring QuickFIX at the FIX Trading Community Americas regional meeting in Chicago. FIX is celebratings it's 20th year, and QuickFIX is now in its 13th year. Back then there was a lot of skepticism that open source would work in the financial industry. Now I can't even keep track of just the open source FIX engines that are available. Thanks for everyone's support for QuickFIX and open source in finance. |
|
From: Grant B. <gbi...@co...> - 2014-08-27 14:45:55
|
Something's not right. I wonder if there's a threading issue or something. Put simply, it looks like the heartbeat is getting sent before the MDRRs, even though the MDRRs are created first. I'm not as well-versed in the C++ QF as I am other ones (Java/C#), and this really seems like a bug specific to C++. Can someone else with a deeper understanding of the C++ engine step in here? On Tue, Aug 26, 2014 at 10:44 PM, Namalie Muthuthanthri < nam...@rh...> wrote: > > > Hi Grant, > > > > Below is from a more recent log. The incorrect heartbeat sequence number > is now 38 because we have more MDR requests for more currency pairs than > from the earlier log . As you can see the MDR requests go out after the > heartbeat that has 38 as it’s sequence number. Also the heartbeat interval > is set to 30 secs in the configs. > > > > > > 20140817-04:19:17.760 : 8=FIX.4.3 9=77 35=A 34=1 49=US > 52=20140817-04:19:17.760 56=THEM 98=0 108=30 141=Y 10=226 > > 20140817-04:19:19.788 : 8=FIX.4.3 9=77 35=A 34=1 49=THEM > 52=20140817-04:19:19.635 56=US 98=0 108=30 141=Y 10=229 > > 20140817-04:19:50.521 : 8=FIX.4.3 9=60 35=0 34=38 49=US > 52=20140817-04:19:50.459 56=THEM 10=191 > > 20140817-04:19:50.631 : 8=FIX.4.3 9=59 35=0 34=2 49=THEM > 52=20140817-04:19:50.496 56=US 10=143 > > 20140817-04:19:50.990 : 8=FIX.4.3 9=68 35=2 34=3 49=THEM > 52=20140817-04:19:50.730 56=US 7=2 16=0 10=005 > > 20140817-04:19:51.629: 8=FIX.4.3 9=183 35=V 34=2 43=Y 49=US > 52=201408104:19:51.629 56=THEM 122=2014081704:19:19.944 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=059 > > 20140817-04:19:51.707 : 8=FIX.4.3 9=183 35=V 34=3 43=Y 49=US > 52=20140817-04:19:51.707 56=THEM 122=20140817-04:19:19.960 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=108 > > 20140817-04:19:51.723 : 8=FIX.4.3 9=183 35=V 34=4 43=Y 49=US > 52=20140817-04:19:51.723 56=THEM 122=20140817-04:19:19.960 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=115 > > 20140817-04:19:51.738 : 8=FIX.4.3 9=183 35=V 34=5 43=Y 49=US > 52=20140817-04:19:51.738 56=THEM 122=20140817-04:19:19.960 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=084 > > 20140817-04:19:51.738 : 8=FIX.4.3 9=183 35=V 34=6 43=Y 49=US > 52=20140817-04:19:51.738 56=THEM 122=20140817-04:19:19.976 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=130 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=183 35=V 34=7 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:19.976 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=057 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=183 35=V 34=8 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:19.976 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=076 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=183 35=V 34=9 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:19.976 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=145 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=184 35=V 34=10 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:19.976 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=186 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=184 35=V 34=11 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:19.991 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=162 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=184 35=V 34=12 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:19.991 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=143 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=184 35=V 34=13 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:19.991 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=174 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=184 35=V 34=14 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:20.007 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=117 > > 20140817-04:19:51.754 : 8=FIX.4.3 9=184 35=V 34=15 43=Y 49=US > 52=20140817-04:19:51.754 56=THEM 122=20140817-04:19:20.007 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=136 > > 20140817-04:19:51.770 : 8=FIX.4.3 9=184 35=V 34=16 43=Y 49=US > 52=20140817-04:19:51.770 56=THEM 122=20140817-04:19:20.007 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=135 > > 20140817-04:19:51.801 : 8=FIX.4.3 9=184 35=V 34=17 43=Y 49=US > 52=20140817-04:19:51.801 56=THEM 122=20140817-04:19:20.007 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=145 > > 20140817-04:19:51.816 : 8=FIX.4.3 9=184 35=V 34=18 43=Y 49=US > 52=20140817-04:19:51.801 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=126 > > 20140817-04:19:51.816 : 8=FIX.4.3 9=184 35=V 34=19 43=Y 49=US > 52=20140817-04:19:51.816 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=192 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=20 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=081 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=21 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=132 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=22 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=118 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=23 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=116 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=24 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=107 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=25 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=104 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=26 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=1M 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=107 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=27 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=131 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=28 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=126 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=29 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=117 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=30 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=103 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=31 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=108 > > 20140817-04:19:51.832 : 8=FIX.4.3 9=184 35=V 34=32 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=123 > > 20140817-04:19:51.848 : 8=FIX.4.3 9=184 35=V 34=33 43=Y 49=US > 52=20140817-04:19:51.832 56=THEM 122=20140817-04:19:20.022 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=156 > > 20140817-04:19:51.879 : 8=FIX.4.3 9=184 35=V 34=35 43=Y 49=US > 52=20140817-04:19:51.879 56=THEM 122=20140817-04:19:20.038 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=200 > > 20140817-04:19:51.879 : 8=FIX.4.3 9=184 35=V 34=36 43=Y 49=US > 52=20140817-04:19:51.879 56=THEM 122=20140817-04:19:20.038 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=161 > > 20140817-04:19:51.879 : 8=FIX.4.3 9=184 35=V 34=37 43=Y 49=US > 52=20140817-04:19:51.879 56=THEM 122=20140817-04:19:20.038 146=1 55=CURPAIR > 6215=SP 5232=USD 5233=10000 262=CURPAIR 263=1 264=0 265=0 267=2 269=0 269=1 > 10=164 > > 20140817-04:19:51.879 : 8=FIX.4.3 9=103 35=4 34=38 43=Y 49=US > 52=20140817-04:19:51.879 56=THEM 122=20140817-04:19:51.879 36=39 123=Y > 10=075 > > > > *From:* Grant Birchmeier [mailto:gbi...@co...] > *Sent:* Tuesday, 26 August, 2014 11:25 PM > > *To:* Namalie Muthuthanthri > *Cc:* qui...@li... > *Subject:* Re: [Quickfix-users] Sends heartbeat messages with incorrect > sequence number > > > > Where are the MDRequests with sequence numbers 2-31? > > > > If the outgoing logon is 1, and the Heartbeat is 32, then your log should > also be showing the 30 messages in-between. > > > > Are those in-between messages triggering some type of error and not being > sent? Something is weird here, but I can't see it in what you've provided. > > > > On Tue, Aug 26, 2014 at 3:03 AM, Namalie Muthuthanthri < > nam...@rh...> wrote: > > Furthermore there are 30 market data requests that has to be sent . I’m > guessing this is why the heartbeat sequence number is set to 32. The > problem is when the fix message log files are checked the heartbeat message > gets sent out before the 30 market data requests. > > > > *From:* Namalie Muthuthanthri > *Sent:* Tuesday, 26 August, 2014 11:15 AM > *To:* 'Grant Birchmeier' > *Cc:* qui...@li... > *Subject:* RE: [Quickfix-users] Sends heartbeat messages with incorrect > sequence number > > > > Hi Grant, > > > > Thanks for your reply. > > > > No, there are no explicit logon calls in the code. However there’s code to > send market data requests on log on message. (onMessage(QuickFix43.Logon , > SessionID) method.) > > > > Thanks, > > Namalie. > > > > > > *From:* Grant Birchmeier [mailto:gbi...@co... > <gbi...@co...>] > *Sent:* Monday, 25 August, 2014 10:02 PM > *To:* Namalie Muthuthanthri > *Cc:* qui...@li... > *Subject:* Re: [Quickfix-users] Sends heartbeat messages with incorrect > sequence number > > > > I strongly suspect you are doing something weird in your code. > > > > Are you explicitly sending Logon messages? e.g. are you calling something > like sendToTarget(logon_message)? > > > > On Mon, Aug 25, 2014 at 12:49 AM, Namalie Muthuthanthri < > nam...@rh...> wrote: > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > QuickFix wrapper seems to be sending out heartbeat messages with seqNum > field set to 32 every once in a way immediately after receiving a logon > reponse from our counterparty. > > This is after having 141=Y on the login request. > > Below are the message logs (from a long time ago, but this is still > happening) from several instances this has happened. This happens > intermittently and is not noticed when a login is preceded by a logout . > We are using product version 1.0.3748 > > > > 20131120-09:46:53.256 : > 8=FIX.4.39=7735=A34=149=US52=20131120-09:46:53.25656=THEM98=0108=30141=Y10=218 > > 20131120-09:46:54.614 : 8=FIX.4.39=7735=A34=149= THEM > 52=20131120-09:46:54.51056= US 98=0108=30141=Y10=212 > > 20131120-09:47:24.691 : 8=FIX.4.39=6035=034=3249= US > 52=20131120-09:47:24.69156= THEM 10=17 > > > > > > 20131124-05:21:47.825 : > 8=FIX.4.39=7735=A34=149=THEM52=20131124-05:21:47.65056=US98=0108=30141=Y10=212 > > 20131124-05:22:17.856 : > 8=FIX.4.39=6035=034=3249=US52=20131124-05:22:17.85656=THEM10=175 > > 20131124-05:22:17.887 : > 8=FIX.4.39=5935=034=249=THEM52=20131124-05:22:17.70856=US10=128 > > 20131124-05:22:18.246 : > 8=FIX.4.39=6835=234=349=THEM52=20131124-05:22:18.00756=US7=216=010=248 > > > > 20131201-05:30:30.165 : > 8=FIX.4.39=7735=A34=149=US52=20131201-05:30:30.16556=THEM98=0108=30141=Y10=201 > > 20131201-05:30:31.600 : > 8=FIX.4.39=7735=A34=149=THEM52=20131201-05:30:31.45756=US98=0108=30141=Y10=206 > > 20131201-05:31:01.600 : > 8=FIX.4.39=6035=034=3249=US52=20131201-05:31:01.60056=THEM10=151 > > 20131201-05:31:01.927 : > 8=FIX.4.39=6835=234=249=THEM52=20131201-05:31:01.78656=US7=216=010=249 > > > > 20131209-14:37:42.386 : > 8=FIX.4.39=7735=A34=149=US52=20131209-14:37:42.38656=THEM98=0108=30141=Y10=224 > > 20131209-14:37:44.757 : > 8=FIX.4.39=7735=A34=149=THEM52=20131209-14:37:44.57256=US98=0108=30141=Y10=223 > > 20131209-14:38:14.850 : > 8=FIX.4.39=6035=034=3249=US52=20131209-14:38:14.85056=THEM10=177 > > > > Any help would be appreciated. > > > > Thanks, > > Namalie. > > > > > > > > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. Although this e-mail and any attachments are > believed to be free of any virus or any other defect which may affect any > computer or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free and no > responsibility is accepted by Rhicon Currency Management for any loss or > damage arising in any way from receipt or use thereof. This message is for > information purposes only, it does not constitute investment advice or an > offer or a solicitation to invest. The information herein is only directed > at professional clients and eligible counterparties and the services or > investments referred to in this e-mail and any attachments thereto are only > available to professional clients and eligible counterparties. Retail > clients should not rely on the information herein. Rhicon Currency > Management Pte Ltd is regulated by Monetary Authority of Singapore (Licence > No. CMS100198-2) and is registered with the CFTC as a Commodity Trading > Advisor and a member of the National Futures Association in the United > States (ID 0391877). Rhicon Currency Management (UK) Ltd is authorised and > regulated by the Financial Conduct Authority (FRN: 228713), and registered > as a limited company in England and Wales No. 4610606. > > > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > > > > > > -- > > Grant Birchmeier > > *Connamara Systems, LLC* > > *Made-To-Measure Trading Solutions.* > > Exactly what you need. No more. No less. > > http://connamara.com > > > > > > -- > > Grant Birchmeier > > *Connamara Systems, LLC* > > *Made-To-Measure Trading Solutions.* > > Exactly what you need. No more. No less. > > http://connamara.com > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com |
|
From: Grant B. <gbi...@co...> - 2014-08-26 15:25:28
|
Where are the MDRequests with sequence numbers 2-31? If the outgoing logon is 1, and the Heartbeat is 32, then your log should also be showing the 30 messages in-between. Are those in-between messages triggering some type of error and not being sent? Something is weird here, but I can't see it in what you've provided. On Tue, Aug 26, 2014 at 3:03 AM, Namalie Muthuthanthri <nam...@rh... > wrote: > Furthermore there are 30 market data requests that has to be sent . I’m > guessing this is why the heartbeat sequence number is set to 32. The > problem is when the fix message log files are checked the heartbeat message > gets sent out before the 30 market data requests. > > > > *From:* Namalie Muthuthanthri > *Sent:* Tuesday, 26 August, 2014 11:15 AM > *To:* 'Grant Birchmeier' > *Cc:* qui...@li... > *Subject:* RE: [Quickfix-users] Sends heartbeat messages with incorrect > sequence number > > > > Hi Grant, > > > > Thanks for your reply. > > > > No, there are no explicit logon calls in the code. However there’s code to > send market data requests on log on message. (onMessage(QuickFix43.Logon > , SessionID) method.) > > > > Thanks, > > Namalie. > > > > > > *From:* Grant Birchmeier [mailto:gbi...@co... > <gbi...@co...>] > *Sent:* Monday, 25 August, 2014 10:02 PM > *To:* Namalie Muthuthanthri > *Cc:* qui...@li... > *Subject:* Re: [Quickfix-users] Sends heartbeat messages with incorrect > sequence number > > > > I strongly suspect you are doing something weird in your code. > > > > Are you explicitly sending Logon messages? e.g. are you calling something > like sendToTarget(logon_message)? > > > > On Mon, Aug 25, 2014 at 12:49 AM, Namalie Muthuthanthri < > nam...@rh...> wrote: > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > QuickFix wrapper seems to be sending out heartbeat messages with seqNum > field set to 32 every once in a way immediately after receiving a logon > reponse from our counterparty. > > This is after having 141=Y on the login request. > > Below are the message logs (from a long time ago, but this is still > happening) from several instances this has happened. This happens > intermittently and is not noticed when a login is preceded by a logout . > We are using product version 1.0.3748 > > > > 20131120-09:46:53.256 : > 8=FIX.4.39=7735=A34=149=US52=20131120-09:46:53.25656=THEM98=0108=30141=Y10=218 > > 20131120-09:46:54.614 : 8=FIX.4.39=7735=A34=149= THEM > 52=20131120-09:46:54.51056= US 98=0108=30141=Y10=212 > > 20131120-09:47:24.691 : 8=FIX.4.39=6035=034=3249= US > 52=20131120-09:47:24.69156= THEM 10=17 > > > > > > 20131124-05:21:47.825 : > 8=FIX.4.39=7735=A34=149=THEM52=20131124-05:21:47.65056=US98=0108=30141=Y10=212 > > 20131124-05:22:17.856 : > 8=FIX.4.39=6035=034=3249=US52=20131124-05:22:17.85656=THEM10=175 > > 20131124-05:22:17.887 : > 8=FIX.4.39=5935=034=249=THEM52=20131124-05:22:17.70856=US10=128 > > 20131124-05:22:18.246 : > 8=FIX.4.39=6835=234=349=THEM52=20131124-05:22:18.00756=US7=216=010=248 > > > > 20131201-05:30:30.165 : > 8=FIX.4.39=7735=A34=149=US52=20131201-05:30:30.16556=THEM98=0108=30141=Y10=201 > > 20131201-05:30:31.600 : > 8=FIX.4.39=7735=A34=149=THEM52=20131201-05:30:31.45756=US98=0108=30141=Y10=206 > > 20131201-05:31:01.600 : > 8=FIX.4.39=6035=034=3249=US52=20131201-05:31:01.60056=THEM10=151 > > 20131201-05:31:01.927 : > 8=FIX.4.39=6835=234=249=THEM52=20131201-05:31:01.78656=US7=216=010=249 > > > > 20131209-14:37:42.386 : > 8=FIX.4.39=7735=A34=149=US52=20131209-14:37:42.38656=THEM98=0108=30141=Y10=224 > > 20131209-14:37:44.757 : > 8=FIX.4.39=7735=A34=149=THEM52=20131209-14:37:44.57256=US98=0108=30141=Y10=223 > > 20131209-14:38:14.850 : > 8=FIX.4.39=6035=034=3249=US52=20131209-14:38:14.85056=THEM10=177 > > > > Any help would be appreciated. > > > > Thanks, > > Namalie. > > > > > > > > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorised copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. Although this e-mail and any attachments are > believed to be free of any virus or any other defect which may affect any > computer or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free and no > responsibility is accepted by Rhicon Currency Management for any loss or > damage arising in any way from receipt or use thereof. This message is for > information purposes only, it does not constitute investment advice or an > offer or a solicitation to invest. The information herein is only directed > at professional clients and eligible counterparties and the services or > investments referred to in this e-mail and any attachments thereto are only > available to professional clients and eligible counterparties. Retail > clients should not rely on the information herein. Rhicon Currency > Management Pte Ltd is regulated by Monetary Authority of Singapore (Licence > No. CMS100198-2) and is registered with the CFTC as a Commodity Trading > Advisor and a member of the National Futures Association in the United > States (ID 0391877). Rhicon Currency Management (UK) Ltd is authorised and > regulated by the Financial Conduct Authority (FRN: 228713), and registered > as a limited company in England and Wales No. 4610606. > > > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Quickfix-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-users > > > > > > -- > > Grant Birchmeier > > *Connamara Systems, LLC* > > *Made-To-Measure Trading Solutions.* > > Exactly what you need. No more. No less. > > http://connamara.com > -- Grant Birchmeier *Connamara Systems, LLC* *Made-To-Measure Trading Solutions.* Exactly what you need. No more. No less. http://connamara.com |
|
From: Namalie M. <nam...@rh...> - 2014-08-26 08:03:35
|
Furthermore there are 30 market data requests that has to be sent . I’m guessing this is why the heartbeat sequence number is set to 32. The problem is when the fix message log files are checked the heartbeat message gets sent out before the 30 market data requests. From: Namalie Muthuthanthri Sent: Tuesday, 26 August, 2014 11:15 AM To: 'Grant Birchmeier' Cc: qui...@li... Subject: RE: [Quickfix-users] Sends heartbeat messages with incorrect sequence number Hi Grant, Thanks for your reply. No, there are no explicit logon calls in the code. However there’s code to send market data requests on log on message. (onMessage(QuickFix43.Logon , SessionID) method.) Thanks, Namalie. From: Grant Birchmeier [mailto:gbi...@co...] Sent: Monday, 25 August, 2014 10:02 PM To: Namalie Muthuthanthri Cc: qui...@li...<mailto:qui...@li...> Subject: Re: [Quickfix-users] Sends heartbeat messages with incorrect sequence number I strongly suspect you are doing something weird in your code. Are you explicitly sending Logon messages? e.g. are you calling something like sendToTarget(logon_message)? On Mon, Aug 25, 2014 at 12:49 AM, Namalie Muthuthanthri <nam...@rh...<mailto:nam...@rh...>> wrote: QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Hi, QuickFix wrapper seems to be sending out heartbeat messages with seqNum field set to 32 every once in a way immediately after receiving a logon reponse from our counterparty. This is after having 141=Y on the login request. Below are the message logs (from a long time ago, but this is still happening) from several instances this has happened. This happens intermittently and is not noticed when a login is preceded by a logout . We are using product version 1.0.3748 20131120-09<tel:20131120-09>:46:53.256 : 8=FIX.4.39=7735=A34=149=US52=20131120-09:46:53.25656=THEM98=0108=30141=Y10=218 20131120-09<tel:20131120-09>:46:54.614 : 8=FIX.4.39=7735=A34=149= THEM 52=20131120-09:46:54.51056= US 98=0108=30141=Y10=212 20131120-09<tel:20131120-09>:47:24.691 : 8=FIX.4.39=6035=034=3249= US 52=20131120-09:47:24.69156= THEM 10=17 20131124-05<tel:20131124-05>:21:47.825 : 8=FIX.4.39=7735=A34=149=THEM52=20131124-05:21:47.65056=US98=0108=30141=Y10=212 20131124-05<tel:20131124-05>:22:17.856 : 8=FIX.4.39=6035=034=3249=US52=20131124-05:22:17.85656=THEM10=175 20131124-05<tel:20131124-05>:22:17.887 : 8=FIX.4.39=5935=034=249=THEM52=20131124-05:22:17.70856=US10=128 20131124-05<tel:20131124-05>:22:18.246 : 8=FIX.4.39=6835=234=349=THEM52=20131124-05:22:18.00756=US7=216=010=248 20131201-05<tel:20131201-05>:30:30.165 : 8=FIX.4.39=7735=A34=149=US52=20131201-05:30:30.16556=THEM98=0108=30141=Y10=201 20131201-05<tel:20131201-05>:30:31.600 : 8=FIX.4.39=7735=A34=149=THEM52=20131201-05:30:31.45756=US98=0108=30141=Y10=206 20131201-05<tel:20131201-05>:31:01.600 : 8=FIX.4.39=6035=034=3249=US52=20131201-05:31:01.60056=THEM10=151 20131201-05<tel:20131201-05>:31:01.927 : 8=FIX.4.39=6835=234=249=THEM52=20131201-05:31:01.78656=US7=216=010=249 20131209-14<tel:20131209-14>:37:42.386 : 8=FIX.4.39=7735=A34=149=US52=20131209-14:37:42.38656=THEM98=0108=30141=Y10=224 20131209-14:37:44.757 : 8=FIX.4.39=7735=A34=149=THEM52=20131209-14:37:44.57256=US98=0108=30141=Y10=223 20131209-14:38:14.850 : 8=FIX.4.39=6035=034=3249=US52=20131209-14:38:14.85056=THEM10=177 Any help would be appreciated. Thanks, Namalie. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Although this e-mail and any attachments are believed to be free of any virus or any other defect which may affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Rhicon Currency Management for any loss or damage arising in any way from receipt or use thereof. This message is for information purposes only, it does not constitute investment advice or an offer or a solicitation to invest. The information herein is only directed at professional clients and eligible counterparties and the services or investments referred to in this e-mail and any attachments thereto are only available to professional clients and eligible counterparties. Retail clients should not rely on the information herein. Rhicon Currency Management Pte Ltd is regulated by Monetary Authority of Singapore (Licence No. CMS100198-2) and is registered with the CFTC as a Commodity Trading Advisor and a member of the National Futures Association in the United States (ID 0391877). Rhicon Currency Management (UK) Ltd is authorised and regulated by the Financial Conduct Authority (FRN: 228713), and registered as a limited company in England and Wales No. 4610606. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Quickfix-users mailing list Qui...@li...<mailto:Qui...@li...> https://lists.sourceforge.net/lists/listinfo/quickfix-users -- Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com |
|
From: Namalie M. <nam...@rh...> - 2014-08-26 03:15:13
|
Hi Grant, Thanks for your reply. No, there are no explicit logon calls in the code. However there’s code to send market data requests on log on message. (onMessage(QuickFix43.Logon , SessionID) method.) Thanks, Namalie. From: Grant Birchmeier [mailto:gbi...@co...] Sent: Monday, 25 August, 2014 10:02 PM To: Namalie Muthuthanthri Cc: qui...@li... Subject: Re: [Quickfix-users] Sends heartbeat messages with incorrect sequence number I strongly suspect you are doing something weird in your code. Are you explicitly sending Logon messages? e.g. are you calling something like sendToTarget(logon_message)? On Mon, Aug 25, 2014 at 12:49 AM, Namalie Muthuthanthri <nam...@rh...<mailto:nam...@rh...>> wrote: QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Hi, QuickFix wrapper seems to be sending out heartbeat messages with seqNum field set to 32 every once in a way immediately after receiving a logon reponse from our counterparty. This is after having 141=Y on the login request. Below are the message logs (from a long time ago, but this is still happening) from several instances this has happened. This happens intermittently and is not noticed when a login is preceded by a logout . We are using product version 1.0.3748 20131120-09<tel:20131120-09>:46:53.256 : 8=FIX.4.39=7735=A34=149=US52=20131120-09:46:53.25656=THEM98=0108=30141=Y10=218 20131120-09<tel:20131120-09>:46:54.614 : 8=FIX.4.39=7735=A34=149= THEM 52=20131120-09:46:54.51056= US 98=0108=30141=Y10=212 20131120-09<tel:20131120-09>:47:24.691 : 8=FIX.4.39=6035=034=3249= US 52=20131120-09:47:24.69156= THEM 10=17 20131124-05<tel:20131124-05>:21:47.825 : 8=FIX.4.39=7735=A34=149=THEM52=20131124-05:21:47.65056=US98=0108=30141=Y10=212 20131124-05<tel:20131124-05>:22:17.856 : 8=FIX.4.39=6035=034=3249=US52=20131124-05:22:17.85656=THEM10=175 20131124-05<tel:20131124-05>:22:17.887 : 8=FIX.4.39=5935=034=249=THEM52=20131124-05:22:17.70856=US10=128 20131124-05<tel:20131124-05>:22:18.246 : 8=FIX.4.39=6835=234=349=THEM52=20131124-05:22:18.00756=US7=216=010=248 20131201-05<tel:20131201-05>:30:30.165 : 8=FIX.4.39=7735=A34=149=US52=20131201-05:30:30.16556=THEM98=0108=30141=Y10=201 20131201-05<tel:20131201-05>:30:31.600 : 8=FIX.4.39=7735=A34=149=THEM52=20131201-05:30:31.45756=US98=0108=30141=Y10=206 20131201-05<tel:20131201-05>:31:01.600 : 8=FIX.4.39=6035=034=3249=US52=20131201-05:31:01.60056=THEM10=151 20131201-05<tel:20131201-05>:31:01.927 : 8=FIX.4.39=6835=234=249=THEM52=20131201-05:31:01.78656=US7=216=010=249 20131209-14<tel:20131209-14>:37:42.386 : 8=FIX.4.39=7735=A34=149=US52=20131209-14:37:42.38656=THEM98=0108=30141=Y10=224 20131209-14:37:44.757 : 8=FIX.4.39=7735=A34=149=THEM52=20131209-14:37:44.57256=US98=0108=30141=Y10=223 20131209-14:38:14.850 : 8=FIX.4.39=6035=034=3249=US52=20131209-14:38:14.85056=THEM10=177 Any help would be appreciated. Thanks, Namalie. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Although this e-mail and any attachments are believed to be free of any virus or any other defect which may affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Rhicon Currency Management for any loss or damage arising in any way from receipt or use thereof. This message is for information purposes only, it does not constitute investment advice or an offer or a solicitation to invest. The information herein is only directed at professional clients and eligible counterparties and the services or investments referred to in this e-mail and any attachments thereto are only available to professional clients and eligible counterparties. Retail clients should not rely on the information herein. Rhicon Currency Management Pte Ltd is regulated by Monetary Authority of Singapore (Licence No. CMS100198-2) and is registered with the CFTC as a Commodity Trading Advisor and a member of the National Futures Association in the United States (ID 0391877). Rhicon Currency Management (UK) Ltd is authorised and regulated by the Financial Conduct Authority (FRN: 228713), and registered as a limited company in England and Wales No. 4610606. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Quickfix-users mailing list Qui...@li...<mailto:Qui...@li...> https://lists.sourceforge.net/lists/listinfo/quickfix-users -- Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com |
38 messages has been excluded from this view by a project administrator.
