quickfix-developers Mailing List for QuickFIX (Page 192)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2026 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joerg T. <Joe...@ma...> - 2005-07-21 18:13:56
|
Barry Kaplan wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX FAQ: > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ QuickFIX Support: > http://www.quickfixengine.org/services.html Alvin Wang wrote: > >> Have you got chance to compare the performance of Quickfix/J with that of >> Quickfix Java/JNI on your application? > > No Alvin. I have never used the JNI version. Wouldn't be able to either as our > system uses spring to configure quickfix. But I believe Steve has done > preliminary comparisons against JNI, and the pure Java is much faster as expected. In this context, a comparison of pure Java and pure C++ would be interesting, too. 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: Barry K. <bk...@bl...> - 2005-07-21 18:04:05
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Alvin Wang wrote:<br> <blockquote cite="mid...@ff..." type="cite"><font face="sans-serif" size="2">Have you got chance to compare the performance of Quickfix/J with that of Quickfix Java/JNI on your application?</font> <br> </blockquote> No Alvin. I have never used the JNI version. Wouldn't be able to either as our system uses spring to configure quickfix. But I believe Steve has done preliminary comparisons against JNI, and the pure Java is much faster as expected.<br> <br> <pre>-- </pre> barry kaplan<br> <a class="moz-txt-link-abbreviated" href="mailto:bk...@bl...">bk...@bl...</a> </body> </html> |
|
From: Alvin W. <AW...@FF...> - 2005-07-21 17:58:12
|
Hi Barry,
Have you got chance to compare the performance of Quickfix/J with that of
Quickfix Java/JNI on your application?
thanks
Alvin
Barry Kaplan <bk...@bl...>
Sent by: qui...@li...
07/21/2005 01:48 PM
To: quickfix <qui...@li...>
cc:
bcc:
Subject: [Quickfix-developers] Quickfix/J - Production Use Report
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html
It was mentioned in the beta release announcment that I was using QFJ in a
production trading application. I will here describe that application and
our experiences with QFJ.
The application is a blackbox system, running an arbitrage strategy. The
strategy will place limit orders on any number of instruments. There will
always be an order at the market, but there are often orders a few price
tiers down as well. Both long and short orders are placed for an
instrument. Opening orders are placed on one exchange, closing orders on
another. The system is designed to run against hundreds of instruments
concurrently, but so far our we have not exceeded six.
The opening orders are entered at some criteria and cancled at another
criteria. In a typical trading dary, for a single instrument we will place
and cancel several thousand orders, get ten to fifty fills with a
corresponding number of closing orders and their fills. When the market is
moving, we have seen the placing and canceling of orders peak at 10/sec.
The CPU on the 1.8GHz Intel Suse box remaining less than 20% during these
peaks.
While we have not yet done any detailed performance measurements (ie,
YourKIT/JProfiler style), we track the time it takes for us to process
market events and send/cancel order and the time it takes to send a
closing order on receipt of a fill. For the case when we receive a fill
and place the closing order, the time in our system averages 10
millseconds. This time includes:
- processing of the fix message by quickfix
- internally dispatching the message via jms (using ActiveMQ)
- pushing the message thru a rete rule base (using Drools)
- sending the closing order via quickfix
In some quickfix specific load testing we performed (and this was before
some of Steve's performance improvements), we were able to push 10k
msgs/sec from on instance of QFJ ot another on the same box. So my guess
is that QFJ contribution to that 10ms time is very small.
So far, in all our production runs we have not had a single QFJ problem.
The system has worked perfectly. I will point out however, that we are
using very basic FIX capabilties. Standard 4.2, only new-orders,
execution-report, and cancel-order. Also we are using the MemoryStore
because we always close all positions prior to shutting down. But we will
in any case change to the SleepyCatStore soon.
So should you be considering the move to QFJ, I would not hestitate to
begin testing. And as Steve mentioned there are some other goodies on the
way. In addition to the JMX support, I have been working on complete
Spring integration (the application above is Spring based), the conversion
of the Netty socket layer to the Mina, and a JMS transport protocol. More
to come on this in future betas.
If anybody has further questions about our use of QFJ, or the new
features, feel free to email me, or better, post here on the list!
---
Barry Kaplan
bk...@bl...
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
**********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message. We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************
|
|
From: Joerg T. <Joe...@ma...> - 2005-07-21 17:52:05
|
Caleb Epstein wrote:
> On 7/21/05, Edde <edd...@gm...> wrote:
>
>>Another important part of this is that we're running two sessions in
>>the system, one for MarketData and one for Order handling. The problem
>>only occurs on the Order session while the communication on the
>>MarketData session works just fine. I think this rules out any
>>problems with the actual network but I'm not sure.
>
> This is all going through the same VPN tunnel? What is the bandwidth
> of that connection? Perhaps the market data session is using so much
> of your bandwidth that its "crowding out" your Order session.
Another common issues is the MTU of the physical interface. Sometimes the end-to-end MTU
cannot be discovered correctly. If the MTU is too large, the VPN connection can get stuck
on large packet size. In a terminal session you notice this, if commands with only a few
lines of output go well, but larger output as created by vi, ls of large dirs or less gets
stuck.
In summary, I do not think its QF related, but has to do with your VPN connection.
BTW, which QF version do you use?
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: Barry K. <bk...@bl...> - 2005-07-21 17:48:28
|
It was mentioned in the beta release announcment that I was using QFJ in a production trading application. I will here describe that application and our experiences with QFJ. The application is a blackbox system, running an arbitrage strategy. The strategy will place limit orders on any number of instruments. There will always be an order at the market, but there are often orders a few price tiers down as well. Both long and short orders are placed for an instrument. Opening orders are placed on one exchange, closing orders on another. The system is designed to run against hundreds of instruments concurrently, but so far our we have not exceeded six. The opening orders are entered at some criteria and cancled at another criteria. In a typical trading dary, for a single instrument we will place and cancel several thousand orders, get ten to fifty fills with a corresponding number of closing orders and their fills. When the market is moving, we have seen the placing and canceling of orders peak at 10/sec. The CPU on the 1.8GHz Intel Suse box remaining less than 20% during these peaks. While we have not yet done any detailed performance measurements (ie, YourKIT/JProfiler style), we track the time it takes for us to process market events and send/cancel order and the time it takes to send a closing order on receipt of a fill. For the case when we receive a fill and place the closing order, the time in our system averages 10 millseconds. This time includes: - processing of the fix message by quickfix - internally dispatching the message via jms (using ActiveMQ) - pushing the message thru a rete rule base (using Drools) - sending the closing order via quickfix In some quickfix specific load testing we performed (and this was before some of Steve's performance improvements), we were able to push 10k msgs/sec from on instance of QFJ ot another on the same box. So my guess is that QFJ contribution to that 10ms time is very small. So far, in all our production runs we have not had a single QFJ problem. The system has worked perfectly. I will point out however, that we are using very basic FIX capabilties. Standard 4.2, only new-orders, execution-report, and cancel-order. Also we are using the MemoryStore because we always close all positions prior to shutting down. But we will in any case change to the SleepyCatStore soon. So should you be considering the move to QFJ, I would not hestitate to begin testing. And as Steve mentioned there are some other goodies on the way. In addition to the JMX support, I have been working on complete Spring integration (the application above is Spring based), the conversion of the Netty socket layer to the Mina, and a JMS transport protocol. More to come on this in future betas. If anybody has further questions about our use of QFJ, or the new features, feel free to email me, or better, post here on the list! --- Barry Kaplan bk...@bl... |
|
From: Alvin W. <AW...@FF...> - 2005-07-21 17:38:36
|
It is Initiator. Only one session. Version is quickfix-1.9.4. OS is Windows Server 2003
SP1.
The reason we use JConsole to monitor QF is that we updated from Java
1.5.0_02 to 1.5.0_04 and then the FIX engine crash once or twice every day
(sometimes when session is up and sometime session is down). I do not know
if the crash has anything to do with threading growth. We did not have
the crash when we used Java 1.5.0_02, but I do not know what about
threading growth issue under 1.5.0_02. I also am not sure if the crash is
related to java itself or to QF.
Thanks!
Oren Miller <or...@qu...>
07/21/2005 11:53 AM
To: Alvin Wang <AW...@FF...>
cc: qui...@li..., quickfix-users list
<qui...@li...>
bcc:
Subject: Re: threading growth issue?
Please give more details on your configuration.
ThreadedSocketAcceptor? Initiator? Number of sessions... version of
QF... operating system...
--oren
On Jul 21, 2005, at 2:39 PM, Alvin Wang wrote:
>
> Hi,
>
> I configure my QF(Java/JNI) engine something like:
> StartTime=08:00:00
> EndTime=23:55:00
>
> I use JConsole (java 1.5.04) to monitor the QF engine's JVM. Before
> the endtime, there were less than 20 threads running. After that,
> the # of threads kept climbing progressively to about 2000 until
> StartTime. After QF re-create the session, the # of thread stopped
> growing.
>
> Can anyone explain to me what is going on here? It looks very
> disturbing.
>
> Thanks
> Alvin
> **********************************************************************
> This e-mail message is intended solely for the use of the
> addressee. The message may contain information that is privileged
> and confidential. Disclosure to anyone other than the intended
> recipient is prohibited. If you are not the intended recipient,
> please do not disseminate, distribute or copy this communication,
> by e-mail or otherwise. Instead, please notify us immediately by
> return e-mail (including the original message with your reply) and
> then delete and discard all copies of the message. We have taken
> precautions to minimize the risk of transmitting software viruses
> but nevertheless advise you to carry out your own virus checks on
> any attachment to this message. We accept no liability for any loss
> or damage caused by software viruses.
> **********************************************************************
|
|
From: Caleb E. <cal...@gm...> - 2005-07-21 17:27:47
|
On 7/21/05, Edde <edd...@gm...> wrote: > Another important part of this is that we're running two sessions in > the system, one for MarketData and one for Order handling. The problem > only occurs on the Order session while the communication on the > MarketData session works just fine. I think this rules out any > problems with the actual network but I'm not sure. This is all going through the same VPN tunnel? What is the bandwidth of that connection? Perhaps the market data session is using so much of your bandwidth that its "crowding out" your Order session. --=20 Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Oren M. <or...@qu...> - 2005-07-21 17:20:42
|
The library needs to be in your library path, not your include path. --oren ----- Original Message ----- From: "Martin Tanguay" <mta...@ho...> To: <qui...@li...> Cc: <mta...@ho...> Sent: Thursday, July 21, 2005 9:37 AM Subject: [Quickfix-developers] SQL support and libMySQL.lib > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > I compiled the quickfix project in order to have SQL support and got this > fatal error: > "quickfix fatal error LNK1104: cannot open file 'libMySQL.lib'" > > Here's what I did: > 1-Download and extract latest sources. > > 2-I enabled "#define HAVE_MYSQL 1" from "../src/config_windows.h". > > 3-Add additional include directories where related SQL header and library > (libMySQL.lib) can be found: > ../;C:\mysql\include;C:\mysql\lib\opt > > 4-Set configuration type to be "Dynamic library (.dll)" > > 5-Set project to be in release mode. > > 6-I find out that a "typelib.h" was missing, so I copied it from : > > http://leithal.cool-tools.co.uk/sourcedoc/mysql509/html/typelib_8h-source.html > and paste it in the same folder as mysql.h > > 7-Rebuild project quickfix and got the specified error. But the "missing" > file libMySQL.lib is in the additional included directory. > > Initially I compiled the project quickfix as a .lib library with success. > > What am I doing wrong now to get it as a dll? > > Thank you > Martin > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: Edde <edd...@gm...> - 2005-07-21 16:46:46
|
Hi Guys, During the last couple of weeks we've been experiencing problems in the FIX communication with our broker firm. Based upon the QuickFix logs of the FIX transmissons the problem is only appearing when we're sending FIX messages to the broker firm (Initiator --> Acceptor). Usually the problem is that it takes a long time for our messages to arrive at the broker firm (sometimes 30s or more) which is very frustrating when you for example want to insert an order to the market. We've been doing extensive network monitoring and we can't find any problems in the network connection at either end. We're running all FIX traffic through a VPN (SecuRemote) and we're suspecting that this might have something to do with the problem but we're not sure. Does anyone on this list have any clues to what might be the problem here? And then yesterday and again today the Acceptor actually terminated the connection since it didn't recieve any messages from our Initiator. I've put together a list of the relevant FIX messages (truncated after Tag 35). "EDDE" is the Initiator (QuickFIX) and "FIP" is the acceptor (I think they're using a self developped FIX Engine): *EDDE -> FIP 09:06:53.349 - 8=3DFIX.4.29=3D17335=3DD (InsertOrde= rSingle) *FIP -> EDDE 09:06:59.739 - 8=3DFIX.4.29=3D34435=3D8 (ExecutionR= eport) *EDDE -> FIP 09:07:23.067 - 8=3DFIX.4.29=3D5135=3D0 (Heartbeat) *EDDE -> FIP 09:07:24.270 - 8=3DFIX.4.29=3D18835=3DD (InsertOrde= rSingle) *EDDE -> FIP 09:07:29.333 - 8=3DFIX.4.29=3D18835=3DD (InsertOrde= rSingle) *FIP -> EDDE 09:07:30.708 - 8=3DFIX.4.29=3D5235=3D0 (Heartbeat) *EDDE -> FIP 09:07:37.677 - 8=3DFIX.4.29=3D17935=3DD (InsertOrde= rSingle) *EDDE -> FIP 09:07:42.677 - 8=3DFIX.4.29=3D17735=3DD (InsertOrde= rSingle) *EDDE -> FIP 09:07:47.677 - 8=3DFIX.4.29=3D17735=3DD (InsertOrde= rSingle) *FIP -> EDDE 09:08:00.708 - 8=3DFIX.4.2=019=3D78=0135=3D1=0134=3D113=0149=3DFIP=0152=3D20050719-07:07:5= 9.001=0156=3DEDDE=01112=3D20050719-07:07:59.000=0110=3D057=01 (TestRequest) *EDDE -> FIP 09:08:00.708 - 8=3DFIX.4.2=019=3D77=0135=3D0=0134=3D96=0149=3DEDDE=0152=3D20050719-07:08:0= 0.708=0156=3DFIP=01112=3D20050719-07:07:59.000=0110=3D018=01 (Response) *EDDE -> FIP 09:08:00.958 - 8=3DFIX.4.29=3D19035=3DD (InsertOrde= rSingle) *EDDE -> FIP 09:08:05.958 - 8=3DFIX.4.29=3D17635=3DD (InsertOrde= rSingle) *EDDE -> FIP 09:08:18.005 - 8=3DFIX.4.29=3D17635=3DD (InsertOrde= rSingle) *FIP -> EDDE 09:08:30.708 - 8=3DFIX.4.2=019=3D109=0135=3D5=0134=3D114=0149=3DFIP=0152=3D20050719-07:08:= 29.001=0156=3DEDDE=0158=3DDidn't receive message for a long time. Disconnected.=0110=3D005=01 (Logout) *EDDE -> FIP 09:08:30.708 - 8=3DFIX.4.29=3D5235=3D5 (Logout) *EDDE -> FIP 09:08:49.817 - 8=3DFIX.4.29=3D6435=3DA (Logon failu= re) *EDDE -> FIP 09:09:09.145 - 8=3DFIX.4.29=3D6435=3DA (Logon) *FIP -> EDDE 09:09:10.474 - 8=3DFIX.4.29=3D6435=3DA (Logon) After this we're doing the proper resends off messages etc. Based on the logs the communication didn't work in the EDDE --> FIP direction between 09:06:55 and 09:09:10 which is just over 2 mins. The point is that the communication works flawlessly in one direction (FIP --> EDDE) while all the messages going the other direction just doesn't reach the target. From what I understand the FIX protocol doesn't acknowledge message delivery so this is ok. What I'm trying to figure out is where these messages go? Shouldn't there be a socket exception or something if the message can't be delivered to the target socket? Another important part of this is that we're running two sessions in the system, one for MarketData and one for Order handling. The problem only occurs on the Order session while the communication on the MarketData session works just fine. I think this rules out any problems with the actual network but I'm not sure. Our system is running on Windows XP using a Java application and the QuickFIX/JNI solution (1.9.4). We're using VPN (SecuRemote) to assure a safe connection with our broker. If anyone have any ideas what may cause these problems please let me know. Thanks, /Eddie Ps. I'm very excited about the pure Java implementation of QuickFIX. Great work!!! |
|
From: Oren M. <or...@qu...> - 2005-07-21 15:53:45
|
Please give more details on your configuration. ThreadedSocketAcceptor? Initiator? Number of sessions... version of QF... operating system... --oren On Jul 21, 2005, at 2:39 PM, Alvin Wang wrote: > > Hi, > > I configure my QF(Java/JNI) engine something like: > StartTime=08:00:00 > EndTime=23:55:00 > > I use JConsole (java 1.5.04) to monitor the QF engine's JVM. Before > the endtime, there were less than 20 threads running. After that, > the # of threads kept climbing progressively to about 2000 until > StartTime. After QF re-create the session, the # of thread stopped > growing. > > Can anyone explain to me what is going on here? It looks very > disturbing. > > Thanks > Alvin > ********************************************************************** > This e-mail message is intended solely for the use of the > addressee. The message may contain information that is privileged > and confidential. Disclosure to anyone other than the intended > recipient is prohibited. If you are not the intended recipient, > please do not disseminate, distribute or copy this communication, > by e-mail or otherwise. Instead, please notify us immediately by > return e-mail (including the original message with your reply) and > then delete and discard all copies of the message. We have taken > precautions to minimize the risk of transmitting software viruses > but nevertheless advise you to carry out your own virus checks on > any attachment to this message. We accept no liability for any loss > or damage caused by software viruses. > ********************************************************************** |
|
From: Alvin W. <AW...@FF...> - 2005-07-21 14:41:26
|
Hi,
I configure my QF(Java/JNI) engine something like:
StartTime=08:00:00
EndTime=23:55:00
I use JConsole (java 1.5.04) to monitor the QF engine's JVM. Before the
endtime, there were less than 20 threads running. After that, the # of
threads kept climbing progressively to about 2000 until StartTime. After
QF re-create the session, the # of thread stopped growing.
Can anyone explain to me what is going on here? It looks very disturbing.
Thanks
Alvin
**********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message. We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************
|
|
From: Martin T. <mta...@ho...> - 2005-07-21 14:38:07
|
Hi,
I compiled the quickfix project in order to have SQL support and got this
fatal error:
"quickfix fatal error LNK1104: cannot open file 'libMySQL.lib'"
Here's what I did:
1-Download and extract latest sources.
2-I enabled "#define HAVE_MYSQL 1" from "../src/config_windows.h".
3-Add additional include directories where related SQL header and library
(libMySQL.lib) can be found:
../;C:\mysql\include;C:\mysql\lib\opt
4-Set configuration type to be "Dynamic library (.dll)"
5-Set project to be in release mode.
6-I find out that a "typelib.h" was missing, so I copied it from :
http://leithal.cool-tools.co.uk/sourcedoc/mysql509/html/typelib_8h-source.html
and paste it in the same folder as mysql.h
7-Rebuild project quickfix and got the specified error. But the "missing"
file libMySQL.lib is in the additional included directory.
Initially I compiled the project quickfix as a .lib library with success.
What am I doing wrong now to get it as a dll?
Thank you
Martin
|
|
From: David V. <dvi...@sm...> - 2005-07-21 07:49:57
|
Hi Joerg, It works very well with JBoss now. Steve and I already started working = on adding JMX capabilities to QuickFix/J. We have a prototype working very = well with JBoss and MX4J by instrumenting Sessions. If you are interested, = let us know. As far as Messages are Serializable, you can also use them as parameters of your EJBs. We experimented that and it's very useful. What kind of integration do you want to do with JBoss ? I'm very = interested in exchanging ideas about it. Regards David -----Message d'origine----- De=A0: qui...@li... [mailto:qui...@li...] De la part de = Joerg Thoennes Envoy=E9=A0: jeudi 21 juillet 2005 08:11 =C0=A0: Steve Bate Cc=A0: qui...@li...; qui...@li... Objet=A0: Re: [Quickfix-developers] QuickFIX/J Beta 1 Available QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX FAQ: = http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ QuickFIX Support: http://www.quickfixengine.org/services.html Hi Steve, > I am pleased to announce the first beta release of QuickFIX/J, a pure > Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is > identical to the QuickFIX JNI Java API. It should be possible to > simply redefine the Java classpath to start using QuickFIX/J if you've > been using the JNI version. Congratulations! Great job, well done. Thank you, Steve, Oren, Barry, = David and Laurent! Personally, I was waiting a long time for a pure Java port for easier = J2EE integration,=20 but could not offer the time to do it. Now we can proceed to integrate QuickFIX/J into JBoss. We have already started using QuickFIX/J for development (from CVS) and = it works like a=20 charm. (Otherwise, we are happy to use the bugtracker ;-) Eventually, we also will use it for production. But first there will be = a longer testing=20 period. I would love to hear Barry Kaplans experiences in QuickFIX/J's = usage for real trading. Looking forward to the first major release... Cheers, J=F6rg --=20 Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. = http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Joerg T. <Joe...@ma...> - 2005-07-21 06:11:17
|
Hi Steve,
> I am pleased to announce the first beta release of QuickFIX/J, a pure
> Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is
> identical to the QuickFIX JNI Java API. It should be possible to
> simply redefine the Java classpath to start using QuickFIX/J if you've
> been using the JNI version.
Congratulations! Great job, well done. Thank you, Steve, Oren, Barry, David and Laurent!
Personally, I was waiting a long time for a pure Java port for easier J2EE integration,
but could not offer the time to do it. Now we can proceed to integrate QuickFIX/J into JBoss.
We have already started using QuickFIX/J for development (from CVS) and it works like a
charm. (Otherwise, we are happy to use the bugtracker ;-)
Eventually, we also will use it for production. But first there will be a longer testing
period. I would love to hear Barry Kaplans experiences in QuickFIX/J's usage for real trading.
Looking forward to the first major release...
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: Steve B. <st...@qu...> - 2005-07-21 04:00:38
|
I am pleased to announce the first beta release of QuickFIX/J, a pure Java port of the QuickFIX C++ FIX engine. The QuickFIX/J API is identical to the QuickFIX JNI Java API. It should be possible to simply redefine the Java classpath to start using QuickFIX/J if you've been using the JNI version. The primary focus of this version was porting the C++ and Ruby code to Java. However, there are a few additional features. For example... * QuickFIX/J messages are serializable * General JDBC log and store support * Jakarta Commons Logging support (JDK, Log4J) * Javadoc documentation * A few new configurations options We are also seeing better performance with QuickFIX/J compared to the JNI implementation. Depending on the test, we are seeing between 3-10x speed improvement. QuickFIX/J is passing the same acceptance tests as the C++ implementation and is also passing numerous unit tests. The code is stable but we are expecting minor issues with compatibility, bugs, and so on once developers start using it. Please follow the guidelines recently suggested by Joerg Thoennes for reporting bugs and issues using the QuickFIX bug tracker. The message containing those guidelines is... http://sourceforge.net/mailarchive/message.php?msg_id=12260171 Several people have provided valuable assistance to the QuickFIX/J effort. David Vincent and Laurent Danesi from Smart Trade Technologies have provided coding and testing support and have set up a Cruise Control continuous integration server for doing automated builds and test report generation. Barry Kaplan has been using the engine for real trading and has provided early feedback on bugs and other issues. These developers are also involved in some very interesting features for future versions of QuickFIX/J. We'll describe those in future messages. Oren Miller has provided project management assistance and has patiently answered our numerous questions about the C++ implementation. We are hoping that the Java QuickFIX users will help us improve the quality of the QuickFIX/J implementation by trying the software and reporting bugs or other issues. If you'd like to get involved as a developer, send me a note and let me know how you'd like to participate. I'm also interested in hearing from people who are experts on the FIX protocol or applications of FIX and who would be willing to consult with the development team when we have questions. The code is available as a binary or source package from the QuickFIX SourceForge file download area. http://sourceforge.net/project/showfiles.php?group_id=37535 Steve Bate |
|
From: Nicholas M. <nic...@ch...> - 2005-07-20 16:05:37
|
Hi all,
It is my understanding that in order to use repeated groups I
must use a datadictionary (I suppose I could turn off all validation and
parse each message string myself - avoiding quickfix's multiple tag error..
but that seams like a headache). So, assuming I need a datadictionary - is
it possible to stream the dictionary to the quickfix SessionSettings without
the external file (create it on the fly in my app and pump it the session).
Maybe something a little more elegant than having the app write the file to
disk each execution; pointing the session settings to the disk. This is in
an attempt to avoid passing an external datadictionary file around with all
our installations.
Appreciate your time,
Nick Murdock
Chicago Trading Company
|
|
From: Joerg T. <Joe...@ma...> - 2005-07-20 14:35:44
|
Tarandeep Singh wrote:
> I am trying to compile quickfix-1.10.2 on AIX 5.1 with compiler XL C++
> v7.0.
Hi,
please tell us if you finally succeed to compile QuickFIX. I hope Orens response fixes
your issue.
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: Steve B. <st...@te...> - 2005-07-19 18:09:57
|
Hi, This is actually a question I wanted to ask about the C++ code. It appears that the set() function in MySQLStore.cpp will do an update if the insert fails. Are there situations where we expect a primary key violation and would want to overwrite the existing row or is that logic there for some other reason? Steve > -----Original Message----- > From: qui...@li... [mailto:quickfix- > dev...@li...] On Behalf Of Barry Kaplan > Sent: Tuesday, July 19, 2005 12:02 AM > To: quickfix > Subject: [Quickfix-developers] [qfj] JdbcStore.set() - Why INSERT of > UPDATE fails? > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > This method catches SQLException on the insert and then attempts an > update. There is a comment in this class asking why this is so. Is it > because this method will get called with exisitng sequence numbers > during a resend? > -- > barry kaplan > gr...@me... > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Oren M. <or...@qu...> - 2005-07-19 14:17:40
|
Someone reported the same issue with gcc 4.0. This patch should fix it: http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/ test/MessagesTestCase.cpp?r1=1.33&r2=1.34 --oren On Jul 19, 2005, at 2:28 AM, Tarandeep Singh wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ > html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php? > QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > I am trying to compile quickfix-1.10.2 on AIX 5.1 with compiler XL C > ++ v7.0. But I am receiving following error: > ////////////////////////////////////////////////////////////////////// > ////////////////////////////////////////////////////////////////////// > ////////////////////////////////////////// > $ make > make all-recursive > Making all in src > Making all in C++ > Making all in test > source='FieldBaseTestCase.cpp' object='FieldBaseTestCase.lo' > libtool=yes depfile='.deps/FieldBaseTestCase.Plo' > tmpdepfile='.deps/FieldBaseTestCase.TPlo' depmode=aix /bin/ > sh ./../../depcomp /bin/sh ../../../libtool --mode=compile xlC_r . > -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -I/home/tuli/ > test/library/libxml2/include/libxml2 -O0 -g -c -o > FieldBaseTestCase.lo `test -f 'FieldBaseTestCase.cpp' || echo > './'`FieldBaseTestCase.cpp > mkdir .libs > xlC_r -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -I/home/tuli/test/ > library/libxml2/include/libxml2 -O0 -g -c -M FieldBaseTestCase.cpp > -DPIC -o .libs/FieldBaseTestCase.o > "FieldBaseTestCase.cpp", line 34.5: 1540-2412 (W) A typeid is > present, but the correct RTTI option is not specified. > source='FieldConvertorsTestCase.cpp' > object='FieldConvertorsTestCase.lo' libtool=yes depfile='.deps/ > FieldConvertorsTestCase.Plo' tmpdepfile='.deps/ > FieldConvertorsTestCase.TPlo' depmode=aix /bin/sh ./../../ > depcomp /bin/sh ../../../libtool --mode=compile xlC_r . > -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -I/home/tuli/ > test/library/libxml2/include/libxml2 -O0 -g -c -o > FieldConvertorsTestCase.lo `test -f 'FieldConvertorsTestCase.cpp' > || echo './'`FieldConvertorsTestCase.cpp > xlC_r -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -I/home/tuli/test/ > library/libxml2/include/libxml2 -O0 -g -c -M > FieldConvertorsTestCase.cpp -DPIC -o .libs/FieldConvertorsTestCase.o > "FieldConvertorsTestCase.cpp", line 54.3: 1540-2412 (W) A typeid is > present, but the correct RTTI option is not specified. > source='MessagesTestCase.cpp' object='MessagesTestCase.lo' > libtool=yes depfile='.deps/MessagesTestCase.Plo' tmpdepfile='.deps/ > MessagesTestCase.TPlo' depmode=aix /bin/sh ./../../depcomp /bin/ > sh ../../../libtool --mode=compile xlC_r . > -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -I/home/tuli/ > test/library/libxml2/include/libxml2 -O0 -g -c -o > MessagesTestCase.lo `test -f 'MessagesTestCase.cpp' || echo > './'`MessagesTestCase.cpp > xlC_r -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g -I/home/tuli/test/ > library/libxml2/include/libxml2 -O0 -g -c -M MessagesTestCase.cpp - > DPIC -o .libs/MessagesTestCase.o > "../DataDictionary.h", line 272.31: 1540-0040 (S) The text "&" is > unexpected. "Message" may be undeclared or ambiguous. > "MessagesTestCase.cpp", line 403.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 420.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 429.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 437.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 446.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 455.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 466.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 476.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 488.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 497.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 508.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 516.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 525.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 539.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 559.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 579.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 609.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 622.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 640.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 657.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 680.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 695.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 713.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 727.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 746.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 758.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 773.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 807.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 880.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 897.6: 1540-0080 (W) Template > specializations must be prefixed with "template<>". > "MessagesTestCase.cpp", line 47.5: 1540-2412 (W) A typeid is > present, but the correct RTTI option is not specified. > make: 1254-004 The error code from the last command is 1. > > Stop. > make: 1254-004 The error code from the last command is 1. > > Stop. > make: 1254-004 The error code from the last command is 1. > > Stop. > make: 1254-004 The error code from the last command is 1. > > Stop. > make: 1254-004 The error code from the last command is 2. > > Stop. > ////////////////////////////////////////////////////////////////////// > ////////////////////////////////////////////////////////////////////// > ////////////////////////////////////////// > Does anybody know why its happening? and How do I solve this? > > Regards, > Tarandeep Singh > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > |
|
From: Tarandeep S. <tar...@ef...> - 2005-07-19 07:29:38
|
Hi,
I am trying to compile quickfix-1.10.2 on AIX 5.1 with compiler XL C++
v7.0. But I am receiving following error:
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
$ make
make all-recursive
Making all in src
Making all in C++
Making all in test
source='FieldBaseTestCase.cpp' object='FieldBaseTestCase.lo'
libtool=yes depfile='.deps/FieldBaseTestCase.Plo'
tmpdepfile='.deps/FieldBaseTestCase.TPlo' depmode=aix /bin/sh
../../../depcomp /bin/sh ../../../libtool --mode=compile xlC_r
-DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g
-I/home/tuli/test/library/libxml2/include/libxml2 -O0 -g -c -o
FieldBaseTestCase.lo `test -f 'FieldBaseTestCase.cpp' || echo
'./'`FieldBaseTestCase.cpp
mkdir .libs
xlC_r -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g
-I/home/tuli/test/library/libxml2/include/libxml2 -O0 -g -c -M
FieldBaseTestCase.cpp -DPIC -o .libs/FieldBaseTestCase.o
"FieldBaseTestCase.cpp", line 34.5: 1540-2412 (W) A typeid is present,
but the correct RTTI option is not specified.
source='FieldConvertorsTestCase.cpp'
object='FieldConvertorsTestCase.lo' libtool=yes
depfile='.deps/FieldConvertorsTestCase.Plo'
tmpdepfile='.deps/FieldConvertorsTestCase.TPlo' depmode=aix /bin/sh
../../../depcomp /bin/sh ../../../libtool --mode=compile xlC_r
-DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g
-I/home/tuli/test/library/libxml2/include/libxml2 -O0 -g -c -o
FieldConvertorsTestCase.lo `test -f 'FieldConvertorsTestCase.cpp' ||
echo './'`FieldConvertorsTestCase.cpp
xlC_r -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g
-I/home/tuli/test/library/libxml2/include/libxml2 -O0 -g -c -M
FieldConvertorsTestCase.cpp -DPIC -o .libs/FieldConvertorsTestCase.o
"FieldConvertorsTestCase.cpp", line 54.3: 1540-2412 (W) A typeid is
present, but the correct RTTI option is not specified.
source='MessagesTestCase.cpp' object='MessagesTestCase.lo'
libtool=yes depfile='.deps/MessagesTestCase.Plo'
tmpdepfile='.deps/MessagesTestCase.TPlo' depmode=aix /bin/sh
../../../depcomp /bin/sh ../../../libtool --mode=compile xlC_r
-DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g
-I/home/tuli/test/library/libxml2/include/libxml2 -O0 -g -c -o
MessagesTestCase.lo `test -f 'MessagesTestCase.cpp' || echo
'./'`MessagesTestCase.cpp
xlC_r -DHAVE_CONFIG_H -I. -I. -I../../.. -I.. -g
-I/home/tuli/test/library/libxml2/include/libxml2 -O0 -g -c -M
MessagesTestCase.cpp -DPIC -o .libs/MessagesTestCase.o
"../DataDictionary.h", line 272.31: 1540-0040 (S) The text "&" is
unexpected. "Message" may be undeclared or ambiguous.
"MessagesTestCase.cpp", line 403.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 420.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 429.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 437.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 446.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 455.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 466.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 476.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 488.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 497.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 508.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 516.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 525.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 539.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 559.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 579.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 609.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 622.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 640.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 657.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 680.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 695.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 713.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 727.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 746.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 758.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 773.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 807.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 880.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 897.6: 1540-0080 (W) Template
specializations must be prefixed with "template<>".
"MessagesTestCase.cpp", line 47.5: 1540-2412 (W) A typeid is present,
but the correct RTTI option is not specified.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 1.
Stop.
make: 1254-004 The error code from the last command is 2.
Stop.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Does anybody know why its happening? and How do I solve this?
Regards,
Tarandeep Singh
|
|
From: Barry K. <gr...@me...> - 2005-07-19 05:01:30
|
This method catches SQLException on the insert and then attempts an update. There is a comment in this class asking why this is so. Is it because this method will get called with exisitng sequence numbers during a resend? -- barry kaplan gr...@me... |
|
From: Barry K. <bk...@me...> - 2005-07-19 05:00:30
|
This method catches SQLException on the insert and then attempts an update. There is a comment in this class asking why this is so. Is it because this method will get called with exisitng sequence numbers during a resend? -- barry kaplan bk...@me... |
|
From: Oren M. <or...@qu...> - 2005-07-15 17:14:29
|
Well, if you dig down into the C++ layer, in the FieldMap class, you =20 will notice that a FieldMap constructor takes a message_order =20 object. Now, if you look in MessageSorters.h, you will find the =20 message_order object which has 4 modes. header: Makes sure that the BeginString, BodyLength, and MsgType are =20 the first three fields. Everything else in ascending numerical order. trailer: Makes sure the CheckSum field is last. Everything else in =20 ascending numerical order. normal: Sorted in ascending numerical order, used for message body's group: Sorted in the order based on provided list. Why is it like this? Well sorting things in ascending order is just =20 the simplest fastest way to sort fields and complies with the spec. =20 The group order was introduced because the spec explicitly states =20 that repeating groups must be in a specific order. Basically to accomplish what you need would require some new =20 functionality. I think it would require the implementation of a data =20= dictionary sorting mode. --oren On Jul 15, 2005, at 11:27 AM, Joerg Thoennes wrote: > Hi Oren, > > >> Which fields need to be ordered? The custom tags in the header =20 >> and the trailer? The entire message? >> > > To be more precise: EMX adds extra custom fields to both the header =20= > and trailer, and of course to the body. > > We generated the new QF classes using the XML scripts, but the =20 > order seems to be different from what EMX expects. > > So our questions is: > > How can we control the order of tags in > > (a) header > (b) body > (c) trailer > > My guess is that the DD order controls at least the body order, but =20= > I am not sure about header and trailer. After some digging of the =20 > source code some advise from you would be very helpful. > > Thanks, J=F6rg > > --=20 > Joerg Thoennes > http://macd.com > Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH > Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen > > |
|
From: Joerg T. <Joe...@ma...> - 2005-07-15 16:28:13
|
Hi Oren,
> Which fields need to be ordered? The custom tags in the header and the
> trailer? The entire message?
To be more precise: EMX adds extra custom fields to both the header and trailer, and of
course to the body.
We generated the new QF classes using the XML scripts, but the order seems to be different
from what EMX expects.
So our questions is:
How can we control the order of tags in
(a) header
(b) body
(c) trailer
My guess is that the DD order controls at least the body order, but I am not sure about
header and trailer. After some digging of the source code some advise from you would be
very helpful.
Thanks, 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: Oren M. <or...@qu...> - 2005-07-15 16:17:37
|
Which fields need to be ordered? The custom tags in the header and the trailer? The entire message? --oren On Jul 15, 2005, at 5:30 AM, Reiner Nix wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ > html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php? > QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > Hi, > > to connect to EMX, I have to use some custom messages and some > extra custom > tags in message header and trailer. > The field order must follow an explicitly defined order different > from the > default order by QuickFix. > > How can I specify this field order? > Is this managed using the XML specification files? > > > Thanks > Reiner Nix > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > 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.
