quickfix-developers Mailing List for QuickFIX (Page 300)
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: <OM...@th...> - 2002-10-29 23:29:49
|
>> Just want to give some of my feedback for version 1.3.
>> I downloaded QuickFIX 1.3 and got it to work under RH 8.0 with gcc 3=
.2.
Compilation is fine however I had to make some changes to get examples
>> compiled.
>> 1. In CPPTest/Test.h, I have to comment out #if TYPEINFO_IN_STD =A0&=
#endif around using std::type_info; in order to it to be compiled. Mayb=
e I
am
>> missing something here.
Yeah, this is a check that is done before compilation of QuickFIX becau=
se
some systems have type_info in the std namespace while some have them i=
n
the global namespace. Looks like this is failing because the examples
configure isn't doing the same check. The base configure is pretty muc=
h
totally isolated from the examples because we wanted the examples to be=
done from the users perspective. I've added the same test into the
examples configure and that should fix it. Alternatively you could hav=
e
defined TYPEINFO_IN_STD on the command line or in config.h.
>> 2. The Java version of tradeclient works. However several things:
>> bin/run_banzai.bat seems to work for windows only, for Linux, I need=
to
change comma to colon for CLASSPATH (and use export instead set for bas=
h
>> shell)
>> Case sensitivity & slashes: I had to change new Settings(new
FileInputStream("cfg\\Banzai.cfg")); to new Settings(new FileInputStrea=
m
("cfg/banzai.cfg")); in >> order to run banzai successfully. If I remem=
ber
correctly windows also recognizes forward slash.
Yeah, as you can no doubt tell, we only ever ran that example under
windows. I made the change with the forward slashes and added a run_ba=
nzai
shell script which uses unix semantics. I have to say the application
looks quite a bit nicer on linux than it did on windows!
=
|
|
From: Chang L. <cl...@gl...> - 2002-10-29 16:34:09
|
Hi there,
Just want to give some of my feedback for version 1.3.
I downloaded QuickFIX 1.3 and got it to work under RH 8.0 with gcc 3.2.
Compilation is fine however I had to make some changes to get examples
compiled.
1. In CPPTest/Test.h, I have to comment out #if TYPEINFO_IN_STD &
#endif around using std::type_info; in order to it to be compiled. Maybe
I am missing something here.
2. The Java version of tradeclient works. However several things:
* bin/run_banzai.bat seems to work for windows only, for Linux, I
need to change comma to colon for CLASSPATH (and use export instead set
for bash shell)
* Case sensitivity & slashes: I had to change new Settings(new
FileInputStream("cfg\\Banzai.cfg")); to new Settings(new
FileInputStream("cfg/banzai.cfg")); in order to run banzai successfully.
If I remember correctly windows also recognizes forward slash.
Overall version 1.3 is much improved over 1.2.1 as far as compilation
process is concerned, and I am quite happy that JAVA version works on
Linux! Thanks for the great work.
Regards,
--Chang
|
|
From: <OM...@th...> - 2002-10-29 14:56:54
|
Found this on dotnet247.com: http://www.dotnet247.com/247reference/msgs/11/56054.aspx Some guy reported getting this exception when trying run either TibExp or RegAsm on a DLL that contains unmanaged code. Someone from the Microsoft Visual C++ compiler team responded and just said "I am working on this". Perhaps you can write to the poster of the original message and ask him if he ever found a resolution. --oren |---------+-----------------------------------------------> | | Peter Wood | | | <Pe...@af...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 10/29/2002 07:24 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: "'qui...@li...'" | | <qui...@li...> | | cc: | | Subject: [Quickfix-developers] COM TLB for .NET library | >----------------------------------------------------------------------------------------------| In attempting to generate a COM type library from the .NET QuickFIX dll using tlbexp, I get the following error at the end of the output, and the .tlb file outputed is not valid. Any suggestions as to how I could fix this problem? .... Type MessageFactory exported. Type DefaultMessageFactory exported. Type MessageCracker exported. Type MessageCracker exported. Type MessageCracker exported. Type MessageCracker exported. Type FileLog exported. Type FileLogFactory exported. Assembly exported to C:\Dev\dotNET\quickfix\lib\quickfixCOM.tlb Unhandled Exception: System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. at __DllMainCRTStartup@12(Void* , UInt32 , Void* ) Thanks, Peter ========================= Peter Wood AFA Systems (SA) Ltd Tel: +27 (0) 21 799 9900 Fax : +27 (0) 21 799 9867 Mobile: +27 (0) 82 862 3501 pe...@af... www.afa-systems.co.za ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Peter W. <Pe...@af...> - 2002-10-29 13:25:22
|
In attempting to generate a COM type library from the .NET QuickFIX dll using tlbexp, I get the following error at the end of the output, and the .tlb file outputed is not valid. Any suggestions as to how I could fix this problem? .... Type MessageFactory exported. Type DefaultMessageFactory exported. Type MessageCracker exported. Type MessageCracker exported. Type MessageCracker exported. Type MessageCracker exported. Type FileLog exported. Type FileLogFactory exported. Assembly exported to C:\Dev\dotNET\quickfix\lib\quickfixCOM.tlb Unhandled Exception: System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. at __DllMainCRTStartup@12(Void* , UInt32 , Void* ) Thanks, Peter ========================= Peter Wood AFA Systems (SA) Ltd Tel: +27 (0) 21 799 9900 Fax : +27 (0) 21 799 9867 Mobile: +27 (0) 82 862 3501 pe...@af... www.afa-systems.co.za ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** |
|
From: <OM...@th...> - 2002-10-28 13:49:05
|
I've looked at the FAQ's for several projects regarding this error message, and it appears to be a bug with the Solaris assembler. Apparently it has trouble processing long symbol names generated by using the STL. There are a few things you can do. 1) Install the GNU assembler 2) compile with the -g option 3) try using another implementation of STL that won't generate such long symbol names Also, please refer to the bug report here: http://gcc.gnu.org/ml/gcc-bugs/1999-08n/msg01030.html --oren |---------+-----------------------------------------------> | | 김상국 <kim...@be...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 10/28/2002 03:57 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: <qui...@li...> | | cc: | | Subject: [Quickfix-developers] quickfix1.3 Install error | >----------------------------------------------------------------------------------------------| I tried to install quickfix1.3 on solaris 2.6 but failed to install it. Error massages was belows. /bin/sh ../../../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../../.. - I.. -I../.. -I../../.. -fexceptions -Wall -I/usr/local/include/libxml2 -I/i nclude -I/include/solaris -c MessagesTestCase.cpp rm -f .libs/MessagesTestCase.lo c++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -I../.. -I../../.. -fexceptions -Wal l -I/usr/local/include/libxml2 -I/include -I/include/solaris -Wp, -MD,.deps/Messa gesTestCase.pp -c MessagesTestCase.cpp -fPIC -DPIC -o .libs/MessagesTestCase.lo /usr/ccs/bin/as: "/var/tmp/cc6ucy6n.s", line 39258: error: can't compute value o f an expression involving an external symbol What was wrong? Please help me to solve this problem. |
|
From: <kim...@be...> - 2002-10-28 09:57:21
|
SSB0cmllZCB0byBpbnN0YWxsIHF1aWNrZml4MS4zIG9uIHNvbGFyaXMgMi42DQpidXQgZmFpbGVk IHRvIGluc3RhbGwgaXQuDQpFcnJvciBtYXNzYWdlcyB3YXMgYmVsb3dzLg0KDQovYmluL3NoIC4u Ly4uLy4uL2xpYnRvb2wgLS1tb2RlPWNvbXBpbGUgYysrIC1ESEFWRV9DT05GSUdfSCAtSS4gLUku IC1JLi4vLi4vLi4gLQ0KSS4uIC1JLi4vLi4gLUkuLi8uLi8uLiAgICAtZmV4Y2VwdGlvbnMgLVdh bGwgICAtSS91c3IvbG9jYWwvaW5jbHVkZS9saWJ4bWwyIC1JL2kNCm5jbHVkZSAtSS9pbmNsdWRl L3NvbGFyaXMgLWMgTWVzc2FnZXNUZXN0Q2FzZS5jcHANCnJtIC1mIC5saWJzL01lc3NhZ2VzVGVz dENhc2UubG8NCmMrKyAtREhBVkVfQ09ORklHX0ggLUkuIC1JLiAtSS4uLy4uLy4uIC1JLi4gLUku Li8uLiAtSS4uLy4uLy4uIC1mZXhjZXB0aW9ucyAtV2FsDQpsIC1JL3Vzci9sb2NhbC9pbmNsdWRl L2xpYnhtbDIgLUkvaW5jbHVkZSAtSS9pbmNsdWRlL3NvbGFyaXMgLVdwLC1NRCwuZGVwcy9NZXNz YQ0KZ2VzVGVzdENhc2UucHAgLWMgTWVzc2FnZXNUZXN0Q2FzZS5jcHAgIC1mUElDIC1EUElDIC1v IC5saWJzL01lc3NhZ2VzVGVzdENhc2UubG8NCi91c3IvY2NzL2Jpbi9hczogIi92YXIvdG1wL2Nj NnVjeTZuLnMiLCBsaW5lIDM5MjU4OiBlcnJvcjogY2FuJ3QgY29tcHV0ZSB2YWx1ZSBvDQpmIGFu IGV4cHJlc3Npb24gaW52b2x2aW5nIGFuIGV4dGVybmFsIHN5bWJvbA0KDQpXaGF0IHdhcyB3cm9u Zz8gDQpQbGVhc2UgaGVscCBtZSB0byBzb2x2ZSB0aGlzIHByb2JsZW0uDQoNCg== |
|
From: <OM...@th...> - 2002-10-28 04:10:51
|
Version 1.3.0, is now available from http://quickfix.thoughtworks.com. There is a lot of new stuff here, including such long awaited features as built in database support (MySQL), JAVA support under linux AND solaris, support for repeating groups in .NET and JAVA, and complete logging of messages and events with the addition of the Log interface (Screen, File, and MySQL loggers provided). The stability problems being encountered on multi-processor machines have been resolved. Simply compile QuickFIX against STLport with older versions of gcc, or upgrade to the latest 3.x.x release. Compiling with STLport has been made easy with the addition of the --with-stlport configure option. Also keep in mind that the interface for MessageStore has changed. So if you are using a custom message store, it will need to support the new interface to use this version. Full release notes are available here: http://sourceforge.net/project/shownotes.php?group_id=37535&release_id=118939 FIX 4.3 coming soon! QuickFIX/ThoughtWorks is going to have a booth at the FIA Expo in Chicago: http://www.fiafii.org/expo2002-2275.asp If you would like a free ticket, please write to us at tr...@th... --oren |
|
From: <OM...@th...> - 2002-10-27 20:28:04
|
For users of QuickFIX that are in timezones affected by Daylight Savings, a quick reminder. Remember that your session times are set using UTC, which is unaffected by daylight savings. This means you may have to modify your session times during the time change so that your sessions are active during your local buisiness hours. --oren |
|
From: Sergey G. <se...@mi...> - 2002-10-25 22:06:41
|
Hello, What is the situation with Java API on linux/solaris? I've seen on the mail-list some mentions of the port to linux, but couldn't find any info about it in 1.2.1. Did anyone succeded to make Java API work on linux? Thanks in advance, |
|
From: <OM...@th...> - 2002-10-22 17:40:07
|
Gary, Yes, QuickFIX does support custom tags for repeating groups. There are many organizations that are using QuickFIX in a production environment. The adoption rate since its release has been extremely high. QuickFIX is a relatively young product, but the earliest adopters have been using it in a stable production environment for 5 months now. --oren |---------+-----------------------------------------------> | | GM...@Pr... | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 10/22/2002 11:46 AM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: qui...@li... | | cc: | | Subject: [Quickfix-developers] custom repeating tags in Java? | >----------------------------------------------------------------------------------------------| Hi, I just started to look at QuickFIX as a possible solution for our platform and was wondering if the Java implementation supports custom tags in repeating groups. We are using Fix 4.2 for fixed income based trading and our trading partner uses some custom tags that will be defined in Fix 4.4. But we will need to use these repeating custom tags for allocation messages. Can we do this with QuickFIX? Also, are many organizations using this product in a production environment at this point? We're looking at other commercial products and would be willing to pay for something commercial, but if this is as stable, we're not averse to Open Source software either if it is stable and can meet our functional and performance needs. Thanks, Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com ------------------------------------------------------- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <GM...@Pr...> - 2002-10-22 16:46:47
|
Hi, I just started to look at QuickFIX as a possible solution for our platform and was wondering if the Java implementation supports custom tags in repeating groups. We are using Fix 4.2 for fixed income based trading and our trading partner uses some custom tags that will be defined in Fix 4.4. But we will need to use these repeating custom tags for allocation messages. Can we do this with QuickFIX? Also, are many organizations using this product in a production environment at this point? We're looking at other commercial products and would be willing to pay for something commercial, but if this is as stable, we're not averse to Open Source software either if it is stable and can meet our functional and performance needs. Thanks, Gary Mui Prescient Markets, Inc 914-989-3118 (W) 445 Hamilton Avenue 914-422-3693 (F) White Plains, NY 10601 Please visit us at http://www.cpmarket.com |
|
From: <OM...@th...> - 2002-10-17 18:26:29
|
That's correct. The newest version in the repository has repeating groups, however a little more work needs to be done so that the fields are ordered correctly. If you will be connecting to an engine that doesn't have strict checking for field orders in repeating groups, you can start using that one right away. Otherwise new code to correct this will probably be checked in within a day or two. --oren |---------+-----------------------------------------------> | | "Jayakumar Kanniah" | | | <ja...@ob...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 10/17/2002 01:23 PM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: <qui...@li...> | | cc: | | Subject: [Quickfix-developers] Repeating Groups in Java | >----------------------------------------------------------------------------------------------| Hi, I downloaded QuickFix 1.2.1 for windows and built the lib for Java. I don't see any way to deal with Repeating groups in any of the classes. Does this mean, QuickFix 1.2.1 for Java does not support Repeating groups? Regards, Jay |
|
From: Jayakumar K. <ja...@ob...> - 2002-10-17 18:18:39
|
Hi, I downloaded QuickFix 1.2.1 for windows and built the lib for Java. I = don't see any way to deal with Repeating groups in any of the classes. = Does this mean, QuickFix 1.2.1 for Java does not support Repeating = groups? Regards, Jay |
|
From: <OM...@th...> - 2002-10-16 18:11:06
|
The latest source code for QuickFIX is now available on SourceForge. Instructions for checking out the latest code are on our developer page (http://quickfix.thoughtworks.com/developers.html). Before checking out, make sure to check the build page to verify the repository is in a working state. The next official release will be made avaiable next week. You can check the NEWS file in CVS to see what has already been implemented. --oren |
|
From: <OM...@th...> - 2002-10-15 02:22:08
|
I'm wondering if we can create an autofconf script to detect this. Due to
the nature of the problem, it probably can't be 100% deterministic, but I
imagine we can create a test that will make catching it extremely likely.
If the problem is detected, at that point we can either define
__STL_PTHREADS and display a warning, or stop the compilation altogether
and recommend the options you outlined.
I think it is important to try to automate this as much as possible because
everything *seems* ok, but really is not at all. And a warning in the
documentation, no matter how prominent, is likely to be glossed over.
Loic's broker thankfully had a test that exposed this for him, but a lot of
brokers don't have such tests, so I think we should. It would also be a
good idea to start adding load tests to the automated test suite.
--oren
Gene Gorokhovsky
<musor102@yahoo.c To: OM...@th...
om> cc: Loic Guezennec <loi...@sw...>,
qui...@li...,
10/14/2002 08:21 qui...@li...
PM Subject: Re: [Quickfix-developers] Stability problems
After some digging, it appears that libstdc++ snapshot
9 (libstdc++-2.90.8.tar.gz) is the last "official" gcc
libstd which works with 2.95.x. Judging from its
documentation, strings are MT safe in that release on
many platforms including Solaris.
For gcc 2.95.3 it requires a patch
(http://gcc.gnu.org/libstdc++/libstdc++-2.90.8-compat-gcc-2.95.3.diff)
I am not sure defining _PTHREADS out of the box is a
great idea -- string performance (and QuickFIX depends
heavliy on them strings) does suffer tremendously.
This link
http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html
has some interesting discussion, and also results
which show that map of strings performance can
decrease three-fold with _PTHREADS defined.
So Solaris options could be :
1)Using gcc 3.2 (requires recompilation of all C++
libraries)
2)Staying with gcc 2.95.x and
a)Using STLPort (4.0 and higher work with gcc 2.95.x)
b)Upgrading libstdc++ to v3 release 9 with patch and
building it with configure --enable-threads
c) Defining _PTHREADS (least effort, performance
penalty)
Gene
--- OM...@th... wrote:
>
> Gene,
>
> I've done some tests and it appears your analysis is
> dead on. Thanks for
> the lead. I am thinking of having autotools turn on
> _PTHREADS by default
> so that everything will work right out of the box,
> but recommend that
> people either upgrade their compiler or move to
> STLPort if using Solaris.
>
> --oren
>
>
>
>
|---------+----------------------------------------------->
> | | Gene Gorokhovsky
> |
> | | <mus...@ya...>
> |
> | | Sent by:
> |
> | |
> qui...@li...ur|
> | | ceforge.net
> |
> | |
> |
> | |
> |
> | | 10/10/2002 08:20 PM
> |
> | |
> |
>
|---------+----------------------------------------------->
>
>
>
----------------------------------------------------------------------------------------------|
> |
> |
> | To: Loic Guezennec
> <loi...@sw...>,
> |
> | qui...@li...
> |
> | cc:
> |
> | Subject: Re: [Quickfix-developers]
> Stability problems |
>
>
>
----------------------------------------------------------------------------------------------|
>
>
>
>
> Although Quickfix code maybe partly to blame, the
> stack that you have shown could also be caused by
> subtle misconfiguraton of gcc and STL (part of
> libstd). Some people have reported that despite
> documentation saying that it matters only for
> Objective-C, gcc itself should be compiled with
> configure --enable-threads, and that C++ compiler is
> affected by this setting. I cannot vouch for this
> though, since I have always preferred Sun's own cc,
> and had with it significantly fewer headaches (for
> some $$)
> Also in gcc 2.95.x + STL defining _PTHREADS turns on
> more robust (and signficantly slower) implementation
> of locking in STL allocator (exactly where your
> stack
> shows crash), This apparently has been fixed in 3.2,
> and the flag no longer has any effect on the code.
> Try defining this and trying your tests.
> Also, some older implemenations of STL had
> reference-counted std::string which made strings not
> thread-safe even for reading. This certainly has
> been
> fixed with gcc 3.2 release, but I am not sure about
> about older versions.
> Another option yet would be to switch to STLPort
> implementation of STL. It has had thread-safe
> strings
> from the get-go.
>
> Gene
> --- Loic Guezennec <loi...@sw...>
> wrote:
> > I have implemented a buy-side with Quickfix which
> I
> > hope to use in prod
> > soon.
> >
> > The platform is Solaris 8 sparc multi-processor.
> > compiler is gcc 2.95.3
> >
> > The application runs well when heartbeating and
> > under light load.
> >
> > I have severe instability problems when I apply a
> > load test of 50 orders
> > in one
> > go. This happens systematically.
> >
> > I believe I am experiencing the problems described
> > by Gene Gorokhovsky
> > with the
> > threading issues. The results so far are
> > segmentation faults, bus errors
> > and
> > also perhaps a deadlock... The latter being hard
> for
> > me to troubleshoot as
> > I am not an expert on threads.
> >
> >
> > An alarming point for me is the following:
> > At times that the engine crashes, I can lose
> > messages. This also seems to
> > go along
> > the message from Constantin about crash scenarios.
> >
> > Now my questions are:
> >
> > - Is quickfix known to be unstable on some
> platforms
> > ( eg Sun)
> > - Is there a preferred platform / architecture to
> > use it.
> > ( OS/ single or multi-proc/ Threaded or non
> > threaded...)
> > I have tried both threaded and non threaded
> > socket initiators
> > with no luck.
> >
> > Any feedback on what to do would be great.
> >
> >
> > An example from attaching gdb to the process:
> >
> > Reading symbols from
> > /usr/lib/libpthread.so.1...done.
> > Reading symbols from /usr/lib/librt.so.1...done.
> > Reading symbols from
> > /usr/local/lib/libxml2.so.2...done.
> > Reading symbols from /usr/lib/libz.so...done.
> > Reading symbols from
> /usr/lib/libsocket.so.1...done.
> > Reading symbols from /usr/lib/libnsl.so.1...done.
> > Reading symbols from
> > /usr/local/lib/libstdc++.so.2.10.0...done.
> > Reading symbols from /usr/lib/libm.so.1...done.
> > Reading symbols from /usr/lib/libc.so.1...done.
> > Reading symbols from /usr/lib/libaio.so.1...done.
> > Reading symbols from /usr/lib/libdl.so.1...done.
> > Reading symbols from /usr/lib/libmp.so.2...done.
> > Reading symbols from
> >
>
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...done.
> > Reading symbols from
> /usr/lib/libthread.so.1...done.
> > sol-thread active.
> > Symbols already loaded for
> /usr/lib/libpthread.so.1
> > Symbols already loaded for /usr/lib/librt.so.1
> > Symbols already loaded for
> > /usr/local/lib/libxml2.so.2
> > Symbols already loaded for /usr/lib/libz.so
> > Symbols already loaded for /usr/lib/libsocket.so.1
> > Symbols already loaded for /usr/lib/libnsl.so.1
> > Symbols already loaded for
> > /usr/local/lib/libstdc++.so.2.10.0
> > Symbols already loaded for /usr/lib/libm.so.1
> > Symbols already loaded for /usr/lib/libc.so.1
> > Symbols already loaded for /usr/lib/libaio.so.1
> > Symbols already loaded for /usr/lib/libdl.so.1
> > Symbols already loaded for /usr/lib/libmp.so.2
> > Symbols already loaded for
> > /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
> > Symbols already loaded for /usr/lib/libthread.so.1
> > 0xff0194a0 in door_restart () from
> > /usr/lib/libc.so.1
> > (gdb) continue
> > Continuing.
> > [New Thread 4 (LWP 5)]
> > [Switching to Thread 4 (LWP 5)]
> >
> > Program received signal SIGSEGV, Segmentation
> fault.
> > 0x142130 in __default_alloc_template<false,
> > 0>::allocate (__n=32)
> > at
> >
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422
>
> > 422 *__my_free_list = __result ->
> > _M_free_list_link;
> > (gdb) bt
> > #0 0x142130 in __default_alloc_template<false,
> > 0>::allocate (__n=32)
> > at
> >
>
=== message truncated ===
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
|
|
From: Gene G. <mus...@ya...> - 2002-10-15 01:21:30
|
After some digging, it appears that libstdc++ snapshot 9 (libstdc++-2.90.8.tar.gz) is the last "official" gcc libstd which works with 2.95.x. Judging from its documentation, strings are MT safe in that release on many platforms including Solaris. For gcc 2.95.3 it requires a patch (http://gcc.gnu.org/libstdc++/libstdc++-2.90.8-compat-gcc-2.95.3.diff) I am not sure defining _PTHREADS out of the box is a great idea -- string performance (and QuickFIX depends heavliy on them strings) does suffer tremendously. This link http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html has some interesting discussion, and also results which show that map of strings performance can decrease three-fold with _PTHREADS defined. So Solaris options could be : 1)Using gcc 3.2 (requires recompilation of all C++ libraries) 2)Staying with gcc 2.95.x and a)Using STLPort (4.0 and higher work with gcc 2.95.x) b)Upgrading libstdc++ to v3 release 9 with patch and building it with configure --enable-threads c) Defining _PTHREADS (least effort, performance penalty) Gene --- OM...@th... wrote: > > Gene, > > I've done some tests and it appears your analysis is > dead on. Thanks for > the lead. I am thinking of having autotools turn on > _PTHREADS by default > so that everything will work right out of the box, > but recommend that > people either upgrade their compiler or move to > STLPort if using Solaris. > > --oren > > > > |---------+-----------------------------------------------> > | | Gene Gorokhovsky > | > | | <mus...@ya...> > | > | | Sent by: > | > | | > qui...@li...ur| > | | ceforge.net > | > | | > | > | | > | > | | 10/10/2002 08:20 PM > | > | | > | > |---------+-----------------------------------------------> > > >----------------------------------------------------------------------------------------------| > | > | > | To: Loic Guezennec > <loi...@sw...>, > | > | qui...@li... > | > | cc: > | > | Subject: Re: [Quickfix-developers] > Stability problems | > > >----------------------------------------------------------------------------------------------| > > > > > Although Quickfix code maybe partly to blame, the > stack that you have shown could also be caused by > subtle misconfiguraton of gcc and STL (part of > libstd). Some people have reported that despite > documentation saying that it matters only for > Objective-C, gcc itself should be compiled with > configure --enable-threads, and that C++ compiler is > affected by this setting. I cannot vouch for this > though, since I have always preferred Sun's own cc, > and had with it significantly fewer headaches (for > some $$) > Also in gcc 2.95.x + STL defining _PTHREADS turns on > more robust (and signficantly slower) implementation > of locking in STL allocator (exactly where your > stack > shows crash), This apparently has been fixed in 3.2, > and the flag no longer has any effect on the code. > Try defining this and trying your tests. > Also, some older implemenations of STL had > reference-counted std::string which made strings not > thread-safe even for reading. This certainly has > been > fixed with gcc 3.2 release, but I am not sure about > about older versions. > Another option yet would be to switch to STLPort > implementation of STL. It has had thread-safe > strings > from the get-go. > > Gene > --- Loic Guezennec <loi...@sw...> > wrote: > > I have implemented a buy-side with Quickfix which > I > > hope to use in prod > > soon. > > > > The platform is Solaris 8 sparc multi-processor. > > compiler is gcc 2.95.3 > > > > The application runs well when heartbeating and > > under light load. > > > > I have severe instability problems when I apply a > > load test of 50 orders > > in one > > go. This happens systematically. > > > > I believe I am experiencing the problems described > > by Gene Gorokhovsky > > with the > > threading issues. The results so far are > > segmentation faults, bus errors > > and > > also perhaps a deadlock... The latter being hard > for > > me to troubleshoot as > > I am not an expert on threads. > > > > > > An alarming point for me is the following: > > At times that the engine crashes, I can lose > > messages. This also seems to > > go along > > the message from Constantin about crash scenarios. > > > > Now my questions are: > > > > - Is quickfix known to be unstable on some > platforms > > ( eg Sun) > > - Is there a preferred platform / architecture to > > use it. > > ( OS/ single or multi-proc/ Threaded or non > > threaded...) > > I have tried both threaded and non threaded > > socket initiators > > with no luck. > > > > Any feedback on what to do would be great. > > > > > > An example from attaching gdb to the process: > > > > Reading symbols from > > /usr/lib/libpthread.so.1...done. > > Reading symbols from /usr/lib/librt.so.1...done. > > Reading symbols from > > /usr/local/lib/libxml2.so.2...done. > > Reading symbols from /usr/lib/libz.so...done. > > Reading symbols from > /usr/lib/libsocket.so.1...done. > > Reading symbols from /usr/lib/libnsl.so.1...done. > > Reading symbols from > > /usr/local/lib/libstdc++.so.2.10.0...done. > > Reading symbols from /usr/lib/libm.so.1...done. > > Reading symbols from /usr/lib/libc.so.1...done. > > Reading symbols from /usr/lib/libaio.so.1...done. > > Reading symbols from /usr/lib/libdl.so.1...done. > > Reading symbols from /usr/lib/libmp.so.2...done. > > Reading symbols from > > > /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...done. > > Reading symbols from > /usr/lib/libthread.so.1...done. > > sol-thread active. > > Symbols already loaded for > /usr/lib/libpthread.so.1 > > Symbols already loaded for /usr/lib/librt.so.1 > > Symbols already loaded for > > /usr/local/lib/libxml2.so.2 > > Symbols already loaded for /usr/lib/libz.so > > Symbols already loaded for /usr/lib/libsocket.so.1 > > Symbols already loaded for /usr/lib/libnsl.so.1 > > Symbols already loaded for > > /usr/local/lib/libstdc++.so.2.10.0 > > Symbols already loaded for /usr/lib/libm.so.1 > > Symbols already loaded for /usr/lib/libc.so.1 > > Symbols already loaded for /usr/lib/libaio.so.1 > > Symbols already loaded for /usr/lib/libdl.so.1 > > Symbols already loaded for /usr/lib/libmp.so.2 > > Symbols already loaded for > > /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 > > Symbols already loaded for /usr/lib/libthread.so.1 > > 0xff0194a0 in door_restart () from > > /usr/lib/libc.so.1 > > (gdb) continue > > Continuing. > > [New Thread 4 (LWP 5)] > > [Switching to Thread 4 (LWP 5)] > > > > Program received signal SIGSEGV, Segmentation > fault. > > 0x142130 in __default_alloc_template<false, > > 0>::allocate (__n=32) > > at > > > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422 > > > 422 *__my_free_list = __result -> > > _M_free_list_link; > > (gdb) bt > > #0 0x142130 in __default_alloc_template<false, > > 0>::allocate (__n=32) > > at > > > === message truncated === __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com |
|
From: <OM...@th...> - 2002-10-14 23:11:48
|
Gene, I've done some tests and it appears your analysis is dead on. Thanks for the lead. I am thinking of having autotools turn on _PTHREADS by default so that everything will work right out of the box, but recommend that people either upgrade their compiler or move to STLPort if using Solaris. --oren |---------+-----------------------------------------------> | | Gene Gorokhovsky | | | <mus...@ya...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 10/10/2002 08:20 PM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: Loic Guezennec <loi...@sw...>, | | qui...@li... | | cc: | | Subject: Re: [Quickfix-developers] Stability problems | >----------------------------------------------------------------------------------------------| Although Quickfix code maybe partly to blame, the stack that you have shown could also be caused by subtle misconfiguraton of gcc and STL (part of libstd). Some people have reported that despite documentation saying that it matters only for Objective-C, gcc itself should be compiled with configure --enable-threads, and that C++ compiler is affected by this setting. I cannot vouch for this though, since I have always preferred Sun's own cc, and had with it significantly fewer headaches (for some $$) Also in gcc 2.95.x + STL defining _PTHREADS turns on more robust (and signficantly slower) implementation of locking in STL allocator (exactly where your stack shows crash), This apparently has been fixed in 3.2, and the flag no longer has any effect on the code. Try defining this and trying your tests. Also, some older implemenations of STL had reference-counted std::string which made strings not thread-safe even for reading. This certainly has been fixed with gcc 3.2 release, but I am not sure about about older versions. Another option yet would be to switch to STLPort implementation of STL. It has had thread-safe strings from the get-go. Gene --- Loic Guezennec <loi...@sw...> wrote: > I have implemented a buy-side with Quickfix which I > hope to use in prod > soon. > > The platform is Solaris 8 sparc multi-processor. > compiler is gcc 2.95.3 > > The application runs well when heartbeating and > under light load. > > I have severe instability problems when I apply a > load test of 50 orders > in one > go. This happens systematically. > > I believe I am experiencing the problems described > by Gene Gorokhovsky > with the > threading issues. The results so far are > segmentation faults, bus errors > and > also perhaps a deadlock... The latter being hard for > me to troubleshoot as > I am not an expert on threads. > > > An alarming point for me is the following: > At times that the engine crashes, I can lose > messages. This also seems to > go along > the message from Constantin about crash scenarios. > > Now my questions are: > > - Is quickfix known to be unstable on some platforms > ( eg Sun) > - Is there a preferred platform / architecture to > use it. > ( OS/ single or multi-proc/ Threaded or non > threaded...) > I have tried both threaded and non threaded > socket initiators > with no luck. > > Any feedback on what to do would be great. > > > An example from attaching gdb to the process: > > Reading symbols from > /usr/lib/libpthread.so.1...done. > Reading symbols from /usr/lib/librt.so.1...done. > Reading symbols from > /usr/local/lib/libxml2.so.2...done. > Reading symbols from /usr/lib/libz.so...done. > Reading symbols from /usr/lib/libsocket.so.1...done. > Reading symbols from /usr/lib/libnsl.so.1...done. > Reading symbols from > /usr/local/lib/libstdc++.so.2.10.0...done. > Reading symbols from /usr/lib/libm.so.1...done. > Reading symbols from /usr/lib/libc.so.1...done. > Reading symbols from /usr/lib/libaio.so.1...done. > Reading symbols from /usr/lib/libdl.so.1...done. > Reading symbols from /usr/lib/libmp.so.2...done. > Reading symbols from > /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...done. > Reading symbols from /usr/lib/libthread.so.1...done. > sol-thread active. > Symbols already loaded for /usr/lib/libpthread.so.1 > Symbols already loaded for /usr/lib/librt.so.1 > Symbols already loaded for > /usr/local/lib/libxml2.so.2 > Symbols already loaded for /usr/lib/libz.so > Symbols already loaded for /usr/lib/libsocket.so.1 > Symbols already loaded for /usr/lib/libnsl.so.1 > Symbols already loaded for > /usr/local/lib/libstdc++.so.2.10.0 > Symbols already loaded for /usr/lib/libm.so.1 > Symbols already loaded for /usr/lib/libc.so.1 > Symbols already loaded for /usr/lib/libaio.so.1 > Symbols already loaded for /usr/lib/libdl.so.1 > Symbols already loaded for /usr/lib/libmp.so.2 > Symbols already loaded for > /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 > Symbols already loaded for /usr/lib/libthread.so.1 > 0xff0194a0 in door_restart () from > /usr/lib/libc.so.1 > (gdb) continue > Continuing. > [New Thread 4 (LWP 5)] > [Switching to Thread 4 (LWP 5)] > > Program received signal SIGSEGV, Segmentation fault. > 0x142130 in __default_alloc_template<false, > 0>::allocate (__n=32) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422 > 422 *__my_free_list = __result -> > _M_free_list_link; > (gdb) bt > #0 0x142130 in __default_alloc_template<false, > 0>::allocate (__n=32) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422 > #1 0xc5148 in > __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3RepUiUi > > (s=16, extra=16) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:33 > #2 0xc5488 in basic_string<char, > string_char_traits<char>, > __default_alloc_template<false, 0> >::Rep::create > (extra=16) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:60 > #3 0xc858c in basic_string<char, > string_char_traits<char>, > __default_alloc_template<false, 0> >::replace > (this=0xfeeff390, pos=0, > n1=0, > s=0x24c2e0 "164\0306421", n2=3) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:164 > #4 0x165d34 in basic_string<char, > string_char_traits<char>, > __default_alloc_template<false, 0> >::assign > (this=0xfeeff390, s=0x24c2e0 > "164\0306421", n=3) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:218 > #5 0x196d98 in basic_string<char, > string_char_traits<char>, > __default_alloc_template<false, 0> >::basic_string > (this=0xfeeff390, > s=0x24c2e0 "164\0306421", > n=3) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:176 > #6 0x18cf30 in stringbuf::str (this=0xfeeff29c) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:77 > #7 0x1a0ca0 in stringstream::str (this=0xfeeff290) > at > /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:330 > #8 0x1a3b98 in FIX::CheckSumConvertor::convert > (value=164) > at FieldConvertors.h:115 > #9 0x1a1810 in FIX::CheckSumField::CheckSumField > (this=0xfeeff4f0, > field=10, > data=164) at Field.h:328 > #10 0x19e960 in FIX::CheckSum::CheckSum > (this=0xfeeff4f0, value=164) > at Fields.h:68 > #11 0x192ff8 in FIX::Message::checkSum > (this=0xfeeffac8) at Message.h:292 > #12 0x188a40 in FIX::Message::getString > (this=0xfeeffac8) at Message.h:147 > #13 0xae760 in FIX::Session::sendRaw (this=0x251b28, > message=@0xfeeffac8, > msgSeqNum=0) at Session.cpp:323 > #14 0xae498 in FIX::Session::send (this=0x251b28, > message=@0xfeeffac8) > at Session.cpp:293 > #15 0xb3950 in FIX::Session::sendToTarget > (message=@0xfeeffac8) > at Session.cpp:849 > #16 0x91278 in Application::enterOrderSingle > (this=0xffbefc40, mapOrd={ > _M_t = {<_Rb_tree_base<pair<const > basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > >,basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > > > >,allocator<basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > > > >> > = {<_Rb_tree_alloc_base<pair<const > basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > >,basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > > > >,allocator<basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > > >,>> > = {_M_header = 0x26d250}, <No data fields>}, > _M_node_count = 31, > _M_key_compare = > {<binary_function<basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > >,basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > >,bool>> > = {<No data fields>}, <No data f---Type <return> to > continue, or q > <return> to quit--- > ields>}}}) at Application.cpp:1064 > #17 0x8f3d4 in Application::onRun (this=0xffbefc40) > at Application.cpp:827 > #18 0xb6c5c in FIX::Initiator::startThread > (p=0xffbefb58) at > Initiator.cpp:151 > (gdb) > > > Loic Guezennec > === message truncated === __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: <OM...@th...> - 2002-10-11 14:51:48
|
Yeah. Part of this effort will be to move the current code into the
sourceforge repository. Right now the build pages are being generated off
of the ThoughtWorks repository, which is up to date. We will be switching
that to sourceforge next week so the current code base will be available
then.
--oren
"Mustafa Radi"
<m....@ka...> To: <qui...@li...>, <OM...@th...>
cc:
10/11/2002 01:38 Subject: Re: [Quickfix-developers] QuickFIX build pages, sneak preview
AM
sorry for the stupid question - but where do I find the sources ?
When I browse through CVS I only see 7 month old code - independent
which tag I am using ....
----- Original Message -----
From: <OM...@th...>
To: <qui...@li...>
Sent: Friday, October 11, 2002 3:55 AM
Subject: [Quickfix-developers] QuickFIX build pages, sneak preview
> QuickFIX build pages for windows vc6, windows vc7, and linux gcc 2.95.2
can
> now be viewed on the public web site. A Solaris page will be available
> soon. We intend on adding more configurations over time.
>
> This automated build process is made possible by CruiseControl
> (http://cruisecontrol.sourceforge.net/). If you are not familiar with
the
> concept of Continuous Integration, I strongly suggest you take a look.
>
> The QF build machines are monitoring the CVS repository. They will build
> the code, and run all tests whenever they detect changes in the code
base.
> These pages give a lot of useful information about each build.
>
> The most current builds can be found at:
> http://quickfix.thoughtworks.com/cchtml/[windows_vc7].html
> http://quickfix.thoughtworks.com/cchtml/[windows_vc6].html
> http://quickfix.thoughtworks.com/cchtml/[linux-pgcc-2-95-2].html
>
> I wanted the people on this list to take a look and provide comments
before
> I create a summary page on the website.
>
> The first you thing you will notice up top is either a large green BUILD
> SUCCEEDED or large red BUILD FAILED. A build will be considered
succesful
> if it is able to compile, able to pass all of its unit tests, and able to
> pass all regression tests. Each succesful build will have a unique label
> (i.e. [windows_vc6].8).
>
> The other sections reported are as follows:
>
> Unit Tests
> ---------------
> Displays how many tests are run and how many failed. All must pass in a
> succesful build. If any tests fail, a report will be show indicated what
> test failed and on which line of code.
>
> Regression Tests
> ---------------------------
> Functional regression tests. Displays how many tests are run and how
many
> failed. All must pass in a succesful build. Test names are followed by
> either a green SUCCESS box or a red FAILURE box. If a test fails, a
> description of either why it failed or which message it failed on will be
> displayed.
>
> New Tests
> ----------------
> Works just like regression tests except they do not have to pass in a
> succesful build. These are generally new features in development.
>
> Modifications
> -------------------
> Complete list of any changes to the repository. Shows who made changes
to
> the repository and at what time including check in comments.
>
> Output
> ---------
> Display of the actual console build. In a failed build, this is where
you
> will find error messages.
>
> --oren
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
|
|
From: Mustafa R. <m....@ka...> - 2002-10-11 06:37:01
|
sorry for the stupid question - but where do I find the sources ? When I browse through CVS I only see 7 month old code - independent which tag I am using .... ----- Original Message ----- From: <OM...@th...> To: <qui...@li...> Sent: Friday, October 11, 2002 3:55 AM Subject: [Quickfix-developers] QuickFIX build pages, sneak preview > QuickFIX build pages for windows vc6, windows vc7, and linux gcc 2.95.2 can > now be viewed on the public web site. A Solaris page will be available > soon. We intend on adding more configurations over time. > > This automated build process is made possible by CruiseControl > (http://cruisecontrol.sourceforge.net/). If you are not familiar with the > concept of Continuous Integration, I strongly suggest you take a look. > > The QF build machines are monitoring the CVS repository. They will build > the code, and run all tests whenever they detect changes in the code base. > These pages give a lot of useful information about each build. > > The most current builds can be found at: > http://quickfix.thoughtworks.com/cchtml/[windows_vc7].html > http://quickfix.thoughtworks.com/cchtml/[windows_vc6].html > http://quickfix.thoughtworks.com/cchtml/[linux-pgcc-2-95-2].html > > I wanted the people on this list to take a look and provide comments before > I create a summary page on the website. > > The first you thing you will notice up top is either a large green BUILD > SUCCEEDED or large red BUILD FAILED. A build will be considered succesful > if it is able to compile, able to pass all of its unit tests, and able to > pass all regression tests. Each succesful build will have a unique label > (i.e. [windows_vc6].8). > > The other sections reported are as follows: > > Unit Tests > --------------- > Displays how many tests are run and how many failed. All must pass in a > succesful build. If any tests fail, a report will be show indicated what > test failed and on which line of code. > > Regression Tests > --------------------------- > Functional regression tests. Displays how many tests are run and how many > failed. All must pass in a succesful build. Test names are followed by > either a green SUCCESS box or a red FAILURE box. If a test fails, a > description of either why it failed or which message it failed on will be > displayed. > > New Tests > ---------------- > Works just like regression tests except they do not have to pass in a > succesful build. These are generally new features in development. > > Modifications > ------------------- > Complete list of any changes to the repository. Shows who made changes to > the repository and at what time including check in comments. > > Output > --------- > Display of the actual console build. In a failed build, this is where you > will find error messages. > > --oren > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: <OM...@th...> - 2002-10-11 01:58:11
|
QuickFIX build pages for windows vc6, windows vc7, and linux gcc 2.95.2 can now be viewed on the public web site. A Solaris page will be available soon. We intend on adding more configurations over time. This automated build process is made possible by CruiseControl (http://cruisecontrol.sourceforge.net/). If you are not familiar with the concept of Continuous Integration, I strongly suggest you take a look. The QF build machines are monitoring the CVS repository. They will build the code, and run all tests whenever they detect changes in the code base. These pages give a lot of useful information about each build. The most current builds can be found at: http://quickfix.thoughtworks.com/cchtml/[windows_vc7].html http://quickfix.thoughtworks.com/cchtml/[windows_vc6].html http://quickfix.thoughtworks.com/cchtml/[linux-pgcc-2-95-2].html I wanted the people on this list to take a look and provide comments before I create a summary page on the website. The first you thing you will notice up top is either a large green BUILD SUCCEEDED or large red BUILD FAILED. A build will be considered succesful if it is able to compile, able to pass all of its unit tests, and able to pass all regression tests. Each succesful build will have a unique label (i.e. [windows_vc6].8). The other sections reported are as follows: Unit Tests --------------- Displays how many tests are run and how many failed. All must pass in a succesful build. If any tests fail, a report will be show indicated what test failed and on which line of code. Regression Tests --------------------------- Functional regression tests. Displays how many tests are run and how many failed. All must pass in a succesful build. Test names are followed by either a green SUCCESS box or a red FAILURE box. If a test fails, a description of either why it failed or which message it failed on will be displayed. New Tests ---------------- Works just like regression tests except they do not have to pass in a succesful build. These are generally new features in development. Modifications ------------------- Complete list of any changes to the repository. Shows who made changes to the repository and at what time including check in comments. Output --------- Display of the actual console build. In a failed build, this is where you will find error messages. --oren |
|
From: Gene G. <mus...@ya...> - 2002-10-11 01:20:39
|
Although Quickfix code maybe partly to blame, the
stack that you have shown could also be caused by
subtle misconfiguraton of gcc and STL (part of
libstd). Some people have reported that despite
documentation saying that it matters only for
Objective-C, gcc itself should be compiled with
configure --enable-threads, and that C++ compiler is
affected by this setting. I cannot vouch for this
though, since I have always preferred Sun's own cc,
and had with it significantly fewer headaches (for
some $$)
Also in gcc 2.95.x + STL defining _PTHREADS turns on
more robust (and signficantly slower) implementation
of locking in STL allocator (exactly where your stack
shows crash), This apparently has been fixed in 3.2,
and the flag no longer has any effect on the code.
Try defining this and trying your tests.
Also, some older implemenations of STL had
reference-counted std::string which made strings not
thread-safe even for reading. This certainly has been
fixed with gcc 3.2 release, but I am not sure about
about older versions.
Another option yet would be to switch to STLPort
implementation of STL. It has had thread-safe strings
from the get-go.
Gene
--- Loic Guezennec <loi...@sw...>
wrote:
> I have implemented a buy-side with Quickfix which I
> hope to use in prod
> soon.
>
> The platform is Solaris 8 sparc multi-processor.
> compiler is gcc 2.95.3
>
> The application runs well when heartbeating and
> under light load.
>
> I have severe instability problems when I apply a
> load test of 50 orders
> in one
> go. This happens systematically.
>
> I believe I am experiencing the problems described
> by Gene Gorokhovsky
> with the
> threading issues. The results so far are
> segmentation faults, bus errors
> and
> also perhaps a deadlock... The latter being hard for
> me to troubleshoot as
> I am not an expert on threads.
>
>
> An alarming point for me is the following:
> At times that the engine crashes, I can lose
> messages. This also seems to
> go along
> the message from Constantin about crash scenarios.
>
> Now my questions are:
>
> - Is quickfix known to be unstable on some platforms
> ( eg Sun)
> - Is there a preferred platform / architecture to
> use it.
> ( OS/ single or multi-proc/ Threaded or non
> threaded...)
> I have tried both threaded and non threaded
> socket initiators
> with no luck.
>
> Any feedback on what to do would be great.
>
>
> An example from attaching gdb to the process:
>
> Reading symbols from
> /usr/lib/libpthread.so.1...done.
> Reading symbols from /usr/lib/librt.so.1...done.
> Reading symbols from
> /usr/local/lib/libxml2.so.2...done.
> Reading symbols from /usr/lib/libz.so...done.
> Reading symbols from /usr/lib/libsocket.so.1...done.
> Reading symbols from /usr/lib/libnsl.so.1...done.
> Reading symbols from
> /usr/local/lib/libstdc++.so.2.10.0...done.
> Reading symbols from /usr/lib/libm.so.1...done.
> Reading symbols from /usr/lib/libc.so.1...done.
> Reading symbols from /usr/lib/libaio.so.1...done.
> Reading symbols from /usr/lib/libdl.so.1...done.
> Reading symbols from /usr/lib/libmp.so.2...done.
> Reading symbols from
>
/usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...done.
> Reading symbols from /usr/lib/libthread.so.1...done.
> sol-thread active.
> Symbols already loaded for /usr/lib/libpthread.so.1
> Symbols already loaded for /usr/lib/librt.so.1
> Symbols already loaded for
> /usr/local/lib/libxml2.so.2
> Symbols already loaded for /usr/lib/libz.so
> Symbols already loaded for /usr/lib/libsocket.so.1
> Symbols already loaded for /usr/lib/libnsl.so.1
> Symbols already loaded for
> /usr/local/lib/libstdc++.so.2.10.0
> Symbols already loaded for /usr/lib/libm.so.1
> Symbols already loaded for /usr/lib/libc.so.1
> Symbols already loaded for /usr/lib/libaio.so.1
> Symbols already loaded for /usr/lib/libdl.so.1
> Symbols already loaded for /usr/lib/libmp.so.2
> Symbols already loaded for
> /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
> Symbols already loaded for /usr/lib/libthread.so.1
> 0xff0194a0 in door_restart () from
> /usr/lib/libc.so.1
> (gdb) continue
> Continuing.
> [New Thread 4 (LWP 5)]
> [Switching to Thread 4 (LWP 5)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x142130 in __default_alloc_template<false,
> 0>::allocate (__n=32)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422
> 422 *__my_free_list = __result ->
> _M_free_list_link;
> (gdb) bt
> #0 0x142130 in __default_alloc_template<false,
> 0>::allocate (__n=32)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422
> #1 0xc5148 in
>
__nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3RepUiUi
>
> (s=16, extra=16)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:33
> #2 0xc5488 in basic_string<char,
> string_char_traits<char>,
> __default_alloc_template<false, 0> >::Rep::create
> (extra=16)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:60
> #3 0xc858c in basic_string<char,
> string_char_traits<char>,
> __default_alloc_template<false, 0> >::replace
> (this=0xfeeff390, pos=0,
> n1=0,
> s=0x24c2e0 "164\0306421", n2=3)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:164
> #4 0x165d34 in basic_string<char,
> string_char_traits<char>,
> __default_alloc_template<false, 0> >::assign
> (this=0xfeeff390, s=0x24c2e0
> "164\0306421", n=3)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:218
> #5 0x196d98 in basic_string<char,
> string_char_traits<char>,
> __default_alloc_template<false, 0> >::basic_string
> (this=0xfeeff390,
> s=0x24c2e0 "164\0306421",
> n=3)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:176
> #6 0x18cf30 in stringbuf::str (this=0xfeeff29c)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:77
> #7 0x1a0ca0 in stringstream::str (this=0xfeeff290)
> at
>
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:330
> #8 0x1a3b98 in FIX::CheckSumConvertor::convert
> (value=164)
> at FieldConvertors.h:115
> #9 0x1a1810 in FIX::CheckSumField::CheckSumField
> (this=0xfeeff4f0,
> field=10,
> data=164) at Field.h:328
> #10 0x19e960 in FIX::CheckSum::CheckSum
> (this=0xfeeff4f0, value=164)
> at Fields.h:68
> #11 0x192ff8 in FIX::Message::checkSum
> (this=0xfeeffac8) at Message.h:292
> #12 0x188a40 in FIX::Message::getString
> (this=0xfeeffac8) at Message.h:147
> #13 0xae760 in FIX::Session::sendRaw (this=0x251b28,
> message=@0xfeeffac8,
> msgSeqNum=0) at Session.cpp:323
> #14 0xae498 in FIX::Session::send (this=0x251b28,
> message=@0xfeeffac8)
> at Session.cpp:293
> #15 0xb3950 in FIX::Session::sendToTarget
> (message=@0xfeeffac8)
> at Session.cpp:849
> #16 0x91278 in Application::enterOrderSingle
> (this=0xffbefc40, mapOrd={
> _M_t = {<_Rb_tree_base<pair<const
>
basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
>
>,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
> >
>
>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
> > > >>
> = {<_Rb_tree_alloc_base<pair<const
>
basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
>
>,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
> >
>
>,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
> > >,>>
> = {_M_header = 0x26d250}, <No data fields>},
> _M_node_count = 31,
> _M_key_compare =
>
{<binary_function<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
>
>,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0>
> >,bool>>
> = {<No data fields>}, <No data f---Type <return> to
> continue, or q
> <return> to quit---
> ields>}}}) at Application.cpp:1064
> #17 0x8f3d4 in Application::onRun (this=0xffbefc40)
> at Application.cpp:827
> #18 0xb6c5c in FIX::Initiator::startThread
> (p=0xffbefb58) at
> Initiator.cpp:151
> (gdb)
>
>
> Loic Guezennec
>
=== message truncated ===
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
|
|
From: <OM...@th...> - 2002-10-10 20:27:18
|
Mustafa, We have succesfully ported the java JNI layer under linux. Thanks to feedback from Joerg Thoennes and Raphael M. Grochtmann from Macdonald Associates GmbH in Germany, and to MEK Securities in Connecticut for subsidizing this work. Currently we are still building quickfix as a static library, and have created a quickfix_jni.so which statically links it in. It is a slightly larger footprint but works for now. The java library for linux will probably be released sometime next week. --oren |---------+-----------------------------------------------> | | Mustafa Radi <m....@ka...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 10/10/2002 03:10 PM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: qui...@li... | | cc: | | Subject: [Quickfix-developers] HELP - linux shared library - and now ??? | >----------------------------------------------------------------------------------------------| Hi there, I am new to that group, but like the approch of how this fix-library is generated. Thats why I started to create the shared library today. Well, I have now a working shared library under linux <quickfix.so> and can start tha java-application "Banzai".java - no problems with the shared library but, as soon as I want to access a native method I get "java.lang.UnsatisfiedLinkError" which occures because the c++-sources in the directory src/java is not compiled and linked to the library generated in src/C++. Thats fine so lets try to compile the directory src/java with all the generated classes from javah ... I created a Makefile since the existing once are ignored but URGS - this is no "ansi-C" standard but seems to be BorlandC++ code. There are includefiles that are NOT available under unix and all conversion-methods as well as operators are not compatible to g++. Even the build.xml file with ant is only available for windows because it uses several windows executeables ... Now I am realy frustrated - after hours of work with the shared library - no satisfaction in the end - sometimes I don't like computers ;-) But perhaps sombody out there can help to solve these final problems now. Here is what must be done to get a shared library that resolves all symbols and manages exeptiopns: (1) first of all you have to compile with the option -fPIC (this makes address-independent code which is necessary for shared libraries) ==> to do that change the line in configure.in from < CFLAGS="-D_XOPEN_SOURCE=500 $XML_CFLAGS" to > CFLAGS="-D_XOPEN_SOURCE=500 -fPIC $XML_CFLAGS" (2) change the line in src/C++/Makefile.in from < libquickfix_la_LDFLAGS = -static to > libquickfix_la_LDFLAGS = -shared (3) call ./bootstrap ./configure --enable-shared (4) this will generate a shared library but because exceptions are used there are still some symbols not linked to the library :-( If you look at the output of the link commands you will see, a line like gcc -shared Session.lo SessionFactory.lo Parser.lo Settings.lo ConfigLexer.lo MessageStore.lo SocketServer.lo SocketConnector.lo SocketStream.lo Acceptor.lo Initiator.lo SocketAcceptor.lo SocketInitiator.lo SocketMonitor.lo SocketConnection.lo ThreadedSocketAcceptor.lo ThreadedSocketInitiator.lo ThreadedSocketConnection.lo FileStore.lo Dictionary.lo DataDictionary.lo SessionSettings.lo MessageSorters.lo Utility.lo -L/usr/lib /usr/lib/libxml2.so -lz -lm -liberty -Wl,-soname -Wl,libquickfix.so.0 -o .libs/libquickfix.so.0.0.0 the problem is, that gcc is using the c-link library and NOT c++ link-library - thus exceptions are NOT handled correctly in libraries. To achieve a working library you must copy the complete line and replace gcc with g++ in the directory src/C++ >> that's it !!! g++ -shared Session.lo SessionFactory.lo Parser.lo Settings.lo ConfigLexer.lo MessageStore.lo SocketServer.lo SocketConnector.lo SocketStream.lo Acceptor.lo Initiator.lo SocketAcceptor.lo SocketInitiator.lo SocketMonitor.lo SocketConnection.lo ThreadedSocketAcceptor.lo ThreadedSocketInitiator.lo ThreadedSocketConnection.lo FileStore.lo Dictionary.lo DataDictionary.lo SessionSettings.lo MessageSorters.lo Utility.lo -L/usr/lib /usr/lib/libxml2.so -lz -lm -liberty -Wl,-soname -Wl,libquickfix.so.0 -o .libs/libquickfix.so.0.0.0 ===> yeahhhh - we have a shared library (5) unfortunatelly java doesn't know anything about our new library - thus insert in your main class public class myMain { static { System.loadLibrary("quickfix"); } static public Main(String args[]) { ... blabla ... } } and don't forget to start java with the option -Djava.library.path e.g. java -Djava.library.path=/usr/local/lib myTest That's all. I hope I could help to get towards a java-library under linux - I really need that, but currently there seems to be no chance instead of developing the complete access-layer in the directory src/java completly new - that sounds ugly ! with best regards P.S. by the way - great job thoughtworks.COM - will there be a fix for the java-code ? soon ??? |
|
From: Mustafa R. <m....@ka...> - 2002-10-10 20:08:56
|
Hi there,
I am new to that group, but like the approch of how this fix-library is
generated. Thats why
I started to create the shared library today. Well, I have now a working
shared library under
linux <quickfix.so> and can start tha java-application
"Banzai".java - no problems with the shared library but, as soon as I
want to access a native method I get "java.lang.UnsatisfiedLinkError"
which occures because the c++-sources in the
directory src/java is not compiled and linked to the library generated
in src/C++.
Thats fine so lets try to compile the directory src/java with all the
generated classes from javah ...
I created a Makefile since the existing once are ignored but
URGS - this is no "ansi-C" standard but seems to be BorlandC++ code.
There are includefiles
that are NOT available under unix and all conversion-methods as well as
operators are
not compatible to g++. Even the build.xml file with ant is only
available for windows because
it uses several windows executeables ...
Now I am realy frustrated - after hours of work with the shared library
- no satisfaction in the end - sometimes I don't like computers ;-)
But perhaps sombody out there can help to solve these final problems
now. Here is what must
be done to get a shared library that resolves all symbols and manages
exeptiopns:
(1) first of all you have to compile with the option -fPIC (this makes
address-independent code which is necessary for shared libraries)
==> to do that change the line in configure.in from
< CFLAGS="-D_XOPEN_SOURCE=500 $XML_CFLAGS"
to
> CFLAGS="-D_XOPEN_SOURCE=500 -fPIC $XML_CFLAGS"
(2) change the line in src/C++/Makefile.in from
< libquickfix_la_LDFLAGS = -static
to
> libquickfix_la_LDFLAGS = -shared
(3) call ./bootstrap
./configure --enable-shared
(4) this will generate a shared library but because exceptions are used
there are still some
symbols not linked to the library :-(
If you look at the output of the link commands you will see, a line like
gcc -shared Session.lo SessionFactory.lo Parser.lo Settings.lo
ConfigLexer.lo MessageStore.lo SocketServer.lo SocketConnector.lo
SocketStream.lo Acceptor.lo Initiator.lo SocketAcceptor.lo
SocketInitiator.lo SocketMonitor.lo SocketConnection.lo
ThreadedSocketAcceptor.lo ThreadedSocketInitiator.lo
ThreadedSocketConnection.lo FileStore.lo Dictionary.lo DataDictionary.lo
SessionSettings.lo MessageSorters.lo Utility.lo -L/usr/lib
/usr/lib/libxml2.so -lz -lm -liberty -Wl,-soname -Wl,libquickfix.so.0
-o .libs/libquickfix.so.0.0.0
the problem is, that gcc is using the c-link library and NOT c++
link-library - thus exceptions
are NOT handled correctly in libraries. To achieve a working library you
must copy the complete
line and replace gcc with g++ in the directory src/C++ >> that's it !!!
g++ -shared Session.lo SessionFactory.lo Parser.lo Settings.lo
ConfigLexer.lo MessageStore.lo SocketServer.lo SocketConnector.lo
SocketStream.lo Acceptor.lo Initiator.lo SocketAcceptor.lo
SocketInitiator.lo SocketMonitor.lo SocketConnection.lo
ThreadedSocketAcceptor.lo ThreadedSocketInitiator.lo
ThreadedSocketConnection.lo FileStore.lo Dictionary.lo DataDictionary.lo
SessionSettings.lo MessageSorters.lo Utility.lo -L/usr/lib
/usr/lib/libxml2.so -lz -lm -liberty -Wl,-soname -Wl,libquickfix.so.0
-o .libs/libquickfix.so.0.0.0
===> yeahhhh - we have a shared library
(5) unfortunatelly java doesn't know anything about our new library -
thus insert in your main class
public class myMain {
static {
System.loadLibrary("quickfix");
}
static public Main(String args[]) {
... blabla ...
}
}
and don't forget to start java with the option -Djava.library.path
e.g. java -Djava.library.path=/usr/local/lib myTest
That's all.
I hope I could help to get towards a java-library under linux - I really
need that, but
currently there seems to be no chance instead of developing the complete
access-layer
in the directory src/java completly new - that sounds ugly !
with best regards
P.S. by the way - great job thoughtworks.COM - will there be a fix for
the java-code ? soon ???
|
|
From: <OM...@th...> - 2002-10-10 18:21:38
|
Loic, We have never run quickfix on a multi-processor Solaris machine, so in that respect you are doing something that we have never tested. Our clients tend to use linux or windows so those versions may tend to be a little more robust. In general I would recomend using the normal SocketInitiator over the Threaded one under Solaris. We have had trouble getting consistantly stable performance from the threaded implementations under Solaris, and since we have not as of yet had the demand, little work has been done to significatly improve it. Much work has been done in the upcoming release to address threading and crash recovery situations in general, as well as overall performance. This will probably help to improve the Solaris version as well. When we were implementing a market data server under 1.2.1 we ran into many of these issues and I believe have solved most of them. We plan on addressing differences between builds by setting up an online build page with a suite of automated tests. This is intended to go online early next week. We have a suite of unit tests and functional tests that we run with each build. We want to also design a set of performance tests that are also run with each build. --oren |---------+-----------------------------------------------> | | Loic Guezennec | | | <loi...@sw...> | | | Sent by: | | | qui...@li...ur| | | ceforge.net | | | | | | | | | 10/10/2002 02:46 PM | | | | |---------+-----------------------------------------------> >----------------------------------------------------------------------------------------------| | | | To: qui...@li... | | cc: | | Subject: [Quickfix-developers] Stability problems | >----------------------------------------------------------------------------------------------| I have implemented a buy-side with Quickfix which I hope to use in prod soon. The platform is Solaris 8 sparc multi-processor. compiler is gcc 2.95.3 The application runs well when heartbeating and under light load. I have severe instability problems when I apply a load test of 50 orders in one go. This happens systematically. I believe I am experiencing the problems described by Gene Gorokhovsky with the threading issues. The results so far are segmentation faults, bus errors and also perhaps a deadlock... The latter being hard for me to troubleshoot as I am not an expert on threads. An alarming point for me is the following: At times that the engine crashes, I can lose messages. This also seems to go along the message from Constantin about crash scenarios. Now my questions are: - Is quickfix known to be unstable on some platforms ( eg Sun) - Is there a preferred platform / architecture to use it. ( OS/ single or multi-proc/ Threaded or non threaded...) I have tried both threaded and non threaded socket initiators with no luck. Any feedback on what to do would be great. An example from attaching gdb to the process: Reading symbols from /usr/lib/libpthread.so.1...done. Reading symbols from /usr/lib/librt.so.1...done. Reading symbols from /usr/local/lib/libxml2.so.2...done. Reading symbols from /usr/lib/libz.so...done. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/local/lib/libstdc++.so.2.10.0...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/lib/libaio.so.1...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /usr/lib/libmp.so.2...done. Reading symbols from /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...done. Reading symbols from /usr/lib/libthread.so.1...done. sol-thread active. Symbols already loaded for /usr/lib/libpthread.so.1 Symbols already loaded for /usr/lib/librt.so.1 Symbols already loaded for /usr/local/lib/libxml2.so.2 Symbols already loaded for /usr/lib/libz.so Symbols already loaded for /usr/lib/libsocket.so.1 Symbols already loaded for /usr/lib/libnsl.so.1 Symbols already loaded for /usr/local/lib/libstdc++.so.2.10.0 Symbols already loaded for /usr/lib/libm.so.1 Symbols already loaded for /usr/lib/libc.so.1 Symbols already loaded for /usr/lib/libaio.so.1 Symbols already loaded for /usr/lib/libdl.so.1 Symbols already loaded for /usr/lib/libmp.so.2 Symbols already loaded for /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1 Symbols already loaded for /usr/lib/libthread.so.1 0xff0194a0 in door_restart () from /usr/lib/libc.so.1 (gdb) continue Continuing. [New Thread 4 (LWP 5)] [Switching to Thread 4 (LWP 5)] Program received signal SIGSEGV, Segmentation fault. 0x142130 in __default_alloc_template<false, 0>::allocate (__n=32) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422 422 *__my_free_list = __result -> _M_free_list_link; (gdb) bt #0 0x142130 in __default_alloc_template<false, 0>::allocate (__n=32) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422 #1 0xc5148 in __nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3RepUiUi (s=16, extra=16) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:33 #2 0xc5488 in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::Rep::create (extra=16) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:60 #3 0xc858c in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::replace (this=0xfeeff390, pos=0, n1=0, s=0x24c2e0 "164\0306421", n2=3) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:164 #4 0x165d34 in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::assign (this=0xfeeff390, s=0x24c2e0 "164\0306421", n=3) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:218 #5 0x196d98 in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >::basic_string (this=0xfeeff390, s=0x24c2e0 "164\0306421", n=3) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:176 #6 0x18cf30 in stringbuf::str (this=0xfeeff29c) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:77 #7 0x1a0ca0 in stringstream::str (this=0xfeeff290) at /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:330 #8 0x1a3b98 in FIX::CheckSumConvertor::convert (value=164) at FieldConvertors.h:115 #9 0x1a1810 in FIX::CheckSumField::CheckSumField (this=0xfeeff4f0, field=10, data=164) at Field.h:328 #10 0x19e960 in FIX::CheckSum::CheckSum (this=0xfeeff4f0, value=164) at Fields.h:68 #11 0x192ff8 in FIX::Message::checkSum (this=0xfeeffac8) at Message.h:292 #12 0x188a40 in FIX::Message::getString (this=0xfeeffac8) at Message.h:147 #13 0xae760 in FIX::Session::sendRaw (this=0x251b28, message=@0xfeeffac8, msgSeqNum=0) at Session.cpp:323 #14 0xae498 in FIX::Session::send (this=0x251b28, message=@0xfeeffac8) at Session.cpp:293 #15 0xb3950 in FIX::Session::sendToTarget (message=@0xfeeffac8) at Session.cpp:849 #16 0x91278 in Application::enterOrderSingle (this=0xffbefc40, mapOrd={ _M_t = {<_Rb_tree_base<pair<const basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> >,basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > >,allocator<basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > > >> = {<_Rb_tree_alloc_base<pair<const basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> >,basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > >,allocator<basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> > >,>> = {_M_header = 0x26d250}, <No data fields>}, _M_node_count = 31, _M_key_compare = {<binary_function<basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> >,basic_string<char,string_char_traits<char>, __default_alloc_template<false,0> >,bool>> = {<No data fields>}, <No data f---Type <return> to continue, or q <return> to quit--- ields>}}}) at Application.cpp:1064 #17 0x8f3d4 in Application::onRun (this=0xffbefc40) at Application.cpp:827 #18 0xb6c5c in FIX::Initiator::startThread (p=0xffbefb58) at Initiator.cpp:151 (gdb) Loic Guezennec ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Loic G. <loi...@sw...> - 2002-10-10 17:52:19
|
I have implemented a buy-side with Quickfix which I hope to use in prod
soon.
The platform is Solaris 8 sparc multi-processor.
compiler is gcc 2.95.3
The application runs well when heartbeating and under light load.
I have severe instability problems when I apply a load test of 50 orders
in one
go. This happens systematically.
I believe I am experiencing the problems described by Gene Gorokhovsky
with the
threading issues. The results so far are segmentation faults, bus errors
and
also perhaps a deadlock... The latter being hard for me to troubleshoot as
I am not an expert on threads.
An alarming point for me is the following:
At times that the engine crashes, I can lose messages. This also seems to
go along
the message from Constantin about crash scenarios.
Now my questions are:
- Is quickfix known to be unstable on some platforms ( eg Sun)
- Is there a preferred platform / architecture to use it.
( OS/ single or multi-proc/ Threaded or non threaded...)
I have tried both threaded and non threaded socket initiators
with no luck.
Any feedback on what to do would be great.
An example from attaching gdb to the process:
Reading symbols from /usr/lib/libpthread.so.1...done.
Reading symbols from /usr/lib/librt.so.1...done.
Reading symbols from /usr/local/lib/libxml2.so.2...done.
Reading symbols from /usr/lib/libz.so...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/local/lib/libstdc++.so.2.10.0...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libaio.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/libthread.so.1...done.
sol-thread active.
Symbols already loaded for /usr/lib/libpthread.so.1
Symbols already loaded for /usr/lib/librt.so.1
Symbols already loaded for /usr/local/lib/libxml2.so.2
Symbols already loaded for /usr/lib/libz.so
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/local/lib/libstdc++.so.2.10.0
Symbols already loaded for /usr/lib/libm.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libaio.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libmp.so.2
Symbols already loaded for /usr/platform/SUNW,Ultra-80/lib/libc_psr.so.1
Symbols already loaded for /usr/lib/libthread.so.1
0xff0194a0 in door_restart () from /usr/lib/libc.so.1
(gdb) continue
Continuing.
[New Thread 4 (LWP 5)]
[Switching to Thread 4 (LWP 5)]
Program received signal SIGSEGV, Segmentation fault.
0x142130 in __default_alloc_template<false, 0>::allocate (__n=32)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422
422 *__my_free_list = __result -> _M_free_list_link;
(gdb) bt
#0 0x142130 in __default_alloc_template<false, 0>::allocate (__n=32)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/stl_alloc.h:422
#1 0xc5148 in
__nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0_3RepUiUi
(s=16, extra=16)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:33
#2 0xc5488 in basic_string<char, string_char_traits<char>,
__default_alloc_template<false, 0> >::Rep::create (extra=16)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:60
#3 0xc858c in basic_string<char, string_char_traits<char>,
__default_alloc_template<false, 0> >::replace (this=0xfeeff390, pos=0,
n1=0,
s=0x24c2e0 "164\0306421", n2=3)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.cc:164
#4 0x165d34 in basic_string<char, string_char_traits<char>,
__default_alloc_template<false, 0> >::assign (this=0xfeeff390, s=0x24c2e0
"164\0306421", n=3)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:218
#5 0x196d98 in basic_string<char, string_char_traits<char>,
__default_alloc_template<false, 0> >::basic_string (this=0xfeeff390,
s=0x24c2e0 "164\0306421",
n=3)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/std/bastring.h:176
#6 0x18cf30 in stringbuf::str (this=0xfeeff29c)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:77
#7 0x1a0ca0 in stringstream::str (this=0xfeeff290)
at
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/../../../../include/g++-3/sstream:330
#8 0x1a3b98 in FIX::CheckSumConvertor::convert (value=164)
at FieldConvertors.h:115
#9 0x1a1810 in FIX::CheckSumField::CheckSumField (this=0xfeeff4f0,
field=10,
data=164) at Field.h:328
#10 0x19e960 in FIX::CheckSum::CheckSum (this=0xfeeff4f0, value=164)
at Fields.h:68
#11 0x192ff8 in FIX::Message::checkSum (this=0xfeeffac8) at Message.h:292
#12 0x188a40 in FIX::Message::getString (this=0xfeeffac8) at Message.h:147
#13 0xae760 in FIX::Session::sendRaw (this=0x251b28, message=@0xfeeffac8,
msgSeqNum=0) at Session.cpp:323
#14 0xae498 in FIX::Session::send (this=0x251b28, message=@0xfeeffac8)
at Session.cpp:293
#15 0xb3950 in FIX::Session::sendToTarget (message=@0xfeeffac8)
at Session.cpp:849
#16 0x91278 in Application::enterOrderSingle (this=0xffbefc40, mapOrd={
_M_t = {<_Rb_tree_base<pair<const
basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > >,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > > >>
= {<_Rb_tree_alloc_base<pair<const
basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > >,allocator<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> > >,>>
= {_M_header = 0x26d250}, <No data fields>},
_M_node_count = 31,
_M_key_compare =
{<binary_function<basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,basic_string<char,string_char_traits<char>,__default_alloc_template<false,0> >,bool>>
= {<No data fields>}, <No data f---Type <return> to continue, or q
<return> to quit---
ields>}}}) at Application.cpp:1064
#17 0x8f3d4 in Application::onRun (this=0xffbefc40) at Application.cpp:827
#18 0xb6c5c in FIX::Initiator::startThread (p=0xffbefb58) at
Initiator.cpp:151
(gdb)
Loic Guezennec
|
98 messages has been excluded from this view by a project administrator.
