quickfix-developers Mailing List for QuickFIX (Page 159)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2026 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Belinda I. <Bel...@gb...> - 2006-03-22 01:22:50
|
Hi Everyone,
We are having some problems resending messages when a resend request is
received. The error we are getting back is as follows -
58=3DREJECT Missing or invalid value for conditionally required fields =
in
PartyID repeating group.
I think the problem may be related to groups not getting copied in the
correct order when the message to be resent is created.
In Session#nextResendRequest the message is created via 'fromString' -
Message msg =3D new Message((String) messages.get(i), dataDictionary);
We have done some unit tests to confirm that the order is different when
a message is created via 'fromString'. =20
Here is our validate method, -
private void validate(Message message) throws InvalidMessage {
MessageFactory messageFactory =3D new
DefaultMessageFactory();=09
String msgType =3D
MessageUtils.getMessageType(message.toString());
Message message2;
message2 =3D
messageFactory.create(dataDictionary.getVersion(), msgType);
message2.fromString(message.toString(), dataDictionary,
false);
System.out.println("Input Message - " +
message.toXML());
System.out.println("Message 2 - " + message2.toXML());
}
And here is the output. The group fields are in different order -
Input Message - <?xml version=3D"1.0" encoding=3D"ISO-8859-1"?>
<message>
<header>
<field number=3D"8"><![CDATA[FIX.4.4]]></field>
<field number=3D"9"><![CDATA[171]]></field>
<field number=3D"35"><![CDATA[D]]></field>
<field number=3D"49"><![CDATA[SenderCompId]]></field>
<field number=3D"56"><![CDATA[TargetCompId]]></field>
</header>
<body>
<field number=3D"11"><![CDATA[183339]]></field>
<field number=3D"22"><![CDATA[8]]></field>
<field number=3D"38"><![CDATA[1]]></field>
<field number=3D"40"><![CDATA[2]]></field>
<field number=3D"44"><![CDATA[12]]></field>
<field number=3D"48"><![CDATA[BHP]]></field>
<field number=3D"54"><![CDATA[2]]></field>
<field number=3D"55"><![CDATA[BHP]]></field>
<field number=3D"59"><![CDATA[1]]></field>
<field number=3D"60"><![CDATA[20060223-22:38:33]]></field>
<field number=3D"526"><![CDATA[3620]]></field>
<group>
<field number=3D"448"><![CDATA[8]]></field>
<field number=3D"447"><![CDATA[D]]></field>
<field number=3D"452"><![CDATA[4]]></field>
</group>
<group>
<field number=3D"448"><![CDATA[AAA35354]]></field>
<field number=3D"447"><![CDATA[D]]></field>
<field number=3D"452"><![CDATA[3]]></field>
</group>
</body>
<trailer>
<field number=3D"10"><![CDATA[168]]></field>
</trailer>
</message>
Message 2 - <?xml version=3D"1.0" encoding=3D"ISO-8859-1"?>
<message>
<header>
<field number=3D"8"><![CDATA[FIX.4.4]]></field>
<field number=3D"9"><![CDATA[171]]></field>
<field number=3D"35"><![CDATA[D]]></field>
<field number=3D"49"><![CDATA[SenderCompId]]></field>
<field number=3D"56"><![CDATA[TargetCompId]]></field>
</header>
<body>
<field number=3D"11"><![CDATA[183339]]></field>
<field number=3D"22"><![CDATA[8]]></field>
<field number=3D"38"><![CDATA[1]]></field>
<field number=3D"40"><![CDATA[2]]></field>
<field number=3D"44"><![CDATA[12]]></field>
<field number=3D"48"><![CDATA[BHP]]></field>
<field number=3D"54"><![CDATA[2]]></field>
<field number=3D"55"><![CDATA[BHP]]></field>
<field number=3D"59"><![CDATA[1]]></field>
<field number=3D"60"><![CDATA[20060223-22:38:33]]></field>
<field number=3D"453"><![CDATA[2]]></field>
<field number=3D"526"><![CDATA[3620]]></field>
<group>
<field number=3D"447"><![CDATA[D]]></field>
<field number=3D"448"><![CDATA[8]]></field>
<field number=3D"452"><![CDATA[4]]></field>
</group>
<group>
<field number=3D"447"><![CDATA[D]]></field>
<field number=3D"448"><![CDATA[AAA35354]]></field>
<field number=3D"452"><![CDATA[3]]></field>
</group>
</body>
<trailer>
<field number=3D"10"><![CDATA[168]]></field>
</trailer>
</message>
Has anyone else had any issue with this?
Any help is appreciated.
Regards,
Belinda
|
|
From: James R. <jam...@gm...> - 2006-03-21 17:28:36
|
Thanks for the information Sean and Caleb. We will upgrade to QuickFIX 1.11.1 and also look into moving to a database based message store. Thanks for your help. -jr |
|
From: Caleb E. <cal...@gm...> - 2006-03-21 17:18:38
|
On 3/21/06, James Reed <jam...@gm...> wrote: > > We've experienced unexplained crashes where no core dumps are generated > nor is there anything in the logs to indicate what the problem is. We hav= e > only noticed that the crashes tend to occur when a large number of client= s > attempt to connect at once or if a significant portion of the connected > clients try to send messages in a short span of time. > > We are using QuickFIX 1.10.2, with g++ 3.2.3, on RHEL AS Release 3. Our > application uses one Initiator and one Acceptor. The Acceptor is configur= ed > with 288 Sessions. Our application is also configured to use a StdOutLogg= er > to minimize usage of file descriptors. The fdlimit for the user account > running the process is 2048. I know there is not much to go on from the > information presented, but does anyone have any ideas about what could > possibly happening here? > > Thanks. > > We've run the application in a debugger and found the following upon > crashing: > > Stack Traces > > Incident #1: > > #0 0x00d22b60 in pthread_detach () from /lib/tls/libpthread.so.0 > #1 0x00a4dc3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344 > #2 0x00a07334 in FIX::ThreadedSocketAcceptor::removeThread > (this=3D0x837d210, s=3D1216) > at stl_map.h:221 > #3 0x00a07453 in FIX::ThreadedSocketAcceptor::socketThread (p=3D0x6ea61a= 10) > at ThreadedSocketConnection.h:51 > #4 0x00d21dec in start_thread () from /lib/tls/libpthread.so.0 > #5 0x005a8a2a in clone () from /lib/tls/libc.so.6 > Judging by this call stack and the second one, you've hit a bug that has been fixed in 1.11.1. There are resources in the ThreadedSocketAcceptor an= d T.S.Connector classes that were being modified without holding a mutex in all versions of QuickFIX prior to 1.11.1. Try updating to the latest version of QuickFIX and I believe this problem will disappear (though I really dislike the use of pthread_detach...) -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Sean K. <sea...@pi...> - 2006-03-21 17:17:36
|
The file descriptor limit in linux is separate from the FD_SETSIZE value =
of 1024. In other words, you could set the nofile limit for a user to =
10,240 and still have the FD_SET limitation of 1024. There is a hack to =
get around the FD_SET hard limit, but as far as I've found it is not =
recommended. The FD_SET is a sized array that is indexed based on the =
created socket file descriptor. Once you've exceeded 1024 fds created =
by your process, you will get unexpected behavior. This will be most =
apparent when a lot of sockets are being created at the same time.
=20
Our solution to a similar problem here has been to utilize the database =
store, decreasing the fds per session to 1 for the socket itself. =
Another possible solution could be to run multiple acceptors (of course, =
then you have to do some kind of load balancing to hit different ports).
=20
--Sean
-----Original Message-----
From: James Reed [mailto:jam...@gm...]
Sent: Tuesday, March 21, 2006 12:07 PM
To: Sean Kirkpatrick; qui...@li...
Subject: Re: [Quickfix-developers] crashes while under moderate message =
load
Hello Sean,
We are using a File store for the message store. Our app makes a call to =
setrlimit and sets the fdlimit to 2048. Currently our app is running =
with 1301 fds being used without problems.
Thanks.
On 3/21/06, Sean Kirkpatrick < sea...@pi...> =
wrote:=20
What are you using for the message store? If the acceptor is using =
files, then I believe 4 file descriptors are created per session =
(seqnums, session, body, and header). Throw a socket in per session and =
you are most likely going over the 1024 FD_SET limit with 288 =
sessions...
=20
--Sean
-----Original Message-----
From: qui...@li... [mailto: =
qui...@li...]On Behalf Of James Reed
Sent: Tuesday, March 21, 2006 11:50 AM
To: qui...@li...
Subject: [Quickfix-developers] crashes while under moderate message load
Hello all,
We've experienced unexplained crashes where no core dumps are generated =
nor is there anything in the logs to indicate what the problem is. We =
have only noticed that the crashes tend to occur when a large number of =
clients attempt to connect at once or if a significant portion of the =
connected clients try to send messages in a short span of time.
We are using QuickFIX 1.10.2, with g++ 3.2.3, on RHEL AS Release 3. Our =
application uses one Initiator and one Acceptor. The Acceptor is =
configured with 288 Sessions. Our application is also configured to use =
a StdOutLogger to minimize usage of file descriptors. The fdlimit for =
the user account running the process is 2048. I know there is not much =
to go on from the information presented, but does anyone have any ideas =
about what could possibly happening here?
Thanks.
We've run the application in a debugger and found the following upon =
crashing:
Stack Traces
Incident #1:
#0 0x00d22b60 in pthread_detach () from /lib/tls/libpthread.so.0
#1 0x00a4dc3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2 0x00a07334 in FIX::ThreadedSocketAcceptor::removeThread =
(this=3D0x837d210, s=3D1216)
at stl_map.h:221
#3 0x00a07453 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0x6ea61a10)
at ThreadedSocketConnection.h:51
#4 0x00d21dec in start_thread () from /lib/tls/libpthread.so.0
#5 0x005a8a2a in clone () from /lib/tls/libc.so.6
Incident #2:
=20
#0 0x00a8bb60 in pthread_detach () from /lib/tls/libpthread.so.0
#1 0x00de7c3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2 0x00da1334 in FIX::ThreadedSocketAcceptor::removeThread =
(this=3D0xb6a4f448, s=3D1170)
at stl_map.h:221
#3 0x00da1453 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0xa95f8a10)
at ThreadedSocketConnection.h:51
#4 0x00a8adec in start_thread () from /lib/tls/libpthread.so.0
#5 0x00595a2a in clone () from /lib/tls/libc.so.6
Incident #3:
=20
#0 0x0027e6d7 in std::string::_Rep::_M_grab () from =
/usr/lib/libstdc++.so.5
#1 0x0027e81c in std::basic_string<char, std::char_traits<char>, =
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.5
#2 0x08077b56 in FieldBase (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:45
#3 0x08077afa in StringField (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:45
#4 0x08077a2e in BeginString (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:45
#5 0x0807782f in SessionID (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:119
#6 0x00f158bb in std::_Rb_tree<FIX::SessionID, FIX::SessionID, =
std::_Identity<FIX::SessionID>, std::less<FIX::SessionID>, =
std::allocator<FIX::SessionID> >::_M_copy (
this=3D0xb75dea20, __x=3D0x93795f8, __p=3D0x92e9af8) at new:89
#7 0x00f15df0 in _Rb_tree (this=3D0xb75dea20, __x=3D@0xbfff97ec) at =
stl_tree.h:648
#8 0x00f14189 in FIX::Initiator::isLoggedOn (this=3D0xbfff97d0) at =
stl_set.h:131
#9 0x00f19961 in FIX::SocketInitiator::onStart (this=3D0xbfff97d0)
at SocketInitiator.cpp:86
#10 0x00f142e7 in FIX::Initiator::startThread (p=3D0xb75de8c0) at =
Initiator.cpp:243
#11 0x0058fdec in start_thread () from /lib/tls/libpthread.so.0
#12 0x00393a2a in clone () from /lib/tls/libc.so.6
|
|
From: James R. <jam...@gm...> - 2006-03-21 17:07:21
|
Hello Sean, We are using a File store for the message store. Our app makes a call to setrlimit and sets the fdlimit to 2048. Currently our app is running with 1301 fds being used without problems. Thanks. On 3/21/06, Sean Kirkpatrick <sea...@pi...> wrote= : > > What are you using for the message store? If the acceptor is using files= , > then I believe 4 file descriptors are created per session (seqnums, sessi= on, > body, and header). Throw a socket in per session and you are most likely > going over the 1024 FD_SET limit with 288 sessions... > > --Sean > > -----Original Message----- > *From:* qui...@li... [mailto: > qui...@li...]*On Behalf Of *James Reed > *Sent:* Tuesday, March 21, 2006 11:50 AM > *To:* qui...@li... > *Subject:* [Quickfix-developers] crashes while under moderate message loa= d > > Hello all, > > We've experienced unexplained crashes where no core dumps are generated > nor is there anything in the logs to indicate what the problem is. We hav= e > only noticed that the crashes tend to occur when a large number of client= s > attempt to connect at once or if a significant portion of the connected > clients try to send messages in a short span of time. > > We are using QuickFIX 1.10.2, with g++ 3.2.3, on RHEL AS Release 3. Our > application uses one Initiator and one Acceptor. The Acceptor is configur= ed > with 288 Sessions. Our application is also configured to use a StdOutLogg= er > to minimize usage of file descriptors. The fdlimit for the user account > running the process is 2048. I know there is not much to go on from the > information presented, but does anyone have any ideas about what could > possibly happening here? > > Thanks. > > We've run the application in a debugger and found the following upon > crashing: > > Stack Traces > > Incident #1: > > #0 0x00d22b60 in pthread_detach () from /lib/tls/libpthread.so.0 > #1 0x00a4dc3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344 > #2 0x00a07334 in FIX::ThreadedSocketAcceptor::removeThread > (this=3D0x837d210, s=3D1216) > at stl_map.h:221 > #3 0x00a07453 in FIX::ThreadedSocketAcceptor::socketThread (p=3D0x6ea61a= 10) > at ThreadedSocketConnection.h:51 > #4 0x00d21dec in start_thread () from /lib/tls/libpthread.so.0 > #5 0x005a8a2a in clone () from /lib/tls/libc.so.6 > > Incident #2: > > #0 0x00a8bb60 in pthread_detach () from /lib/tls/libpthread.so.0 > #1 0x00de7c3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344 > #2 0x00da1334 in FIX::ThreadedSocketAcceptor::removeThread > (this=3D0xb6a4f448, s=3D1170) > at stl_map.h:221 > #3 0x00da1453 in FIX::ThreadedSocketAcceptor::socketThread (p=3D0xa95f8a= 10) > at ThreadedSocketConnection.h:51 > #4 0x00a8adec in start_thread () from /lib/tls/libpthread.so.0 > #5 0x00595a2a in clone () from /lib/tls/libc.so.6 > > Incident #3: > > #0 0x0027e6d7 in std::string::_Rep::_M_grab () from > /usr/lib/libstdc++.so.5 > #1 0x0027e81c in std::basic_string<char, std::char_traits<char>, > std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.5 > #2 0x08077b56 in FieldBase (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) at > SessionID.h:45 > #3 0x08077afa in StringField (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) = at > SessionID.h:45 > #4 0x08077a2e in BeginString (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) = at > SessionID.h:45 > #5 0x0807782f in SessionID (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) at > SessionID.h:119 > #6 0x00f158bb in std::_Rb_tree<FIX::SessionID, FIX::SessionID, > std::_Identity<FIX::SessionID>, std::less<FIX::SessionID>, > std::allocator<FIX::SessionID> >::_M_copy ( > this=3D0xb75dea20, __x=3D0x93795f8, __p=3D0x92e9af8) at new:89 > #7 0x00f15df0 in _Rb_tree (this=3D0xb75dea20, __x=3D@0xbfff97ec) at > stl_tree.h:648 > #8 0x00f14189 in FIX::Initiator::isLoggedOn (this=3D0xbfff97d0) at > stl_set.h:131 > #9 0x00f19961 in FIX::SocketInitiator::onStart (this=3D0xbfff97d0) > at SocketInitiator.cpp:86 > #10 0x00f142e7 in FIX::Initiator::startThread (p=3D0xb75de8c0) at > Initiator.cpp:243 > #11 0x0058fdec in start_thread () from /lib/tls/libpthread.so.0 > #12 0x00393a2a in clone () from /lib/tls/libc.so.6 > > |
|
From: Sean K. <sea...@pi...> - 2006-03-21 17:01:27
|
What are you using for the message store? If the acceptor is using =
files, then I believe 4 file descriptors are created per session =
(seqnums, session, body, and header). Throw a socket in per session and =
you are most likely going over the 1024 FD_SET limit with 288 =
sessions...
=20
--Sean
-----Original Message-----
From: qui...@li... =
[mailto:qui...@li...]On Behalf Of =
James Reed
Sent: Tuesday, March 21, 2006 11:50 AM
To: qui...@li...
Subject: [Quickfix-developers] crashes while under moderate message load
Hello all,
We've experienced unexplained crashes where no core dumps are generated =
nor is there anything in the logs to indicate what the problem is. We =
have only noticed that the crashes tend to occur when a large number of =
clients attempt to connect at once or if a significant portion of the =
connected clients try to send messages in a short span of time.
We are using QuickFIX 1.10.2, with g++ 3.2.3, on RHEL AS Release 3. Our =
application uses one Initiator and one Acceptor. The Acceptor is =
configured with 288 Sessions. Our application is also configured to use =
a StdOutLogger to minimize usage of file descriptors. The fdlimit for =
the user account running the process is 2048. I know there is not much =
to go on from the information presented, but does anyone have any ideas =
about what could possibly happening here?
Thanks.
We've run the application in a debugger and found the following upon =
crashing:
Stack Traces
Incident #1:
#0 0x00d22b60 in pthread_detach () from /lib/tls/libpthread.so.0
#1 0x00a4dc3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2 0x00a07334 in FIX::ThreadedSocketAcceptor::removeThread =
(this=3D0x837d210, s=3D1216)
at stl_map.h:221
#3 0x00a07453 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0x6ea61a10)
at ThreadedSocketConnection.h:51
#4 0x00d21dec in start_thread () from /lib/tls/libpthread.so.0
#5 0x005a8a2a in clone () from /lib/tls/libc.so.6
Incident #2:
=20
#0 0x00a8bb60 in pthread_detach () from /lib/tls/libpthread.so.0
#1 0x00de7c3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2 0x00da1334 in FIX::ThreadedSocketAcceptor::removeThread =
(this=3D0xb6a4f448, s=3D1170)
at stl_map.h:221
#3 0x00da1453 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0xa95f8a10)
at ThreadedSocketConnection.h:51
#4 0x00a8adec in start_thread () from /lib/tls/libpthread.so.0
#5 0x00595a2a in clone () from /lib/tls/libc.so.6
Incident #3:
=20
#0 0x0027e6d7 in std::string::_Rep::_M_grab () from =
/usr/lib/libstdc++.so.5
#1 0x0027e81c in std::basic_string<char, std::char_traits<char>, =
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.5
#2 0x08077b56 in FieldBase (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:45
#3 0x08077afa in StringField (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:45
#4 0x08077a2e in BeginString (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:45
#5 0x0807782f in SessionID (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) =
at SessionID.h:119
#6 0x00f158bb in std::_Rb_tree<FIX::SessionID, FIX::SessionID, =
std::_Identity<FIX::SessionID>, std::less<FIX::SessionID>, =
std::allocator<FIX::SessionID> >::_M_copy (
this=3D0xb75dea20, __x=3D0x93795f8, __p=3D0x92e9af8) at new:89
#7 0x00f15df0 in _Rb_tree (this=3D0xb75dea20, __x=3D@0xbfff97ec) at =
stl_tree.h:648
#8 0x00f14189 in FIX::Initiator::isLoggedOn (this=3D0xbfff97d0) at =
stl_set.h:131
#9 0x00f19961 in FIX::SocketInitiator::onStart (this=3D0xbfff97d0)
at SocketInitiator.cpp:86
#10 0x00f142e7 in FIX::Initiator::startThread (p=3D0xb75de8c0) at =
Initiator.cpp:243
#11 0x0058fdec in start_thread () from /lib/tls/libpthread.so.0
#12 0x00393a2a in clone () from /lib/tls/libc.so.6
|
|
From: James R. <jam...@gm...> - 2006-03-21 16:50:34
|
Hello all,
We've experienced unexplained crashes where no core dumps are generated nor
is there anything in the logs to indicate what the problem is. We have only
noticed that the crashes tend to occur when a large number of clients
attempt to connect at once or if a significant portion of the connected
clients try to send messages in a short span of time.
We are using QuickFIX 1.10.2, with g++ 3.2.3, on RHEL AS Release 3. Our
application uses one Initiator and one Acceptor. The Acceptor is configured
with 288 Sessions. Our application is also configured to use a StdOutLogger
to minimize usage of file descriptors. The fdlimit for the user account
running the process is 2048. I know there is not much to go on from the
information presented, but does anyone have any ideas about what could
possibly happening here?
Thanks.
We've run the application in a debugger and found the following upon
crashing:
Stack Traces
Incident #1:
#0 0x00d22b60 in pthread_detach () from /lib/tls/libpthread.so.0
#1 0x00a4dc3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2 0x00a07334 in FIX::ThreadedSocketAcceptor::removeThread (this=3D0x837d2=
10,
s=3D1216)
at stl_map.h:221
#3 0x00a07453 in FIX::ThreadedSocketAcceptor::socketThread (p=3D0x6ea61a10=
)
at ThreadedSocketConnection.h:51
#4 0x00d21dec in start_thread () from /lib/tls/libpthread.so.0
#5 0x005a8a2a in clone () from /lib/tls/libc.so.6
Incident #2:
#0 0x00a8bb60 in pthread_detach () from /lib/tls/libpthread.so.0
#1 0x00de7c3b in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2 0x00da1334 in FIX::ThreadedSocketAcceptor::removeThread
(this=3D0xb6a4f448, s=3D1170)
at stl_map.h:221
#3 0x00da1453 in FIX::ThreadedSocketAcceptor::socketThread (p=3D0xa95f8a10=
)
at ThreadedSocketConnection.h:51
#4 0x00a8adec in start_thread () from /lib/tls/libpthread.so.0
#5 0x00595a2a in clone () from /lib/tls/libc.so.6
Incident #3:
#0 0x0027e6d7 in std::string::_Rep::_M_grab () from
/usr/lib/libstdc++.so.5
#1 0x0027e81c in std::basic_string<char, std::char_traits<char>,
std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.5
#2 0x08077b56 in FieldBase (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) at
SessionID.h:45
#3 0x08077afa in StringField (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) at
SessionID.h:45
#4 0x08077a2e in BeginString (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) at
SessionID.h:45
#5 0x0807782f in SessionID (this=3D0x92e9b68, _ctor_arg=3D@0x9379608) at
SessionID.h:119
#6 0x00f158bb in std::_Rb_tree<FIX::SessionID, FIX::SessionID,
std::_Identity<FIX::SessionID>, std::less<FIX::SessionID>,
std::allocator<FIX::SessionID> >::_M_copy (
this=3D0xb75dea20, __x=3D0x93795f8, __p=3D0x92e9af8) at new:89
#7 0x00f15df0 in _Rb_tree (this=3D0xb75dea20, __x=3D@0xbfff97ec) at
stl_tree.h:648
#8 0x00f14189 in FIX::Initiator::isLoggedOn (this=3D0xbfff97d0) at
stl_set.h:131
#9 0x00f19961 in FIX::SocketInitiator::onStart (this=3D0xbfff97d0)
at SocketInitiator.cpp:86
#10 0x00f142e7 in FIX::Initiator::startThread (p=3D0xb75de8c0) at
Initiator.cpp:243
#11 0x0058fdec in start_thread () from /lib/tls/libpthread.so.0
#12 0x00393a2a in clone () from /lib/tls/libc.so.6
|
|
From: Edde <edd...@gm...> - 2006-03-21 14:07:39
|
Hi Guys, I appologize to bother you with this once again... >Oren wrote: >So I suggest that you clear the expected sequence number *before* starting the application. >That way QuickFIX will allways request a retransmission from 1 thru infinity, and since QuickFIX >requested the retransmissions it will know what to do with them. I've now rewritten my application according to this design and it seems to work fine. However, I would still like to know if there is a way to know when QuickFIX has resent all messages? >Joerg wrote: >BTW, a TestRequest with a unique has to be answered by a Heartbeat with this unique id. >If you get this specific heartbeat, you know that the other side must have processed all >messages preceding this TestRequest. Of course, this does not prevent further resend >processing at any later point of time. I've tried this approach but unfortunately our counterparty doesn't quite live up the FIX specification in this regard. It works great most of the time but every now and then our counterparty "forget" to answer my TestRequest with the corresponding heartbeat. Is there another way to do this? I've noticed that QuickFIX logs the following event when the Resend has finished: "ResendRequest for messages FROM: 1 TO: XXXX has been satisfied.". Is there a way for me to get this message on an application level? Another solution I was thinking off was to check for the first message wher= e the PossDupFlag isn't set and then assume that the Resend is finished but I'm not sure this is a fail proof solution. Any comments or suggestions will be deeply appreciated. Thanks, /Eddie |
|
From: Brad H. <Bra...@gb...> - 2006-03-21 04:56:49
|
> Hi Everyone,
>=20
> I'm having some problems sending a valid NewOrderCross (s) message
> using quickfix/j 1.0.0 beta3. The nested Party group is being added
> at the very end of the Side group, but I need the 38 tag (OrderQty) to
> be after the Party group.
>=20
Here's an example of the message that quickfix is outputting.
8=3DFIX.4.4=20
9=3D244=20
35=3Ds=20
34=3D5=20
49=3Dsender=20
52=3D20060319-09:08:20.881=20
56=3Dtarget=20
22=3D8=20
40=3D2=20
44=3D9=20
48=3DABC=20
55=3DABC=20
60=3D20060319-09:08:19=20
548=3D184214=20
549=3D2=20
550=3D0=20
552=3D2=20
54=3D1=20
38=3D9=20
453=3D2=20
448=3D8=20
447=3DD=20
452=3D4=20
448=3DAAA35777=20
447=3DD=20
452=3D3=20
54=3D2=20
38=3D9=20
453=3D2=20
448=3D8=20
447=3DD=20
452=3D4=20
448=3Daaa=20
447=3DD=20
452=3D3=20
10=3D100=20
The data dictionary has them specified in the correct order. I can see
how the ordering of fields within a group is decided:
// from NewOrderCross
public static class NoSides extends Group {
public NoSides() {
super(552, 54,
new int[] {54, 11, 526, 583, 229, 75, 1, 660, 581, 589, 590,
591, 70, 854, 38, 152, 516, 468, 469, 12, 13, 479, 497, 528, 529, 582,
121, 120, 775, 58, 354, 355, 77, 203, 544, 635, 377, 659, 0 } );
}
But none of the tags in the nested group are in here (453, 448, 447,
452). How do we put the nested group in the correct spot?
Many thanks,
Brad.
Here's how we're creating a NoSides group:
// side, brokerCode, bookingRef, unitQty passed in..
NoSides sides =3D new NoSides();
sides.set(new Side(side)));=20
=09
// Add PartyIDs
quickfix.fix44.NewOrderCross.NoSides.NoPartyIDs partyIds
=3D=20
new
quickfix.fix44.NewOrderCross.NoSides.NoPartyIDs();=09
partyIds.set(new PartyID(brokerCode));
partyIds.set(new
PartyIDSource(PartyIDSource.PROPRIETARY_CUSTOM_CODE));
partyIds.set(new PartyRole(PartyRole.CLEARING_FIRM));=09
=09
sides.addGroup(partyIds);
=09
partyIds.set(new PartyID(bookingRef));
partyIds.set(new
PartyIDSource(PartyIDSource.PROPRIETARY_CUSTOM_CODE));
partyIds.set(new PartyRole(PartyRole.CLIENT_ID));=09
=09
sides.addGroup(partyIds);
sides.set(new OrderQty(unitQty));
=09
message.addGroup(sides);
|
|
From: Brad H. <Bra...@gb...> - 2006-03-19 23:00:54
|
Thanks for that Oren - I thought it should but it wasn't working. Turns out our modifications to quickfix.Session broke the sending of queued messages. So, any suggestions on how to send a BE User Request after a logon but before any queued messages without modifying quickfix.Session are very welcome! -----Original Message----- From: Oren Miller [mailto:or...@qu...]=20 Sent: Friday, 17 March 2006 2:05 AM To: Brad Harvey Cc: qui...@li... Subject: Re: [Quickfix-developers] [qfj] Queueing messages before Logged on? You can send messages at any time. There is no need to wait for a=20 succesful logon. The messages will be queued sent automatically after=20 the next succesfull connection. --oren Brad Harvey wrote: > Hi All, > > I would like to be able to send messages to quickfixj after a session=20 > has been created but while it is not logged on, and then have those=20 > messages sent automatically once the session is logged on. Is this=20 > something that is currently possible?=20 > > Some additional background info may be in order. Our counterparty fix > engine is really just a wrapper for another system, and before we=20 > start sending orders etc we have to login to the other system with a=20 > BE User request. No, I'm not sure why they didn't just add some=20 > custom fields to the normal fix login message.=20 > > We wanted to ensure that no "normal" messages could be sent before the > BE User request. To do this we have modified Session to only consider > itself fully logged on after the BE User request, and to automatically > send the BE after the normal fix logon. Before our application sends=20 > any messages it waits for session.isLoggedOn() to be true. I'm not=20 > really happy with this - I'd prefer it to be able to just send it and=20 > let quickfix take care of sending when it can, hence the original=20 > question. > > I'm also interested in hearing of better ways to do the BE User=20 > request thing - I'd really prefer not to maintain our own changes in=20 > Session. We're quite happy to contribute the changes if they'd be=20 > useful to the quickfixj community, but at the moment it isn't optional > so would require a little work. > > Regards, > Brad. > |
|
From: Steve B. <sb...@sm...> - 2006-03-17 15:31:41
|
Hi Edde, =20 There are many options. You could use a hybrid approach, FIX for the trading messages and a remoting technology like RMI for communicating other information. You could also transmit XML documents using FIX for your portfolio messages. If you are familiar with the Spring Framework, it has a nice object remoting framework with several options for the transport protocol (also see Lingo http://lingo.codehaus.org/ for JMS-based remoting). =20 Steve Bate Smart Trade Technologies Phone: +33 4 42 90 03 97 http://www.smart-trade.net/ ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Edde Sent: Wednesday, March 15, 2006 5:09 PM To: Oren Miller Cc: qui...@li...; Dale Wilson Subject: Re: [Quickfix-developers] Waiting for automatic ResendRequest to finish? =09 =09 Hi Oren, =09 I would really look into writing a simple gateway so your two applications can share the connection.=20 =20 Thanks for everyone's help with this issue! =20 We've now been in contact with our broker and they have agreed to host one of our server which is great news since we can now rewrite our applications to work as a client/server system. The idea is to have our server (which is hosted at the broker firm) to communicate with the market through FIX and then we can have any number of clients connected to the server. I guess this is a fairly common setup for a trading system so I was wondering if anyone on this list have any suggestions on what transfer/communications protocol we should use between the client and the server. I guess you can use FIX here as well but since we need to transmit other data as well ( e.g portfolio information) I'd like to find some other way to communicate. My own idea was to use some XML based protocol like SOAP but my experience in this is limited so I'd gladly appreciate any suggestions from the experts on this list. Our system is 100% Java based and I'd like to keep it this way if possible.=20 =20 Thanks again! /Eddie =20 =20 --oren =09 Edde wrote: =09 > Hi Dale, > > Thanks for the quick reply. > > The reason we've gone through the hassel of resending all the messages=20 > is that we're too people working on our trading system. We work from > two different locations and a couple of times a day we swap who's > doing the actual trading. The current procedure when we swap is that=20 > we simply exchange the seqnums file and then since we do the complete > ResendRequest the one taking over the trading will process the old > messages and reach the current trading "state". > However I realize know that I've been on the wrong path by doing this. > Your first suggestion about reading the messages from the log seems > pretty good to me. Is there a standardized way of doing this? For example:=20 > > 1) I don't really care about heartbeats etc so is there a > specification somewhere which messages are significant when reprocessing? > 2) Are there any utility methods in QuickFIX to reproduce a FIX=20 > message from a String/character stream or similar? > 3) I guess you need to maintain a list of all messages already > processed so that you don't get duplicate processing of one or more > messages?=20 > > Thanks for your help, > /Eddie > > > On 2/20/06, *Dale Wilson* <wil...@oc... > <mailto: wil...@oc... <mailto:wil...@oc...> >> wrote: > > Hi Eddie > > Edde wrote: > > > Since it needed to resend 50000 messages this takes some time and > > while this is in progress our system continues the startup process.=20 > > I'm planning to rewrite this code ASAP but at the moment what we do > > after a major crash on either end is to clear all our databases and > > send a ResendRequest demanding all messages sent in the session:=20 > > The problem is that a ResendRequest is an administrative-level message > and you are attempting to use it for an application-level purpose. > TCP/IP will resend packets on occasion as part of it's error recovery,=20 > but no one attempts to use this information to "replay" a TCP/IP > session. THe same should be true for FIX. Communication stacks work > because the layers are kept distinct --- each one serving it's own=20 > purpose and interactinint with the layers above and below it through a > well specified API. > > Unfortunately in FIX the two layers, admin and app, are not so > clearly > delineated and it tempts developers to cross the line. This > is not the > first time I have seen someone trying to use a ResendRequest for this > purpose. QuickFIX takes care of the administrative layer of the=20 > protocol for you, but if your application sends its own admin layer > messages that QuickFIX doesn't know about, it gets confused (and > rightly > so!) > > You might be able to come up with a hack that works for this=20 > particular > version of QuickFIX, but what ever you come up with there's no > guarantee > that it will work correctly in future versions of QuickFIX. > > That gets us to the question of, "what's the *right* way to fix this=20 > problem.. > > Solution #1: read the day's messages fom the store or from the > log and > reprocess them. . > > Solution #2: define a "retransmit today's transactions" message. You=20 > might define a new custom message type, or consider "twisting" an > application level message for this purpose. (How about using > "wildcard" > order id's in an order status request.? ) You could even define an=20 > "End of retransamint" application level message (or field within a > message). This, of course, assumes you have some influence on the > software at the other end of the connection. Note that "misusing" an=20 > application level message is much less of a sin than subverting an > Admin > message. Among other things it won't confuse QuickFIX. > > Solution #3: Trick QuickFIX into sending the resend request you need=20 > -- reset the expected incoming sequence number to 1 without > chaning the > next sequence number to send. Do this before loggin in so only one > "resed" will happen. > > > Dale > > -- > ----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ > ---------------------------------------------------- > > =09 |
|
From: Steve B. <sb...@sm...> - 2006-03-17 15:28:42
|
J=F6rg, I've searched the SF mailing list archives for the threads you referenced a and I didn't find them. Can you post a link to one=20 of the messages in each thread? Thanks, Steve Bate Smart Trade Technologies Phone: +33 4 42 90 03 97 http://www.smart-trade.net/ =20 > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Joerg Thoennes > Sent: Thursday, March 16, 2006 10:41 PM > To: Oren Miller > Cc: Graham Miller; qui...@li... > Subject: Re: [Quickfix-developers] [qfj] double and not BigDecimal? >=20 > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > Oren Miller wrote: > > QuickFIX Documentation:=20 > > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html > >=20 > > Did QuickFIX actually return this value to you or did you do some=20 > > calculations on it before seeing this price? >=20 > As a side note: >=20 > This issue has already been discussed a while ago; see the=20 > message threads: >=20 > * QF java interface: conversion from double fields to=20 > BigDecimal give imprecise results > * price as double >=20 > For Java, a good default would be to use BigDecimal, but for=20 > C++ you would need a BCD lib. > So using the underlying string directly is the safest way at=20 > the moment. >=20 > Cheers, J=F6rg >=20 > -- > Joerg Thoennes > http://macd.com > Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH > Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking=20 > scripting language > that extends applications into web and mobile media. Attend=20 > the live webcast > and join the prime developer group breaking into this new=20 > coding territory! > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers >=20 |
|
From: Joerg T. <Joe...@ma...> - 2006-03-16 21:41:33
|
Oren Miller wrote: > QuickFIX Documentation:=20 > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > Did QuickFIX actually return this value to you or did you do some=20 > calculations on it before seeing this price? As a side note: This issue has already been discussed a while ago; see the message thread= s: * QF java interface: conversion from double fields to BigDecimal give imp= recise results * price as double For Java, a good default would be to use BigDecimal, but for C++ you woul= d need a BCD lib. So using the underlying string directly is the safest way at the moment. Cheers, J=F6rg --=20 Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
|
From: Oren M. <or...@qu...> - 2006-03-16 21:21:13
|
Did QuickFIX actually return this value to you or did you do some calculations on it before seeing this price? --oren Graham Miller wrote: > Why was the decision made to use doubles instead of BigDecimals when > representing decimal data like prices? (I guess maybe this was > something inherited from the old Java wrapper, but then the same can > be asked about the Javfa wrapper). It seems like the BigDecimal exact > representations would suit the application better, as dealing with > rounding problems associated with doubles can be a pain. Of course > arithmetic expressions are more straightforward using doubles in Java, > but you can always get around that by converting to doubles before > doing any calculations. Sitting here next to a stock ticker, I just > saw that Ford is down .07000000000001 cents today. That's what I'm > talking about. Thoughts? > > graham > |
|
From: Joerg T. <Joe...@ma...> - 2006-03-16 21:09:10
|
Hi both,
> For QFJ, doubles were used for QF JNI compatibility.
Maybe there is a nice C++ BCD arithmetic lib...
> In a future version of QFJ I'd be open to the possibility of using BigD=
ecimals, but I'd
> want to do some performance analysis first.
Steve, IMHO there no need for performance analysis. You cannot trade corr=
ectness for=20
performance. Maybe we find a way to provide both methods, though.
Recently, I read an article about floating point and Java, but this is a =
issue with=20
floating point numbers in general: They are not precise. The article in i=
s in German, so I=20
cannot post it here.
Therefore, one of the first rules I learnt in the area of financial math =
was: *Never* use=20
floating point, but use fixed point or BCD arithmetic instead.
> IIRC, all the commercial Java FIX engines I've used also represented
> price-like data as doubles.
> Of course, that doesn't make it right. ;-)
Indeed.
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of
> Graham Miller
> Sent: Thursday, March 16, 2006 9:12 PM
> To: qui...@li...
> Subject: [Quickfix-developers] [qfj] double and not BigDecimal?
> =09
> =09
> =09
> Why was the decision made to use doubles instead of BigDecimals
> when representing decimal data like prices? (I guess maybe this was
> something inherited from the old Java wrapper, but then the same can be
> asked about the Javfa wrapper). It seems like the BigDecimal exact
> representations would suit the application better, as dealing with
> rounding problems associated with doubles can be a pain.
Indeed.
> Of course arithmetic expressions are more straightforward using doubles=
in Java, but
> you can always get around that by converting to doubles before doing an=
y calculations.
In this way, you re-introduce all the hassles you wanted to avoid by usin=
g BigDecimal.
> Sitting here next to a stock ticker, I just saw that Ford is down .0700=
0000000001 cents
> today. That's what I'm talking about. Thoughts?
I know that kind of numbers ;-)
My first solution was:
new BigDecimal( fixData.getPrice().getValue() ) ).setScale( 6, BigDecimal=
.ROUND_HALF_DOWN );
but much better is to access the String value directly:
new BigDecimal( fixData.getString( Price.FIELD ) );
This completely skips the conversion to double and back to BigDecimal. So=
a possible=20
solution for both QF and QF/J would be to return all floats as String, le=
aving it to the=20
user to do the appropriate conversion.
Or we could introduce the notion of a ConverterFactory(), which could be =
configured in the=20
same way as the MessageFactory(). QF would then use:
converterFactory.getPriceConverter().convert( message.getString( tag ) )=
;
These factories and the used types could be tied to the message generatio=
n codes somehow.
Just some thoughts..
Cheers, J=F6rg
--=20
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Steve B. <sb...@sm...> - 2006-03-16 20:42:28
|
Hi Graham, =20 For QFJ, doubles were used for QF JNI compatibility. In a future version of QFJ I'd be open to the possibility of using BigDecimals, but I'd want to do some performance analysis first. =20 IIRC, all the commercial Java FIX engines I've used also represented price-like data as doubles. Of course, that doesn't make it right. ;-) =20 Regards, =20 Steve =09 ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Graham Miller Sent: Thursday, March 16, 2006 9:12 PM To: qui...@li... Subject: [Quickfix-developers] [qfj] double and not BigDecimal? =09 =09 =09 Why was the decision made to use doubles instead of BigDecimals when representing decimal data like prices? (I guess maybe this was something inherited from the old Java wrapper, but then the same can be asked about the Javfa wrapper). It seems like the BigDecimal exact representations would suit the application better, as dealing with rounding problems associated with doubles can be a pain. Of course arithmetic expressions are more straightforward using doubles in Java, but you can always get around that by converting to doubles before doing any calculations. Sitting here next to a stock ticker, I just saw that Ford is down .07000000000001 cents today. That's what I'm talking about. Thoughts?=20 =09 graham =09 =09 ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Graham Miller Sent: Thursday, March 16, 2006 9:12 PM To: qui...@li... Subject: [Quickfix-developers] [qfj] double and not BigDecimal? =09 =09 Why was the decision made to use doubles instead of BigDecimals when representing decimal data like prices? (I guess maybe this was something inherited from the old Java wrapper, but then the same can be asked about the Javfa wrapper). It seems like the BigDecimal exact representations would suit the application better, as dealing with rounding problems associated with doubles can be a pain. Of course arithmetic expressions are more straightforward using doubles in Java, but you can always get around that by converting to doubles before doing any calculations. Sitting here next to a stock ticker, I just saw that Ford is down .07000000000001 cents today. That's what I'm talking about. Thoughts?=20 =09 graham =09 =09 |
|
From: Graham M. <gra...@gm...> - 2006-03-16 20:12:28
|
Why was the decision made to use doubles instead of BigDecimals when representing decimal data like prices? (I guess maybe this was something inherited from the old Java wrapper, but then the same can be asked about the Javfa wrapper). It seems like the BigDecimal exact representations woul= d suit the application better, as dealing with rounding problems associated with doubles can be a pain. Of course arithmetic expressions are more straightforward using doubles in Java, but you can always get around that b= y converting to doubles before doing any calculations. Sitting here next to = a stock ticker, I just saw that Ford is down .07000000000001 cents today. That's what I'm talking about. Thoughts? graham |
|
From: Oren M. <or...@qu...> - 2006-03-16 17:06:11
|
All these are documented in the FIX protocol spec. You can get it from www.fixprotocol.org --oren Martin Tanguay wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > In which section of the doc can I find the full Session and Sequence > number mecanism explanation? > > I still have use cases regarding that section and I would like to > clearly understand the whole process. > > There is some things like, why quickfix keep incrementing sequence > number by one when the gap between client and server is like 10000 for > instance. Why it does not synchronise instead of incrementing? Which > seqnum number is for incoming and outgoing? And some other not clear > scenarios. > > If you could point me to some doc, it would be great. > > Thanks you ! > Marty > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > |
|
From: Martin T. <mta...@ho...> - 2006-03-16 16:56:11
|
Hi, In which section of the doc can I find the full Session and Sequence number mecanism explanation? I still have use cases regarding that section and I would like to clearly understand the whole process. There is some things like, why quickfix keep incrementing sequence number by one when the gap between client and server is like 10000 for instance. Why it does not synchronise instead of incrementing? Which seqnum number is for incoming and outgoing? And some other not clear scenarios. If you could point me to some doc, it would be great. Thanks you ! Marty |
|
From: Oren M. <or...@qu...> - 2006-03-16 16:04:49
|
You can send messages at any time. There is no need to wait for a succesful logon. The messages will be queued sent automatically after the next succesfull connection. --oren Brad Harvey wrote: > Hi All, > > I would like to be able to send messages to quickfixj after a session > has been created but while it is not logged on, and then have those > messages sent automatically once the session is logged on. Is this > something that is currently possible? > > Some additional background info may be in order. Our counterparty fix > engine is really just a wrapper for another system, and before we > start sending orders etc we have to login to the other system with a > BE User request. No, I'm not sure why they didn't just add some > custom fields to the normal fix login message. > > We wanted to ensure that no "normal" messages could be sent before the > BE User request. To do this we have modified Session to only consider > itself fully logged on after the BE User request, and to automatically > send the BE after the normal fix logon. Before our application sends > any messages it waits for session.isLoggedOn() to be true. I'm not > really happy with this - I'd prefer it to be able to just send it and > let quickfix take care of sending when it can, hence the original > question. > > I'm also interested in hearing of better ways to do the BE User > request thing - I'd really prefer not to maintain our own changes in > Session. We're quite happy to contribute the changes if they'd be > useful to the quickfixj community, but at the moment it isn't optional > so would require a little work. > > Regards, > Brad. > |
|
From: Brad H. <Bra...@gb...> - 2006-03-15 23:14:38
|
Hi All, I would like to be able to send messages to quickfixj after a session has been created but while it is not logged on, and then have those messages sent automatically once the session is logged on. Is this something that is currently possible? =20 Some additional background info may be in order. Our counterparty fix engine is really just a wrapper for another system, and before we start sending orders etc we have to login to the other system with a BE User request. No, I'm not sure why they didn't just add some custom fields to the normal fix login message. =20 We wanted to ensure that no "normal" messages could be sent before the BE User request. To do this we have modified Session to only consider itself fully logged on after the BE User request, and to automatically send the BE after the normal fix logon. Before our application sends any messages it waits for session.isLoggedOn() to be true. I'm not really happy with this - I'd prefer it to be able to just send it and let quickfix take care of sending when it can, hence the original question. I'm also interested in hearing of better ways to do the BE User request thing - I'd really prefer not to maintain our own changes in Session. We're quite happy to contribute the changes if they'd be useful to the quickfixj community, but at the moment it isn't optional so would require a little work. Regards, Brad. |
|
From: Edde <edd...@gm...> - 2006-03-15 16:08:53
|
Hi Oren, > > I would really look into writing a simple gateway so your two > applications can share the connection. Thanks for everyone's help with this issue! We've now been in contact with our broker and they have agreed to host one of our server which is great news since we can now rewrite our applications to work as a client/server system. The idea is to have our server (which is hosted at the broker firm) to communicate with the market through FIX and then we can have any number of clients connected to the server. I guess this is a fairly common setup for = a trading system so I was wondering if anyone on this list have any suggestions on what transfer/communications protocol we should use between the client and the server. I guess you can use FIX here as well but since w= e need to transmit other data as well (e.g portfolio information) I'd like to find some other way to communicate. My own idea was to use some XML based protocol like SOAP but my experience in this is limited so I'd gladly appreciate any suggestions from the experts on this list. Our system is 100= % Java based and I'd like to keep it this way if possible. Thanks again! /Eddie --oren > > Edde wrote: > > > Hi Dale, > > > > Thanks for the quick reply. > > > > The reason we've gone through the hassel of resending all the messages > > is that we're too people working on our trading system. We work from > > two different locations and a couple of times a day we swap who's > > doing the actual trading. The current procedure when we swap is that > > we simply exchange the seqnums file and then since we do the complete > > ResendRequest the one taking over the trading will process the old > > messages and reach the current trading "state". > > However I realize know that I've been on the wrong path by doing this. > > Your first suggestion about reading the messages from the log seems > > pretty good to me. Is there a standardized way of doing this? For > example: > > > > 1) I don't really care about heartbeats etc so is there a > > specification somewhere which messages are significant when > reprocessing? > > 2) Are there any utility methods in QuickFIX to reproduce a FIX > > message from a String/character stream or similar? > > 3) I guess you need to maintain a list of all messages already > > processed so that you don't get duplicate processing of one or more > > messages? > > > > Thanks for your help, > > /Eddie > > > > > > On 2/20/06, *Dale Wilson* <wil...@oc... > > <mailto:wil...@oc...>> wrote: > > > > Hi Eddie > > > > Edde wrote: > > > > > Since it needed to resend 50000 messages this takes some time and > > > while this is in progress our system continues the startup > process. > > > I'm planning to rewrite this code ASAP but at the moment what we > do > > > after a major crash on either end is to clear all our databases > and > > > send a ResendRequest demanding all messages sent in the session: > > > > The problem is that a ResendRequest is an administrative-level > message > > and you are attempting to use it for an application-level purpose. > > TCP/IP will resend packets on occasion as part of it's error > recovery, > > but no one attempts to use this information to "replay" a TCP/IP > > session. THe same should be true for FIX. Communication stacks > work > > because the layers are kept distinct --- each one serving it's own > > purpose and interactinint with the layers above and below it throug= h > a > > well specified API. > > > > Unfortunately in FIX the two layers, admin and app, are not so > > clearly > > delineated and it tempts developers to cross the line. This > > is not the > > first time I have seen someone trying to use a ResendRequest for > this > > purpose. QuickFIX takes care of the administrative layer of the > > protocol for you, but if your application sends its own admin layer > > messages that QuickFIX doesn't know about, it gets confused (and > > rightly > > so!) > > > > You might be able to come up with a hack that works for this > > particular > > version of QuickFIX, but what ever you come up with there's no > > guarantee > > that it will work correctly in future versions of QuickFIX. > > > > That gets us to the question of, "what's the *right* way to fix thi= s > > problem.. > > > > Solution #1: read the day's messages fom the store or from the > > log and > > reprocess them. . > > > > Solution #2: define a "retransmit today's transactions" > message. You > > might define a new custom message type, or consider "twisting" an > > application level message for this purpose. (How about using > > "wildcard" > > order id's in an order status request.? ) You could even define a= n > > "End of retransamint" application level message (or field within a > > message). This, of course, assumes you have some influence on the > > software at the other end of the connection. Note that "misusing" > an > > application level message is much less of a sin than subverting an > > Admin > > message. Among other things it won't confuse QuickFIX. > > > > Solution #3: Trick QuickFIX into sending the resend request you > need > > -- reset the expected incoming sequence number to 1 without > > chaning the > > next sequence number to send. Do this before loggin in so only one > > "resed" will happen. > > > > > > Dale > > > > -- > > ----------------------------------------------------- > > Dale Wilson, Senior Software Engineer > > Object Computing, Inc. (OCI) > > http://www.ociweb.com/ http://www.theaceorb.com/ > > ---------------------------------------------------- > > > > > |
|
From: Emil V. <que...@ho...> - 2006-03-15 11:51:42
|
Hi guys, we're having interesting problem with the party we connect to not responding properly to Logon request, having ResetSeqNumFlag==Y. They don't include it in their logon response, so QuickFIX 1.11.0 treats their response as request, and eventually the parties can't connect. Wondering if you could suggest me some workarround as we could do it with the older QuickFix by manually setting the ResetSeqNumFlag==Y and it wouldn't threat the response as request. Thanks, Emil _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
|
From: Oren M. <or...@qu...> - 2006-03-15 07:27:26
|
Thank you very much for providing unit tests. This patch has been added to CVS. --oren Yihu Fang wrote: > Jonathan, > > From the example you provided, I did a unit test and indeed it looks > like that the isSameSession() does not pass the test. > >>> My session start time is 10:00 (5 am est) > >>> My session end time is 02:00:00 (9 pm est) > >>> Day one, my session starts at 5:00:14. Next day, the session starts > up at 5:00:11.. > > // start time is greater than end time > > start = UtcTimeOnly( 10, 0, 0 ); > > end = UtcTimeOnly( 2, 0, 0 ); > > // same session time 1 is in next day > > time1 = UtcTimeStamp( 10, 0, 11, 9, 3, 2006 ); > > time2 = UtcTimeStamp( 10, 0, 14, 8, 3, 2006 ); > > assert( !SessionTime::isSameSession( start, end, time1, time2 ) ); > > As you noticed that when the startTime is ahead of endTime (next day), > the following simple check in method isSameSession() is not valid > > return labs( time1 - time2 ) < DateTime::SECONDS_PER_DAY; > > Because the current time2 (creation time) could be at any where within > the session window between start and end. A simple compare of current > time (time1) and creation time (time2) is not enough. A bit more check > to ensure that the (time1 – time2) is within the session window is needed. > > Attached please find the patch of SessionTime.cpp. I also provide some > more unit test cases in SessionTimeTestCase.cpp. The patch seems to > solve the problem and it also passes all the unit tests. > > Thanks, > > -Yihu > > > > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be the > views of Reuters Ltd. > >------------------------------------------------------------------------ > >--- SessionTime.cpp 2006-03-09 22:08:49.060525200 -0500 >+++ SessionTime.cpp.new 2006-03-09 21:58:45.598807200 -0500 >@@ -112,7 +112,21 @@ > if( start < end || start == end ) > return time1Date == time2Date; > else if( start > end ) >- return labs( time1 - time2 ) < DateTime::SECONDS_PER_DAY; >+ { >+ UtcTimeOnly time2TimeOnly = UtcTimeOnly(time2); >+ long delta = time2TimeOnly - start; >+ if (delta < 0) >+ delta = DateTime::SECONDS_PER_DAY + delta; >+ >+ int sessionLength = DateTime::SECONDS_PER_DAY - (start - end); >+ bool result; >+ if (time1 > time2) >+ result = (time1 - time2) < (sessionLength - delta); >+ else >+ result = (time2 - time1) < sessionLength; >+ return result; >+ // return labs( time1 - time2 ) < DateTime::SECONDS_PER_DAY; >+ } > return false; > > QF_STACK_POP > > >------------------------------------------------------------------------ > >--- SessionTimeTestCase.cpp 2006-03-09 22:15:01.300718300 -0500 >+++ SessionTimeTestCase.cpp.new 2006-03-09 21:58:11.680373100 -0500 >@@ -190,6 +190,31 @@ > time2 = UtcTimeStamp( 19, 06, 0, 1, 14, 2004 ); > assert( !SessionTime::isSameSession( start, end, time1, time2 ) ); > assert( !SessionTime::isSameSession( start, end, time2, time1 ) ); >+ >+ // start time is greater than end time >+ start = UtcTimeOnly( 10, 0, 0 ); >+ end = UtcTimeOnly( 2, 0, 0 ); >+ >+ // same session time 1 is in next day >+ time1 = UtcTimeStamp( 10, 0, 11, 9, 3, 2006 ); >+ time2 = UtcTimeStamp( 10, 0, 14, 8, 3, 2006 ); >+ assert( !SessionTime::isSameSession( start, end, time1, time2 ) ); >+ >+ // same session time 1 is in next day >+ start = UtcTimeOnly( 16, 0, 0 ); >+ end = UtcTimeOnly( 15, 0, 0 ); >+ >+ time1 = UtcTimeStamp( 14, 0, 0, 9, 3, 2006 ); >+ time2 = UtcTimeStamp( 1, 0, 0, 9, 3, 2006 ); >+ assert (SessionTime::isSameSession( start, end, time1, time2 ) ); // yes >+ time2 = UtcTimeStamp( 23, 0, 0, 8, 3, 2006 ); >+ assert( SessionTime::isSameSession( start, end, time1, time2 ) ); // yes >+ >+ time1 = UtcTimeStamp( 17, 0, 0, 9, 3, 2006 ); >+ time2 = UtcTimeStamp( 1, 0, 0, 9, 3, 2006 ); >+ assert( !SessionTime::isSameSession( start, end, time1, time2 ) ); // no >+ time2 = UtcTimeStamp( 23, 0, 0, 8, 3, 2006 ); >+ assert( !SessionTime::isSameSession( start, end, time1, time2 ) ); // no > } > > void SessionTimeTestCase::isSameSessionWithDay::onRun( SessionTime& object ) > > |
|
From: Oren M. <or...@qu...> - 2006-03-14 17:55:58
|
Yes, however this only works if the socket is able to establish a connection. If not, no logon will be sent. --oren Dale Wilson wrote: > If you want to go to the effort, you could even add code to toAdmin to > count the number of Logon messages. Reset the count if you ever get > a onLogon callback. > > Dale > > Oren Miller wrote: > >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> No, but you can keep track of how much time has elapsed and query >> isLoggedOn to see if the connection is succesfull. If you want you >> can read in the recconnectInterval settings and multiply it by the >> number of connections you are interested in. i.e., if the interval >> is set to 10 seconds and you want 5 attempts, (10 * 5) - 10 = 40 >> seconds. >> >> --oren >> >> On Mar 14, 2006, at 8:26 AM, Nick Volpe wrote: >> >>> >>> Thanks for the swift reply. Will the engine try and start >>> indefinitely, or is there another configuration option to specify >>> the number of attempts? If not, can I somehow query the number of >>> attempts so that I can stop trying and exit if the engine hasn't >>> connected to the acceptor after a specific number of attempts? >>> >>> Regards. >>> Nik >>> >>> >>> >>> > |
98 messages has been excluded from this view by a project administrator.
