quickfix-developers Mailing List for QuickFIX (Page 285)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joerg T. <Joe...@ma...> - 2003-04-07 15:31:14
|
Mike Hepburn wrote:
> i haven't seen your posting's - but sure no problem, library attached.
Hi Mike,
Thanks a lot. My 1.4.0 version had some problems with missing throw specifier, so I
went back to 1.3.2 but in this version I had problems with libpthread. I think the
linkage to libpthread was wrong and therefore signal were misdirected and aborted the
program.
Since I use Debian 3.0 (stable), the necessary libs to use your library were not available.
So I used another machine with the newer 'testing' package pool and upgrade the needed
libs. On loading the library, I got strange linkage errors with version mismatches so I
stopped here.
> what problems were you having building quickfix ? we couldn't get all of
> the tests to build on gcc-3.2, but didn't spend much time on them as the
> main quickfix library built OK.
Currently I use gcc-3.0. The 1.4.0 has problems with some missing throw specifier.
For some reasons currently the anonymous CVS access to sourceforge does not work, so that
I could not get the fixes. Now I try it with CVS browsing.
Cheers, Joerg
--
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: Vamsi K. <Vam...@ib...> - 2003-04-07 14:09:29
|
HI I was trying to poll on external source ( pre-composed FIX messages residing either in Database or MQSeries or some proprietory command messages which start or start FIXClient component). Can somebody tell me how? I was trying to use onRun function. It seems that it will get invoked only once. Thanks in advance Vamsi |
|
From: Gene G. <mus...@ya...> - 2003-04-04 19:29:56
|
I have FIX:Session that has messages send to it from multiple threads. I have discovered (the hard way) that under certain conditions Session::send crashes. It happens when simultaneously there is a Session::disconnect called from another thread, for example when FIX session counterpart closes socket. Session::disconnect deletes m_Responder, if that happens after Session::send checks for m_Responder for presence, but before it is finished using it, crash ensues. The fix is to guard Session::disconnect with the same mutex that guards Session::sendRaw. I have attached patch that does just that. Gene __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com |
|
From: Mike H. <mi...@an...> - 2003-04-04 07:03:52
|
Hi Joerg, i haven't seen your posting's - but sure no problem, library attached. what problems were you having building quickfix ? we couldn't get all of the tests to build on gcc-3.2, but didn't spend much time on them as the main quickfix library built OK. Cheers Mike PS: I didn't post the library to the group list as its 1.8 M and the jar is 1.2 M On Thu, 2003-04-03 at 17:44, Joerg Thoennes wrote: > Hi Mike, > > > i'm using quickfix 1.4.0 on linux (gcc-3.2) java-1.4 > > Sorry to bother you, but I have currently problems to get QF running on Linux and JDK 1.4.1_01. > (See also my posting in the newsgroup.) > > Could you tell me about your configuration and perhaps send me you libquickfix_jni.so? > > That would be of a great help for me since I have to prototype some Java/QuickFIX application. > > Thanks and cheers, > > Joerg > > -- > Joerg Thoennes > http://macd.com > Tel.: +49 -- ___________________________________________________________________ Mike Hepburn Phone: +44 (0)207 749 7900 Anvil Software Limited Fax: +44 (0)207 749 7916 51-53 Rivington Street E-mail: mi...@an... London EC2A 3SE ef...@ho... |
|
From: Mike H. <mi...@an...> - 2003-04-04 06:55:34
|
Thanks Oren, i'll give these a go. Cheers Mike On Thu, 2003-04-03 at 19:24, OM...@th... wrote: >=20 > You will need these revisions: >=20 > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quickfix/quickfix/src/java= /src/org/quickfix/MessageCracker.java.diff?r1=3D1.1&r2=3D1.2 > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quickfix/quickfix/src/java= /src/org/quickfix/fix43/MessageCracker.java.diff?r1=3D1.2&r2=3D1.3 >=20 > That should do it. >=20 > --oren >=20 >=20 >=20 > |---------+-----------------------------------------------> > | | Mike Hepburn <mi...@an...> | > | | Sent by: | > | | qui...@li...ur| > | | ceforge.net | > | | | > | | | > | | 04/03/2003 10:19 AM | > | | | > |---------+-----------------------------------------------> > >----------------------------------------------------------------------= ------------------------| > | = | > | To: quickfix <qui...@li...> = | > | cc: = | > | Subject: [Quickfix-developers] Java FIX4.3 message cracking = | > >----------------------------------------------------------------------= ------------------------| >=20 >=20 >=20 >=20 > Hi, >=20 > i'm using quickfix 1.4.0 on linux (gcc-3.2) java-1.4 >=20 > is there java support for cracking FIX4.3 messages ?? when i crack such > a message i get an Unsupported Message Type exception every time. i > noticed in the java source that the java MessageCracker only supports > fix42: >=20 > public class MessageCracker extends org.quickfix.fix42.MessageCracker > {... >=20 >=20 > Do I need a later revision ?? >=20 > Regards > Mike >=20 > (See attached file: signature.asc) >=20 >=20 --=20 ___________________________________________________________________ Mike Hepburn Phone: +44 (0)207 749 7900 Anvil Software Limited Fax: +44 (0)207 749 7916 51-53 Rivington Street E-mail: mi...@an... London EC2A 3SE ef...@ho... |
|
From: <OM...@th...> - 2003-04-03 18:34:46
|
This has been applied to the repository. Thanks. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quickfix/quickfix/src/C%2b%2b/FieldTypes.h.diff?r1=1.3&r2=1.4 --oren |---------+-----------------------------------------------> | | Chris Patmore | | | <Chr...@BT...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 04/03/2003 10:31 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: developers QuickFIX <qui...@li...> | | cc: | | Subject: [Quickfix-developers] UtcDate initialisation bug | >----------------------------------------------------------------------------------------------| FieldTypes.h (v 1.3) has UtcDate( int date, int month, int year ) : UtcTimeStamp( date, month, year ) { clearTime(); } but this will pick up the wrong constructor for the UtcTimeStamp class UtcTimeStamp : protected tm { ... /// Defaults to the current date UtcTimeStamp( int hour, int minute, int second ) { ... } so I assume it should be UtcDate( int date, int month, int year ) : UtcTimeStamp( 0, 0, 0, date, month, year ) { clearTime(); } Regards Chris Patmore **************************************************************************** This message is confidential to the sender and addressee, and may contain proprietary or legally privileged information. If you are not the intended recipient, please delete it from your system, destroy any copies, and notify the sender immediately. Opinions stated herein are not necessarily those of BrokerTec. BrokerTec reserves the right to monitor messages that pass through it's networks. BrokerTec Europe Ltd is regulated by FSA. ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Gene G. <mus...@ya...> - 2003-04-03 18:26:31
|
1) Acceptor leaks thread in which onRun is running. The code uses incorrect function (the one returning boolean, not threadid) to spawn the onRun thread, and uses resulting "1" instead of correct thread id to join. The consequenses are that accptor->stop (called after onRun) continues running after acceptor.start returns and is acceptor instance gets deleted, which often results in crashes in my server. 2) After fixing above, a race condition in ThreadedSocketAcceptor is apparent. onStop thread iterates over the collection of open connection threads trying to join them. This loop is protected by mutex. However the connection threads themselves attempt to erase themself from the same collection, and deadlock on the same mutex. The fix is to treat shutdown as the special case and when a m_stop flag is set, skip per-thread cleanup. m_stop has to be protected by a separate mutex. My patch uses a class MtVar(.h) (tested internally on all platforms) which allows to change only the declaration: bool m_stop to MtVar<bool> m_stop and have exact same semantics elsewhere, only in a thread-safe way. Four files are attached (in a zip): patches for Acceptor.cpp, ThreadedSocketAccpeptor.cpp and .h and MtVar.h Gene __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com |
|
From: <OM...@th...> - 2003-04-03 18:24:22
|
You will need these revisions: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quickfix/quickfix/src/java/src/org/quickfix/MessageCracker.java.diff?r1=1.1&r2=1.2 http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quickfix/quickfix/src/java/src/org/quickfix/fix43/MessageCracker.java.diff?r1=1.2&r2=1.3 That should do it. --oren |---------+-----------------------------------------------> | | Mike Hepburn <mi...@an...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 04/03/2003 10:19 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: quickfix <qui...@li...> | | cc: | | Subject: [Quickfix-developers] Java FIX4.3 message cracking | >----------------------------------------------------------------------------------------------| Hi, i'm using quickfix 1.4.0 on linux (gcc-3.2) java-1.4 is there java support for cracking FIX4.3 messages ?? when i crack such a message i get an Unsupported Message Type exception every time. i noticed in the java source that the java MessageCracker only supports fix42: public class MessageCracker extends org.quickfix.fix42.MessageCracker {... Do I need a later revision ?? Regards Mike (See attached file: signature.asc) |
|
From: Chris P. <Chr...@BT...> - 2003-04-03 16:31:57
|
FieldTypes.h (v 1.3) has
UtcDate( int date, int month, int year )
: UtcTimeStamp( date, month, year )
{
clearTime();
}
but this will pick up the wrong constructor for the UtcTimeStamp
class UtcTimeStamp : protected tm
{
...
/// Defaults to the current date
UtcTimeStamp( int hour, int minute, int second )
{
...
}
so I assume it should be
UtcDate( int date, int month, int year )
: UtcTimeStamp( 0, 0, 0, date, month, year )
{
clearTime();
}
Regards
Chris Patmore
****************************************************************************
This message is confidential to the sender and addressee, and may contain
proprietary or legally privileged information. If you are not the intended
recipient, please delete it from your system, destroy any copies, and notify
the sender immediately. Opinions stated herein are not necessarily those of
BrokerTec. BrokerTec reserves the right to monitor messages that pass
through it's networks. BrokerTec Europe Ltd is regulated by FSA.
|
|
From: Mike H. <mi...@an...> - 2003-04-03 16:19:48
|
Hi,
i'm using quickfix 1.4.0 on linux (gcc-3.2) java-1.4
is there java support for cracking FIX4.3 messages ?? when i crack such
a message i get an Unsupported Message Type exception every time. i
noticed in the java source that the java MessageCracker only supports
fix42:
public class MessageCracker extends org.quickfix.fix42.MessageCracker
{...
Do I need a later revision ??
Regards
Mike
|
|
From: Joerg T. <Joe...@ma...> - 2003-04-03 11:47:10
|
Hi Barry,
> No, invalid argument as pbind tells you.
>
>> bash-2.03$ /usr/sbin/psrinfo
>> 1 on-line since 07/19/02 18:35:00
>> 2 on-line since 07/19/02 18:35:02
>
>
> From this output, you see that you have processors 1 and 2 (see first
> column).
>
>> bash-2.03$ /usr/sbin/pbind -b 0 3761
>> /usr/sbin/pbind: cannot bind pid 3761: Invalid argument
>
>
> But you try to bind to processor 0 (-b 0) which simply does not exist --
> therefore the invalid argument.
Please, can you confirm whether this works now?
Does it fix your problem?
> Actually, we used this approach to hotfix a threading problem under
> heavy load on a
> multiprocessor machine while development took place on a single
> processor one.
> But later we discovered, that we had used C library functions which are
> not thread save.
> After we fixed this, we could drop the pbind.
>
> For all non-thread save functions, there are thread-safe (re-entrant)
> variants suffixed
> by "_r". In our case, gethostbyname() was one of the culprits. We
> replaced it by
> gethostbyname_r(), which lead to a somewhat more complex call syntax.
Perhaps you have been experiencing exactly this kind of situation. It would be
good to have a stack trace of core dump:
$ pstack core
In the stack trace we could see at which place the error occured. For more such
nice utilities see "man proc", "man truss", "man gcore", "man coreadm".
In addition, beginning with Solaris 2.8 there are two thread libraries:
1. Old T1 lib in /lib/libthread.so implements complex N:M mappings of N user threads
to M<<N kernel threads callend LWPs( Light Weight Processes ). Due to the complexity
there are many issues in the bug database.
2. New T2 lib in /lib/lwp/libthread.so. This simply maps every user thread to an LWP.
This is much simpler and new kernels can handle lots of LWPs. Therefore, this is the
default in Solaris 9.
Prepend /usr/lib/lwp to your LD_LIBRARY_PATH to activate it:
export LD_LIBRARY_PATH=/usr/lib/lwp:$LD_LIBRARY_PATH
or
setenv LD_LIBRARY_PATH /usr/lib/lwp:$LD_LIBRARY_PATH
In our experience, if you mix Java application and JNI/native libs which create threads
on their own, this is always a good choice to avoid threading problem by buggy libs.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Joerg T. <Joe...@ma...> - 2003-04-03 11:35:00
|
Hi Barry,
this is an easy one...
> The only problem is that I don't seem able to execute pbind properly against
> any process that I own. Insufficient rights I am guessing. For example:
No, invalid argument as pbind tells you.
> bash-2.03$ /usr/sbin/psrinfo
> 1 on-line since 07/19/02 18:35:00
> 2 on-line since 07/19/02 18:35:02
From this output, you see that you have processors 1 and 2 (see first column).
> bash-2.03$ /usr/sbin/pbind -b 0 3761
> /usr/sbin/pbind: cannot bind pid 3761: Invalid argument
But you try to bind to processor 0 (-b 0) which simply does not exist --
therefore the invalid argument.
I am sorry for the rather sketchy explanation in my last mail. I thought that it was
obvious to use psrinfo to look the available processor number (at my Sun: 0, but at
your Sun: 1 and 2) and I also thought that there is always a processor 0.
Nevertheless, feel free to ask further questions.
Actually, we used this approach to hotfix a threading problem under heavy load on a
multiprocessor machine while development took place on a single processor one.
But later we discovered, that we had used C library functions which are not thread save.
After we fixed this, we could drop the pbind.
For all non-thread save functions, there are thread-safe (re-entrant) variants suffixed
by "_r". In our case, gethostbyname() was one of the culprits. We replaced it by
gethostbyname_r(), which lead to a somewhat more complex call syntax.
Oren, perhaps QF uses some non-thread safe functions (e.g. gethostbyname()). In my
experience, this can work for a long time, but if you switch to a real fast MP machine
(for production), the program starts to dump core.
On my machine, I looked in the following way for all "_r" suffixed functions:
joerg@polaris:/usr/lib $ nm -A -g -n lib*.so | egrep '_r$' | grep -v UNDEF
libXm.so: [6411] | 1542716| 252|FUNC |GLOB |0 |12 |XmFontListCreate_r
libXm.so: [7899] | 1542040| 256|FUNC |GLOB |0 |12 |XmFontListEntryCreate_r
libXm.so: [8495] | 1542980| 12|FUNC |GLOB |0 |12 |XmStringCreateFontList_r
libXm.so: [6958] | 483476| 96|FUNC |GLOB |0 |12 |_XmReCacheLabG_r
libbsm.so: [865] | 30892| 408|FUNC |GLOB |0 |9 |getauclassent_r
libbsm.so: [586] | 31364| 76|FUNC |GLOB |0 |9 |getauclassnam_r
libbsm.so: [587] | 36924| 424|FUNC |GLOB |0 |9 |getauevent_r
libbsm.so: [727] | 37412| 92|FUNC |GLOB |0 |9 |getauevnam_r
libbsm.so: [814] | 37504| 88|FUNC |GLOB |0 |9 |getauevnum_r
libbsm.so: [826] | 54888| 424|FUNC |GLOB |0 |9 |getauuserent_r
libbsm.so: [583] | 55368| 168|FUNC |GLOB |0 |9 |getauusernam_r
libc.so: [2699] | 227336| 332|FUNC |GLOB |0 |9 |__posix_asctime_r
libc.so: [3019] | 227852| 68|FUNC |GLOB |0 |9 |__posix_ctime_r
libc.so: [3752] | 608620| 100|FUNC |GLOB |0 |9 |__posix_getgrgid_r
libc.so: [4553] | 608856| 92|FUNC |GLOB |0 |9 |__posix_getgrnam_r
libc.so: [4510] | 240376| 120|FUNC |GLOB |0 |9 |__posix_getlogin_r
libc.so: [3910] | 611572| 100|FUNC |GLOB |0 |9 |__posix_getpwnam_r
libc.so: [3028] | 611336| 100|FUNC |GLOB |0 |9 |__posix_getpwuid_r
libc.so: [3346] | 615168| 200|FUNC |GLOB |0 |9 |__posix_readdir_r
libc.so: [3199] | 349788| 148|FUNC |GLOB |0 |9 |__posix_ttyname_r
libc.so: [4378] | 227668| 48|FUNC |GLOB |0 |9 |_asctime_r
libc.so: [3478] | 615368| 48|FUNC |GLOB |0 |9 |_ctermid_r
libc.so: [4082] | 227780| 72|FUNC |GLOB |0 |9 |_ctime_r
libc.so: [3184] | 609252| 124|FUNC |GLOB |0 |9 |_fgetgrent_r
libc.so: [3038] | 611976| 124|FUNC |GLOB |0 |9 |_fgetpwent_r
libc.so: [3294] | 613520| 124|FUNC |GLOB |0 |9 |_fgetspent_r
libc.so: [3835] | 609044| 208|FUNC |GLOB |0 |9 |_getgrent_r
libc.so: [3797] | 607960| 256|FUNC |GLOB |0 |9 |_getgrgid_r
libc.so: [4619] | 607628| 332|FUNC |GLOB |0 |9 |_getgrnam_r
libc.so: [3589] | 240080| 296|FUNC |GLOB |0 |9 |_getlogin_r
libc.so: [4636] | 611768| 208|FUNC |GLOB |0 |9 |_getpwent_r
libc.so: [3228] | 610772| 244|FUNC |GLOB |0 |9 |_getpwnam_r
libc.so: [4694] | 611016| 184|FUNC |GLOB |0 |9 |_getpwuid_r
libc.so: [3016] | 613312| 208|FUNC |GLOB |0 |9 |_getspent_r
libc.so: [3807] | 613080| 136|FUNC |GLOB |0 |9 |_getspnam_r
libc.so: [3116] | 336028| 72|FUNC |GLOB |0 |9 |_gmtime_r
libc.so: [3720] | 335940| 68|FUNC |GLOB |0 |9 |_localtime_r
libc.so: [3929] | 614524| 92|FUNC |GLOB |0 |9 |_rand_r
libc.so: [3110] | 614616| 348|FUNC |GLOB |0 |9 |_readdir64_r
libc.so: [3092] | 614964| 204|FUNC |GLOB |0 |9 |_readdir_r
libc.so: [4684] | 324656| 128|FUNC |GLOB |0 |9 |_strtok_r
libc.so: [3166] | 616336| 176|FUNC |GLOB |0 |9 |_tmpnam_r
libc.so: [4325] | 349056| 732|FUNC |GLOB |0 |9 |_ttyname_r
libc.so: [3870] | 608484| 136|FUNC |GLOB |0 |9 |_uncached_getgrgid_r
libc.so: [4153] | 608720| 136|FUNC |GLOB |0 |9 |_uncached_getgrnam_r
libc.so: [4681] | 611436| 136|FUNC |GLOB |0 |9 |_uncached_getpwnam_r
libc.so: [4479] | 611200| 136|FUNC |GLOB |0 |9 |_uncached_getpwuid_r
libc.so: [3587] | 227668| 48|FUNC |WEAK |0 |9 |asctime_r
libc.so: [3559] | 615368| 48|FUNC |WEAK |0 |9 |ctermid_r
libc.so: [2899] | 227780| 72|FUNC |WEAK |0 |9 |ctime_r
libc.so: [4579] | 609252| 124|FUNC |WEAK |0 |9 |fgetgrent_r
libc.so: [3187] | 611976| 124|FUNC |WEAK |0 |9 |fgetpwent_r
libc.so: [3755] | 613520| 124|FUNC |WEAK |0 |9 |fgetspent_r
libc.so: [3185] | 609044| 208|FUNC |WEAK |0 |9 |getgrent_r
libc.so: [2760] | 607960| 256|FUNC |WEAK |0 |9 |getgrgid_r
libc.so: [3782] | 607628| 332|FUNC |WEAK |0 |9 |getgrnam_r
libc.so: [4251] | 240080| 296|FUNC |WEAK |0 |9 |getlogin_r
libc.so: [3271] | 243412| 184|FUNC |GLOB |0 |9 |getnetgrent_r
libc.so: [3520] | 611768| 208|FUNC |WEAK |0 |9 |getpwent_r
libc.so: [4097] | 610772| 244|FUNC |WEAK |0 |9 |getpwnam_r
libc.so: [3320] | 611016| 184|FUNC |WEAK |0 |9 |getpwuid_r
libc.so: [3851] | 613312| 208|FUNC |WEAK |0 |9 |getspent_r
libc.so: [4436] | 613080| 136|FUNC |WEAK |0 |9 |getspnam_r
libc.so: [3362] | 336028| 72|FUNC |WEAK |0 |9 |gmtime_r
libc.so: [3898] | 335940| 68|FUNC |WEAK |0 |9 |localtime_r
libc.so: [3182] | 614524| 92|FUNC |WEAK |0 |9 |rand_r
libc.so: [3279] | 614616| 348|FUNC |WEAK |0 |9 |readdir64_r
libc.so: [3418] | 614964| 204|FUNC |WEAK |0 |9 |readdir_r
libc.so: [3288] | 324656| 128|FUNC |WEAK |0 |9 |strtok_r
libc.so: [4516] | 616336| 176|FUNC |WEAK |0 |9 |tmpnam_r
libc.so: [3538] | 349056| 732|FUNC |WEAK |0 |9 |ttyname_r
libm.so: [594] | 18020| 16|FUNC |GLOB |0 |9 |__gamma_r
libm.so: [612] | 28796| 16|FUNC |GLOB |0 |9 |__lgamma_r
libm.so: [658] | 18020| 16|FUNC |WEAK |0 |9 |gamma_r
libm.so: [632] | 28796| 16|FUNC |WEAK |0 |9 |lgamma_r
libnsl.so: [3766] | 435368| 52|FUNC |GLOB |0 |9 |__nis_map_group_r
libnsl.so: [3773] | 234608| 160|FUNC |GLOB |0 |9 |_switch_gethostbyaddr_r
libnsl.so: [3501] | 119800| 148|FUNC |GLOB |0 |9 |_switch_gethostbyname_r
libnsl.so: [3929] | 234768| 160|FUNC |GLOB |0 |9 |_switch_getipnodebyaddr_r
libnsl.so: [3543] | 234460| 148|FUNC |GLOB |0 |9 |_switch_getipnodebyname_r
libnsl.so: [3646] | 216360| 48|FUNC |GLOB |0 |9 |_uncached_gethostbyaddr_r
libnsl.so: [4061] | 216348| 12|FUNC |GLOB |0 |9 |_uncached_gethostbyname_r
libnsl.so: [4253] | 216612| 200|FUNC |GLOB |0 |9 |gethostbyaddr_r
libnsl.so: [3714] | 216408| 204|FUNC |GLOB |0 |9 |gethostbyname_r
libnsl.so: [4141] | 218508| 144|FUNC |GLOB |0 |9 |gethostent_r
libnsl.so: [4225] | 228912| 148|FUNC |GLOB |0 |9 |getrpcbyname_r
libnsl.so: [3561] | 229060| 148|FUNC |GLOB |0 |9 |getrpcbynumber_r
libnsl.so: [4424] | 229328| 132|FUNC |GLOB |0 |9 |getrpcent_r
libnsl.so: [3817] | 114092| 76|FUNC |GLOB |0 |9 |inet_ntoa_r
libnsl.so: [3526] | 415004| 96|FUNC |GLOB |0 |9 |nis_leaf_of_r
libnsl.so: [4178] | 430712| 176|FUNC |GLOB |0 |9 |nis_sperror_r
libsocket.so: [273] | 20944| 152|FUNC |GLOB |0 |9 |getnetbyaddr_r
libsocket.so: [261] | 20796| 148|FUNC |GLOB |0 |9 |getnetbyname_r
libsocket.so: [343] | 21220| 132|FUNC |GLOB |0 |9 |getnetent_r
libsocket.so: [307] | 22304| 148|FUNC |GLOB |0 |9 |getprotobyname_r
libsocket.so: [234] | 22452| 148|FUNC |GLOB |0 |9 |getprotobynumber_r
libsocket.so: [463] | 22716| 132|FUNC |GLOB |0 |9 |getprotoent_r
libsocket.so: [458] | 23488| 156|FUNC |GLOB |0 |9 |getservbyname_r
libsocket.so: [464] | 23644| 160|FUNC |GLOB |0 |9 |getservbyport_r
libsocket.so: [378] | 24268| 136|FUNC |GLOB |0 |9 |getservent_r
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Joerg T. <Joe...@ma...> - 2003-04-03 10:50:23
|
OM...@th... wrote:
> It appears under windows they are not thread safe.
> [....]
> This looks like an important fix so it should probably go out with 1.4.1,
> initially using locking for windows.
May I provide some sample code from our software:
For gethostbyname_r(() there are difference between Linux and Solaris:
102 /* Get the IP address of the localhost.
103 * Note: This thread-safe version needs some extra data structures.
104 */
105 {
106 struct hostent host;
107 struct hostent *host_ptr = NULL;
108 char gethostname_buffer[ 1024 ];
109 int error;
110
111 #ifdef SYSTEM_linux
112 gethostbyname_r( "localhost", &host, gethostname_buffer, sizeof( gethostname_buffer ), &host_ptr, &error );
113 #endif
114 #ifdef SYSTEM_sunos
115 host_ptr = gethostbyname_r( "localhost", &host, gethostname_buffer, sizeof( gethostname_buffer ), &error );
116 #endif
117
118 if ( NULL == host_ptr ) {
119 logError( "openSocketQueue: Could not resolve 'localhost'" );
120 return -1;
121 }
122
123 memcpy( &sin.sin_addr, host_ptr->h_addr_list[0], sizeof( sin.sin_addr ) );
124 }
localtime() and gmtime() are simple, since you only have to provide an extra buffer instead
of using the returned value. Note that there man pages may be missing on Linux. But you could use
http://docs.sun.com to look up the Solaris man pages, which are equivalent here:
SYNOPSIS
#include <time.h>
[...deleted...]
struct tm *localtime_r(const time_t *clock, struct tm *res);
struct tm *gmtime_r(const time_t *clock, struct tm *res);
DESCRIPTION
[...]
The localtime_r() and gmtime_r() functions have the same
functionality as localtime() and gmtime() respectively,
except that the caller must supply a buffer res to store the
result.
[...]
ERRORS
The ctime_r() and asctime_r() functions will fail if:
ERANGE
The length of the buffer supplied by the caller is not
large enough to store the result.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Joerg T. <Joe...@ma...> - 2003-04-03 10:20:48
|
Hi,
after the call to the onRun() method, my application stops with a SIGABORT signal
(no core dump). The last words according to strace are:
gettimeofday({1049364332, 949497}, NULL) = 0
gettimeofday({1049364332, 949592}, NULL) = 0
write(5, "[Thu Apr 03 12:05:32.949 CEST 2003] [INFO ] [FixSession] open: opening session.."..., 82[Thu Apr 03 12:05:32.949 CEST 2003] [INFO ] [FixSession] open: opening session...
) = 82
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
write(4, "\240\320\2@\0\0\0\0\0\0\0\0\334kbL\230_\'\10\0\0\0\200\0\0\0\0\330\306\377\277\220^(\10\27\0\0\0\302l\\L\370(U@0(\5\10\360\306\377\277-\200\\L\304(\5\10"..., 148) = 148
[Thu Apr 03 12:05:32.951 CEST 2003] [INFO ] [FixApplication] onRun: started
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([] <unfinished ...>
--- SIGRTMIN (Real-time signal 0) ---
<... rt_sigsuspend resumed> ) = -1 EINTR (Interrupted system call)
sigreturn() = ? (mask now [RTMIN])
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
kill(32338, SIGABRT) = 0
--- SIGABRT (Aborted) ---
+++ killed by SIGABRT +++
Previously, the onCreate() and onRun() callbacks of the Application have been successfully
called.
My program uses a SocketAcceptor.
QF version is 1.3.2 (1.4.0 still has some compilation problems, so I decided to wait for 1.4.1.)
Compiler:
gcc-3.0 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.4/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.0.4
Libc version: libc6 Version: 2.2.5-6
Kernel version: 2.2.19
Linux distribution: Debian 3.0
Did anybody here run QF with Java on Linux successfully? I may provide further information if
needed.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Joerg T. <Joe...@ma...> - 2003-04-03 10:09:34
|
Hi,
it would be nice to have the following in the configuration file:
DataDictionary=${FIX_SPEC_DIR}/FIX42.xml
while ${name} syntax refers to an environment variable FIX_SPEC_DIR. This make the
Configuration files more flexible.
In the operator>>() method of Settings:
79 case ConfigLexer::LC_STATE_VALUE:
80 std::string value = lexer.YYText();
81 std::string::size_type pos = value.find_last_not_of( ' ' );
82 if ( pos == std::string::npos ) continue;
83 value.resize( pos + 1 );
84 ( *currentSection ).setString( currentName, value );
85 break;
after line 80 there could be a function expandEnvironmentVariable to interpolate
the references.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: <OM...@th...> - 2003-04-03 09:26:13
|
It appears under windows they are not thread safe. From MSDN: "gmtime, mktime, and localtime all use a single statically allocated tm= structure for the conversion. Each call to one of these routines destro= ys the result of the previous call." In fact it seems that if I am reading that correctly, all three methods= share the same static structure. I'd prefer not to lock (long term) because this is a frequently called method, and would add some unwanted contention. What might have to be = done in the future is to start using the Win32 API equivalents instead. This looks like an important fix so it should probably go out with 1.4.= 1, initially using locking for windows. --oren |---------+-----------------------------------------------> | | Joerg Thoennes | | | <Joe...@ma...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 04/03/2003 02:47 AM | | | Please respond to Joerg.Thoennes | | | | |---------+-----------------------------------------------> >--------------------------------------------------------------------= --------------------------| | = | | To: developers QuickFIX <qui...@li...ur= ceforge.net> | | cc: = | | Subject: [Quickfix-developers] Usage of non-threadsafe C fun= ctions in QF | >--------------------------------------------------------------------= --------------------------| Hi, inspired by Barry Bishops core dumps on a fast multiprocessor Solaris machine, I just checked if QF used functions which have re-entrant equivalents on Solaris or Li= nux (suffixed by _r). Here is what I found: ./include/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= sec ); ./include/FieldTypes.h: *static_cast < tm* > ( this ) =3D *localtime= ( &time ); ./include/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= t ); ./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= sec ); ./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) =3D *localtime= ( &time ); ./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) =3D *gmtime( &= t ); ./src/C++/Utility.cpp: buf =3D gethostbyname( name ); ./src/C++/Utility.cpp: return inet_ntoa( **paddr ); The last function probably does not count, since the man page states th= at the returned buffer is in a thread local data space (and the _r variant is not mentioned in= the man pages). BUT: The other function can really account for some core dumps. Actuall= y we used all these function in our software until some release consistently core dumped on= our fast multiprocessor production machine. As a quick fix we used the pbind command to assign = only one processor to the process. Analysis of the core file revealed the culprits listed abo= ve. After replacing the usage of gmtime(), localtime() and gethostbyname() by their _r variants= , core dumping stopped and all went fine since then. Oren, I have no way to check whether the functions on Windows are threa= d safe by default. But I would suggest to put these functions also into Utility.cpp and perhaps protect the Windows variants by a mutex if they are unsafe. If you need an example for the UNIX implementation, I could extract one out of our code. Cheers, J=F6rg -- 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 ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers = |
|
From: <OM...@th...> - 2003-04-03 08:59:31
|
Yes, a patch would be great. --oren |---------+-----------------------------------------------> | | Joerg Thoennes | | | <Joe...@ma...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 04/03/2003 02:09 AM | | | Please respond to Joerg.Thoennes | | | | |---------+-----------------------------------------------> >--------------------------------------------------------------------= --------------------------| | = | | To: developers QuickFIX <qui...@li...ur= ceforge.net> | | cc: = | | Subject: [Quickfix-developers] SocketAcceptor listens on all= local interfaces, should | | be configurable = | >--------------------------------------------------------------------= --------------------------| Hi, looking at documentation for the configuration of the Acceptor, I see t= hat only the listen port can be configured. The source reveals that the SocketAccept= or listens on all local interfaces (line 116): 108 SocketServer::SocketServer( int port, int timeout ) 109 : m_port( port ), m_monitor( timeout ) 110 { 111 m_socket =3D socket( PF_INET, SOCK_STREAM, 0 ); 112 if ( m_socket < 0 ) throw std::exception(); 113 114 m_address.sin_family =3D PF_INET; 115 m_address.sin_port =3D htons( port ); 116 m_address.sin_addr.s_addr =3D INADDR_ANY; 117 m_socklen =3D sizeof( m_address ); 118 119 socket_setsockopt( m_socket ); 120 if ( !bind() ) throw std::exception(); 121 if ( !listen() ) throw std::exception(); 122 m_monitor.add( m_socket ); 123 } The backlog is currently configured to the maximum value. This could be= also configurable. Since we work with virtual interface in the production environment, it would be important if we could specify a distinct host/IP address to listen on. The defaul= t could remain e.g. "*" which could mean INADDR_ANY. Oren, shall I provide a patch to implement this? Cheers, J=F6rg -- 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 ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers = |
|
From: Joerg T. <Joe...@ma...> - 2003-04-03 08:48:30
|
Hi,
inspired by Barry Bishops core dumps on a fast multiprocessor Solaris machine, I just checked
if QF used functions which have re-entrant equivalents on Solaris or Linux (suffixed by _r).
Here is what I found:
./include/FieldTypes.h: *static_cast < tm* > ( this ) = *gmtime( &sec );
./include/FieldTypes.h: *static_cast < tm* > ( this ) = *localtime( &time );
./include/FieldTypes.h: *static_cast < tm* > ( this ) = *gmtime( &t );
./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) = *gmtime( &sec );
./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) = *localtime( &time );
./src/C++/FieldTypes.h: *static_cast < tm* > ( this ) = *gmtime( &t );
./src/C++/Utility.cpp: buf = gethostbyname( name );
./src/C++/Utility.cpp: return inet_ntoa( **paddr );
The last function probably does not count, since the man page states that the returned buffer
is in a thread local data space (and the _r variant is not mentioned in the man pages).
BUT: The other function can really account for some core dumps. Actually we used all these
function in our software until some release consistently core dumped on our fast multiprocessor
production machine. As a quick fix we used the pbind command to assign only one processor to
the process. Analysis of the core file revealed the culprits listed above. After replacing the
usage of gmtime(), localtime() and gethostbyname() by their _r variants, core dumping stopped
and all went fine since then.
Oren, I have no way to check whether the functions on Windows are thread safe by default. But I
would suggest to put these functions also into Utility.cpp and perhaps protect the Windows variants
by a mutex if they are unsafe. If you need an example for the UNIX implementation, I could extract
one out of our code.
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Joerg T. <Joe...@ma...> - 2003-04-03 08:10:11
|
Hi,
looking at documentation for the configuration of the Acceptor, I see that only the
listen port can be configured. The source reveals that the SocketAcceptor listens
on all local interfaces (line 116):
108 SocketServer::SocketServer( int port, int timeout )
109 : m_port( port ), m_monitor( timeout )
110 {
111 m_socket = socket( PF_INET, SOCK_STREAM, 0 );
112 if ( m_socket < 0 ) throw std::exception();
113
114 m_address.sin_family = PF_INET;
115 m_address.sin_port = htons( port );
116 m_address.sin_addr.s_addr = INADDR_ANY;
117 m_socklen = sizeof( m_address );
118
119 socket_setsockopt( m_socket );
120 if ( !bind() ) throw std::exception();
121 if ( !listen() ) throw std::exception();
122 m_monitor.add( m_socket );
123 }
The backlog is currently configured to the maximum value. This could be also configurable.
Since we work with virtual interface in the production environment, it would be important
if we could specify a distinct host/IP address to listen on. The default could remain e.g.
"*" which could mean INADDR_ANY.
Oren, shall I provide a patch to implement this?
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: David M. <dav...@ds...> - 2003-04-03 00:23:31
|
Hi All, It is now 01:20 and I just got banzai and all to work! I am tickled pink= =2E =20 Turned out that it was the compiler (sheepish grin as Oren kept on saying= =20 that!). I used gcc-3.2.2 and had to download the latest snapshot out of = CVS=20 due to all kinds of compile errors. I am using RedHat 7.3. This time, since I had JAVA_HOME defined, all I had to do was to type=20 configure and voila! Thanks so much for all the comments and help. Cheers David |
|
From: Oren M. <ore...@ya...> - 2003-04-02 16:47:18
|
Are you building the VS7 after building VS6? Doint so leaves latent files around which will cause linker errors. If you want to have botha VS6 and VS7 version, I suggest you keep two codebases in two directories so they don't conflict. You can see archived builds by going to the http://quickfix.thoughtworks.com/cchtml directory and picking a build file. They are all labeled with the date and build number. To do what you want to do, I would suggest you get the latest from CVS. Issues were recently addressed to make it possible for an application to act as both an initiator and an acceptor. Pay attention to the threading model and the fact that start() is a blocking call. Peter Krause <kra...@ho...> wrote: Hi! (a) I downloaded the QF source code a while ago, converted the VS6 files to VS 7 files, and had no end of problems (death by a thousand cuts). Just downloaded a fresh copy, and everything seems to be working beautifully in VS6, but when I try to run the quickfix.sln file, I gets tons of errors (mostly LNK 2005, most of which vanish when I link in static rather than a dll version of mfc, but there are a few stubborn ones LNK2020s, particularly relating to cout and basic_stream that I can't root out). Is the answer just to stick with VS6? (b) And what do the errors maean in QuickFIX build result page in the thoughtworks.com web site mean? As I understand it, they relate to the current build in the sourcesafe: is there a page where I can see the build that is archived? (c) My project is to have an administrative thread that gets orders via FIX, and then parcells them out to various ECNs & exchanges (i.e., if the order is to buy a thousand, and there are 500 on two ecns, it would split it up & fill). Following Murphy's law, what should I expect to go wrong? Peter _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more |
|
From: Peter K. <kra...@ho...> - 2003-04-02 16:30:05
|
Hi! (a) I downloaded the QF source code a while ago, converted the VS6 files to VS 7 files, and had no end of problems (death by a thousand cuts). Just downloaded a fresh copy, and everything seems to be working beautifully in VS6, but when I try to run the quickfix.sln file, I gets tons of errors (mostly LNK 2005, most of which vanish when I link in static rather than a dll version of mfc, but there are a few stubborn ones LNK2020s, particularly relating to cout and basic_stream that I can't root out). Is the answer just to stick with VS6? (b) And what do the errors maean in QuickFIX build result page in the thoughtworks.com web site mean? As I understand it, they relate to the current build in the sourcesafe: is there a page where I can see the build that is archived? (c) My project is to have an administrative thread that gets orders via FIX, and then parcells them out to various ECNs & exchanges (i.e., if the order is to buy a thousand, and there are 500 on two ecns, it would split it up & fill). Following Murphy's law, what should I expect to go wrong? Peter _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail |
|
From: Alexandre H. <a....@ca...> - 2003-04-02 09:27:33
|
Hello,
Many thanks for the ideas.=20
What I have done is to create my own message factory, which uses the
"DefaultMessageFactory".
My "create" method (see code below) takes as parameters :=20
- the begin string ("FIX.4.2"),=20
- the message type ("D")=20
- and the full FIX String:
"8=3DFIX.4.2=019=3D136=0135=3DD=0134=3D16=0149=3DLeTrader02=0152=3D20030=
402-08:09:11=0156=3DLeBroker02
=0111=3DTrader_OrderID_1=0121=3D1=0138=3D1280=0140=3D1=0154=3D1=0155=3Dt=
f1=0159=3D0=0160=3D20030402-08:09:11
=0110=3D104=01"
The message I get can then be cast into =
(org.quickfix.fix42.NewOrderSingle).
The only problem is that the "create" method doesn't handle Quote =
Requests
(because of repeating groups).
Is there a "setString" method that takes a full FIX String and returns =
an
object of class "org.quickfix.Message" that
can be cast to "org.quickfix.fix42.QuoteRequest" for example ?
Alternately, I think I should write a second "create" method that =
handles
repeating groups.
Thanks,
Alexandre
******
public Message create(String beginString, String msgType,String str)
{
=09
Message message =3D new Message() ;
try { =09
MessageFactory messageFactory =3D new
DefaultMessageFactory();
message =3D messageFactory.create(beginString,
msgType);
=09
StringTokenizer st =3D new StringTokenizer(str, "\1");
while(st.hasMoreTokens()) {
String tag=3Dst.nextToken();
StringTokenizer st2 =3D new
StringTokenizer(tag, "=3D");=20
int tagID =3D
Integer.parseInt(st2.nextToken());
String tagValue =3D st2.nextToken();
=09
if ((tagID !=3D35) && (tagID !=3D8) && (tagID
!=3D10) && (tagID !=3D9)) {
message.setString(tagID,tagValue);
}
}
} =09
catch(Exception e ) {
e.printStackTrace();
}
return message;=09
}=09
******
-----Message d'origine-----
De : OM...@th... [mailto:OM...@th...]
Envoy=E9 : mercredi 2 avril 2003 01:49
=C0 : Alexandre Hoang
Cc : Olivier Bonheur; 'qui...@li...';
qui...@li...
Objet : Re: [Quickfix-developers] Casting from "Message" to
"org.quickfix.fix42.QuoteRequest"
There is a couple of ways to do this, depending on how much type safety =
you
want. If you want to conitinue using the base Message class, you just =
need
to start using the non-type safe getField method instead of get. If =
you
want to be able to get a class that represents the message type, you =
can
use the DefaultMessageFactory class to create the derived message =
class.
You need to pass in a valid beginstring and a msgtype.
To do this it might be worthwhile to put the values of just those two
fields in separate columns in your database. Then you can pull them =
out,
pass them into the factory, and call setString using your stored =
string.
Then you will be able to cast the resulting message to the appropriate
type.
--oren
--------------------------------------------------------
=20
>-----------------------------------------------------------------------=
----
-------------------|
|
|
| To: "'qui...@li...'"
|
| <qui...@li...>
|
| cc: Olivier Bonheur <o.b...@ca...>
|
| Subject: [Quickfix-developers] Casting from "Message" to
|
| "org.quickfix.fix42.QuoteRequest"
|
=20
>-----------------------------------------------------------------------=
----
-------------------|
Hello,
I archive the FIX messages I receive through QuickFIX in an SQL Server
database.
Basically, if I receive a quote request, encapsulated in an object of =
class
"QuoteRequest", I do:
"aQuoteRequest.toString()" and I put the string in the database.
Now I want to retrieve from my database the quote request. So I first =
use a
query to get the string I have just stored.
Then a can create a Message: Message aMessage =3D new
Message(stringRetrievedFromDB);
But then, I cannot do the following:
Symbol aSymbol =3D new Symbol();
aMessage.get(aSymbol); // does not work !
I actually need to cast to the "Message" to
"org.quickfix.fix42.QuoteRequest".
But this is not possible: I get a class cast exception.
Is there a way to do this casting ?
Or is there a better way to archive messages ? I have thought of =
archiving
the tags one by one, but doing with makes it more difficult to =
reconstruct
an object of class "Message".
Thanks for any idea,
Alexandre
--------------------------------------------------------
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * =
* *=20
Confidentiality Notice :=20
The information contained in this e-mail message is intended only for =
the
personal and confidential use of the recipient(s) named above. If the =
reader
of this message is not the intended recipient or an agent responsible =
for
delivering it to the intended recipient, you are hereby notified that =
you
have received this document in error and that any review, =
dissemination,
distribution, or copying of this message is strictly prohibited. If you =
have
received this communication in error, please notify =
pos...@ca...
immediately by e-mail, and delete the original message.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * =
* *=20
|
|
From: <OM...@th...> - 2003-04-01 23:57:37
|
Well, QuickFIX will ignore any message that is considered "mangled". This could mean they have an incorrect message length or checksum. Is this a possibility with these messages? --oren |---------+-----------------------------------------------> | | Nicholas Palmer | | | <nic...@sl...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 03/31/2003 06:31 PM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: "'qui...@li...'" | | <qui...@li...> | | cc: | | Subject: [Quickfix-developers] Droping messages... | >----------------------------------------------------------------------------------------------| -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey All, I am having some trouble with a QuickFIX application I am developing. Unfortunately it requires that I interface with a vendor who uses a bastardized version of FIX. I have created a special XML file for validation of these messages, and two out of the three I have to handle get received and cracked properly. The third doesn't seem to get into the application at all. I have overridden both fromAdmin and fromApp and put logging statements in both. For the other messages I see the log message in fromAdmin, and then fromApp, however for this message I see the log of the message being received that looks like: <20030401-00:11:05, FIX.4.2:US->THEM, incoming> (field=data*field=data*etc...) but neither the fromAdmin or fromApp methods get called, and no other message is logged (such as rejecting due to missing or invalid fields which I have seen when I had the XML messed up, so I don't think that is the problem, but I guess it is possible. I have been over the XML with a fine toothed comb though so I doubt it.) The application then goes into an infinite loop where QuickFIX claims that the next message had a sequence number that was too high and re requests the message that it just dropped, which it drops again. Lather rinse repeat until the processor explodes. The message that I receive contains fields out of order, and fields which print with fieldnum=NOREF, so I suspect it is a problem handling the crappy message from the other vendor, but since QuickFIX receives it they claim that it is my problem to fix. I have set: ValidateFieldsOutOfOrder=N ValidateFieldsHaveValues=N in the config file with no change in behavior. Any thoughts on a cure for this problem. Thanks, - -Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+iN3hR42/Somtp0QRArTAAJwLsxraN8FpGlAnH3AJsJP/wl9UoQCggqIV IzUOnThR+n1roiPuSAgmBvE= |
|
From: <OM...@th...> - 2003-04-01 23:49:18
|
There is a couple of ways to do this, depending on how much type safety= you want. If you want to conitinue using the base Message class, you just = need to start using the non-type safe getField method instead of get. If yo= u want to be able to get a class that represents the message type, you ca= n use the DefaultMessageFactory class to create the derived message class= . You need to pass in a valid beginstring and a msgtype. To do this it might be worthwhile to put the values of just those two fields in separate columns in your database. Then you can pull them ou= t, pass them into the factory, and call setString using your stored string= . Then you will be able to cast the resulting message to the appropriate type. --oren |---------+-----------------------------------------------> | | Alexandre Hoang | | | <a....@ca...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 04/01/2003 09:33 AM | | | | |---------+-----------------------------------------------> >--------------------------------------------------------------------= --------------------------| | = | | To: "'qui...@li...'" = | | <qui...@li...> = | | cc: Olivier Bonheur <o.b...@ca...> = | | Subject: [Quickfix-developers] Casting from "Message" to = | | "org.quickfix.fix42.QuoteRequest" = | >--------------------------------------------------------------------= --------------------------| Hello, I archive the FIX messages I receive through QuickFIX in an SQL Server database. Basically, if I receive a quote request, encapsulated in an object of c= lass "QuoteRequest", I do: "aQuoteRequest.toString()" and I put the string in the database. Now I want to retrieve from my database the quote request. So I first u= se a query to get the string I have just stored. Then a can create a Message: Message aMessage =3D new Message(stringRetrievedFromDB); But then, I cannot do the following: Symbol aSymbol =3D new Symbol(); aMessage.get(aSymbol); // does not work ! I actually need to cast to the "Message" to "org.quickfix.fix42.QuoteRequest". But this is not possible: I get a class cast exception. Is there a way to do this casting ? Or is there a better way to archive messages ? I have thought of archiv= ing the tags one by one, but doing with makes it more difficult to reconstr= uct an object of class "Message". Thanks for any idea, Alexandre -----Message d'origine----- De : qui...@li... [mailto:qui...@li...] Envoy=E9 : vendredi 28 mars 2003 21:35 =C0 : qui...@li... Objet : Quickfix-developers digest, Vol 1 #193 - 5 msgs Send Quickfix-developers mailing list submissions to qui...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/quickfix-developers or, via email, send a message with subject or body 'help' to qui...@li... You can reach the person managing the list at qui...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Quickfix-developers digest..." Today's Topics: 1. COM Error when trying to initialize acceptor (Jacob Steyn) 2. RE: COM Error when trying to initialize acceptor (Jacob Steyn) 3. Re: COM Error when trying to initialize acceptor (Vitor Castro) 4. SessionNotFound Exception sending messages in Java (David Monheit= ) 5. Message storage and retrieval (David Monheit) --__--__-- Message: 1 Date: Fri, 28 Mar 2003 10:58:53 +0200 From: "Jacob Steyn" <ja...@pe...> To: <qui...@li...> Subject: [Quickfix-developers] COM Error when trying to initialize acce= ptor HI All I get this error when in C# I try to start the socketacceptor. An unhandled exception of type 'QuickFix.ConfigError' occurred in =3D quickfix_net_debug.dll Additional information: Could not initialize COM Any Ideas? Thanks Jac --__--__-- Message: 2 Subject: RE: [Quickfix-developers] COM Error when trying to initialize acceptor Date: Fri, 28 Mar 2003 12:23:24 +0200 From: "Jacob Steyn" <ja...@pe...> To: "Vitor Castro" <vc...@hi...>, <qui...@li...> Hi Vitor Thanks. Im not trying to expose them. Using the default quickfix_net_debug.dll in 1.4.0 and just referencing it in my .net solution which doesnt register in COM. -----Original Message----- From: Vitor Castro [mailto:vc...@hi...] Sent: 28 March 2003 11:27 To: Jacob Steyn; qui...@li... Subject: RE: [Quickfix-developers] COM Error when trying to initialize acceptor Hi Jac, Are you trying to expose the objects in quickfix_net_debug.dll as COM objects? If not check to see if your quickfix .net project isn't by mistake enabling the registration of the dll as a COM server. -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Jacob Steyn Sent: sexta-feira, 28 de Mar=3DE7o de 2003 8:59 To: qui...@li... Subject: [Quickfix-developers] COM Error when trying to initialize acceptor HI All I get this error when in C# I try to start the socketacceptor. An unhandled exception of type 'QuickFix.ConfigError' occurred in quickfix_net_debug.dll Additional information: Could not initialize COM= Any Ideas? Thanks Jac ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --__--__-- Message: 3 From: "Vitor Castro" <vc...@hi...> Cc: <qui...@li...> Subject: Re: [Quickfix-developers] COM Error when trying to initialize acceptor Date: Fri, 28 Mar 2003 10:18:20 -0000 Organization: HiperBit Hi Jac, Are you trying to expose the objects in quickfix_net_debug.dll as COM objects? If not check to see if your quickfix .net project isn't by mistake enabling the registration of the dll as a COM server. -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Jacob Steyn Sent: sexta-feira, 28 de Mar=3DE7o de 2003 8:59 To: qui...@li... Subject: [Quickfix-developers] COM Error when trying to initialize acceptor HI All I get this error when in C# I try to start the socketacceptor. An unhandled exception of type 'QuickFix.ConfigError' occurred in quickfix_net_debug.dll Additional information: Could not initialize COM= Any Ideas? Thanks Jac ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --__--__-- Message: 4 Date: Fri, 28 Mar 2003 14:47:47 +0000 From: David Monheit <Dav...@mo...> Reply-To: Dav...@mo... Organization: Morgan Stanley To: qui...@li... Subject: [Quickfix-developers] SessionNotFound Exception sending messag= es in Java Hi all, Coming along in QF. I saw some old threads which experienced this exac= t problem, ie, QF for Java has some problem finding the right session. Here is the scoop: There are 3 overrides to Session.sendToTarget a) sendToTarget(Message) b) sendToTarget(Message, SessionID) c) sendToTarget(Message, SenderCompID (string), SenderTargetID (string)= ) It turns out that no matter what I tried with c, I ALWAYS got SessionNotFound!!! I also noticed that if I set the following in the cfg file: SenderCompID=3DOrderEngine TargetCompID=3Dmonheit I got back a sessionID of "FIX.4.0:OrderEngine->monheit" on the C++ program, ie, executor. When I ran my order entry program in Java with = a cfg of: SenderCompID=3Dmonheit TargetCompID=3DOrderEngine the sessionID was "FIX.4.0: monheit->OrderEngine" !!! Note the space i= n there!!!! The way I got it to work is by using override b, and sending the SessionID which I got on the order... I did not try method a yet. Need to have a look at why this is. Regards David --__--__-- Message: 5 Date: Fri, 28 Mar 2003 15:06:53 +0000 From: David Monheit <Dav...@mo...> Reply-To: Dav...@mo... Organization: Morgan Stanley To: Quickfix <qui...@li...> Subject: [Quickfix-developers] Message storage and retrieval Hi Starting the debate of earlier threads again... IMHO a client app could either try to keep the state of the world (SOW)= itself of delegate it to something else which then uses different methods for dispersing this info. A client app could go to a db to get= known orders and status on startup, connect to a pub/sub system and request the current SOW or whatever. A server, however, specially something like an order manager must keep track of its orders EVEN through a core !!! As Oren mentioned in some earlier thread, this presents a problem. Server which handle large order flow will have a huge FIX traffic whose latency needs to be kept to a minimum. Writing orders to a db or whatever is basically out of the quesion because of the IO time involved. Since QF does have the logs stored if the file system one would imagine that re-loading the order server to the state prior to a core is just a matter of replaying= the messages and rebuiding the order collection. This however, is a server problem, not a qf problem. I would vote for writing a small library for reading and even better, replaying these messages. For instance we could create a MessageReplayApplication whic= h subclasses Application. This classes' thread would read the inbound lo= g file and invoke fromApp callbacks. Any messages sent by this app would= be ignored!!!! This would allow a server to rebuild its state. When done, the main class deletes this playback object and start the real one.... Just a thought anyways. The point is that for some apps we DO need to have not just message recovery but state recovery as well... David -- NOTICE: If received in error, please destroy and notify sender. Sender= does not waive confidentiality or privilege, and use is prohibited. --__--__-- _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers End of Quickfix-developers Digest * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *= * * Confidentiality Notice : The information contained in this e-mail message is intended only for t= he personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible f= or delivering it to the intended recipient, you are hereby notified that y= ou have received this document in error and that any review, dissemination= , distribution, or copying of this message is strictly prohibited. If you= have received this communication in error, please notify postmaster@cadextan= .fr immediately by e-mail, and delete the original message. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *= * * ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers = |
98 messages has been excluded from this view by a project administrator.
