quickfix-users — QuickFIX user support

Re: [Quickfix-users] [Quickfix-developers] Problem during building quickfix

[Oren M. <or...@qu...>]

Did you check out the source from svn?  If so, then yes, you must run  
bootstrap before running configure.  If downloading a release  
package, you shouldn't have to do this.

--oren

On Feb 20, 2008, at 9:45 PM, Mayank Jain Nawal wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I have solved the problem. Before configure I run the ./bootstrap  
> command.
> Now I am trying to use quickfix to generate fix transactions. Lets  
> see I
> could be able to find out some good doc for that.
>
> Thanks Aaron for your kind concern.
>
>
> -- 
> _____________________________________________________________
> Mayank Jain Nawal             NIKSUN.
> ma...@in...          http://www.niksun.com
> Tel: +91 124 231 6012         SCO 16 Sector 14
> Mob: +91 981 839 0836         Gurgaon Haryana 122001 India
> _____________________________________________________________
>
>
>
> Good Times wrote:
>> what directory were you in when you executed the command
>>
>> why don't you post a little more from the terminal
>>
>> aaron
>>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-users] How to run this application for traffic generation

[Mayank J. N. <ma...@in...>]

Hi,

I am quite new to the quickfixengine. Can anybody assist me in running 
this application. I want to use quickfixengine as a traffic generator on 
my FreeBSD machine. Is there any document available on this? I am not 
able to figure out what I need to do to run this application. I have 
installed this on my machine. I think I need to run run_tradeclient and 
./run_ordermatch. I have installed this application on 2 of the machines 
but I am not able to find out how to give the ip address and the port 
number on which it should listen to. Any help would be appreciated .

-- 
_____________________________________________________________
Mayank Jain Nawal             NIKSUN.
ma...@in...          http://www.niksun.com
Tel: +91 124 231 6012         SCO 16 Sector 14
Mob: +91 981 839 0836         Gurgaon Haryana 122001 India
_____________________________________________________________

Re: [Quickfix-users] Problem during building quickfix

[Mayank J. N. <ma...@in...>]

I have solved the problem. Before configure I run the ./bootstrap command.
Now I am trying to use quickfix to generate fix transactions. Lets see I 
could be able to find out some good doc for that.

Thanks Aaron for your kind concern.


-- 
_____________________________________________________________
Mayank Jain Nawal             NIKSUN.
ma...@in...          http://www.niksun.com
Tel: +91 124 231 6012         SCO 16 Sector 14
Mob: +91 981 839 0836         Gurgaon Haryana 122001 India
_____________________________________________________________



Good Times wrote:
> what directory were you in when you executed the command
>
> why don't you post a little more from the terminal
>
> aaron
>   

Re: [Quickfix-users] Problem during building quickfix

[Good T. <aa...@rd...>]

what directory were you in when you executed the command

why don't you post a little more from the terminal

aaron
-- 
Ripley: I say we take off and nuke the entire site from orbit. It's the only way to be sure.
Hudson: Fuckin' A...
	-Aliens

On Wed, Feb 20, 2008 at 11:26:12AM +0530, Mayank Jain Nawal wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Hi,
> 
> 
> I have downloaded source code of quickfix on my FreeBSD. I am not able 
> to build the source code on my machine.
> 
> Steps performed
> 
> 1) Downloaded the source code using command
> 
> svn co https://quickfix.svn.sourceforge.net/svnroot/quickfix/trunk/quickfix
> 
> 2) ./configure
> 
> Error I got
> 
>  configure: error: cannot find install-sh or install.sh in config "."/config
> 
> 
> 3)autoconf
> no message
> 
> 4) make
> make: no target to make.
> 
> Can you please let me know the steps for building the quickfix.
> 
> -- 
> _____________________________________________________________
> Mayank Jain Nawal             NIKSUN.
> ma...@in...          http://www.niksun.com
> Tel: +91 124 231 6012         SCO 16 Sector 14
> Mob: +91 981 839 0836         Gurgaon Haryana 122001 India
> _____________________________________________________________
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users

[Quickfix-users] Issue on message.get

[Francesco P. <fpi...@gm...>]

Hi everybody,
first of all, thank you for your great job.
I'm using quickfix to build a simple application and I'm experiencing this
issue:

when an execution report arrives, I crack the message and I do this: *

FIX::LastQty aLastQty;
message.get(**aLastQty);

*if this field is not in the message, I receive this exception:
Conditionally Required Field Missing (32).
How can I avoid this? Can I test in any way the result of get method?

Hope I was clear, thank you for your attention.
Francesco

[Quickfix-users] Problem during building quickfix

[Mayank J. N. <ma...@in...>]

Hi,


I have downloaded source code of quickfix on my FreeBSD. I am not able 
to build the source code on my machine.

Steps performed

1) Downloaded the source code using command

svn co https://quickfix.svn.sourceforge.net/svnroot/quickfix/trunk/quickfix

2) ./configure

Error I got

 configure: error: cannot find install-sh or install.sh in config "."/config


3)autoconf
no message

4) make
make: no target to make.

Can you please let me know the steps for building the quickfix.

-- 
_____________________________________________________________
Mayank Jain Nawal             NIKSUN.
ma...@in...          http://www.niksun.com
Tel: +91 124 231 6012         SCO 16 Sector 14
Mob: +91 981 839 0836         Gurgaon Haryana 122001 India
_____________________________________________________________

Re: [Quickfix-users] Two more questions about QuickFix

[Dan G. <dua...@ya...>]

John,
thanks. here we did a tcp dump and found this  - two orders were sent consecutively back to back and the 2nd order is 6mill seconds after 1st one, on socket level. If that holds, 160 orders/s is the best we can do. we certainly think this is not acceptable. we wonder 
1. if there is any way to improve;
2. if this is what others see;
3. if there is any configuration error on our part.

thanks,
Dan

----- Original Message ----
From: John Haldi <jh...@ca...>
To: Dan Guo <dua...@ya...>
Sent: Friday, February 8, 2008 1:52:04 PM
Subject: RE: [Quickfix-users] Two more questions about QuickFix


Dan,

1.  On sending, you should log when you are actually calling the SendToTarget method and determine how long the delay is between calls within your code.  Once you call SendToTarget, quickfix will take over and manage the socket connection to the broker.  Depending on your line bandwidth and latency, as well as their ability to process things, this could be a bottleneck.  If however you are seeing delays between successive calls to SendToTarget, the delay is in your code.  QuickFix will manage any line delays by handling its own queue internally, so it won't cause any noticeable delays between successive calls to SendToTarget.  You could also consider logging a millisecond timestamp both before you call SendToTarget and immediately after the method returns, in order to get a sense of the time quickfix is taking to release your thread.

2.  When your broker is sending messages to you, quickfix ought to handle any delays in your code by transparently creating and managing an inbound queue on your side.  You clear the queue by handling each onMessage event.  If your code is the bottleneck, you won't react to the onMessage event until your code has finished processing the previous message.  One way to get around this problem (if that is indeed what you are experiencing) is to create your own managed queue.  Essentially you limit your code in the onMessage event to grabbing the message and putting it onto your own managed queue.  Then, on a separate thread, you have a queue processor which clears the queue.  This gives you the flexibility to easily monitor any queue length in your managed queue.

If however your broker is in fact seeing a bottleneck on their side in their ability to send you messages, it is likely a problem with your network connection to the broker.  You might want to investigate the TCP traffic and determine if there is a problem between you and the broker.  Incorrect net card drivers or router configuration can cause the TCP protocol to progressively reduce the frame size in an attempt to determine an optimal sending packet size.  If this shrinks enough, it will manifest itself in seemingly slow network connectivity as the protocol takes each of your messages and breaks them into tiny chunks and then has to reassemble them on the other side before passing them up to your application.

If it helps you to get a benchmark for what to expect, on our systems we typically see about a 1,000 max message per second throughput using the single threaded socket initiator and socket acceptor object, configured for file (not DB) logging and with the .body files turned on.  This is on a system using high speed dedicated lines between us and the exchanges/brokers in question.  We have not gone further in our attempts to maximize throughput yet, as we only do a few hundred thousand orders per day.  On a 4xCPU, 4GB RAM server running right now, I see CPU load at about 2% on our engine and its running about 20 messages per second right now.

Hope this helps,

    John

-----Original Message-----
From: qui...@li... [mailto:qui...@li...] On Behalf Of Dan Guo
Sent: Friday, February 08, 2008 1:03 PM
To: qui...@li...
Subject: [Quickfix-users] Two more questions about QuickFix

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Everyone!

we notice two issues and want to hear whether anyone knows what is going on.

1. when i sent FIX msgs at higher rate (10 msg per second), there seems a longer latency for the msg to hit market.

  i have strong suspecion QuickFix responsible for the longer latency, as i isolated other segments' contributions to the overall latency.

  can anyone comment on this?

2. our broker's network engineers noticed there is TCP back-pressure alert on their site. It basically means the FIX messages got queued on our broker's side. Either because our network connection is not adequate or (and) our QuickFix code cannot process them fast enough.

  did anyone in this list encounter the similiar issue? any comments?

Thank you in advance.

Dan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.21/1266 - Release Date: 2/8/2008 10:06 AM


No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.21/1266 - Release Date: 2/8/2008 10:06 AM

[Quickfix-users] FIX session creation/shutdown tracking

[Drazen D. <de...@se...>]

Hi,
 
I am a bit puzzled that QuickFix does not have the mechanism to signal the creation/shutdown of the FIX session. Alternatively there is something, but I haven't figured it out.

IIUC, onCreate is called every time the app starts up, for each of the *QuickFix* sessions configured in the settings file. At the same time, for each of the QuickFix sessions, I am allowed to configure the start/end time, so the QuickFix engine does know when and how to create a new FIX session. By the way, it doesn't help that two different things are called sessions :(

Anyway, since I am using my own MessageStore implementation, am I right assuming that QuickFix will create a new FIX session some time after it calls _reset_ method on the MessageStore? It appears to me that FIX session creation/shutdown warrants its own onSessionStart/onSessionEnd callbacks, much like onLogon/onLogout are done (even though one can and in fact I do use fromAdmin to check if the message is Logon and then act on it, thus theoretically onLogon/onLogout isn't really needed).

Is it preferable to manually track the FIX session via onLogon/onLogout + a bit more code to save the date/time and deduce if I am in a new FIX session?

Which mechanism would you suggest?

Thanks in advance,

Drazen

Re: [Quickfix-users] how can i NOT generate a bigFIX.4.2-xxxxx.body file?

[<urb...@sb...>]

Dan,

As Oren pointed out, managing the message callback in Queue can be 
substantially beneficial.  As well, you want to be absolutely certain to 
dispose properly in all related functions, which in the end also makes 
substantial differences.  Switching to memory file mode for message store, 
may be reducing your cpu and wait demands for file writing some, but at a 
price of memory consumption and loss of messages on an interruption or power 
down.

In our experience, we have found that setting flags to be able to start with 
or without messaging / modes and then managing file maintenance on disk at 
rollover time, gave us the best balance, once we got disposals and other 
proper handling working.

Are you making proper use of caching to your hardrive with DMA and other 
drive write benefits enabled?

It sounds like your issues may be related to either not having trimmed down 
your operating system to be lean enough to act as a dedicated tool, or that 
your TCP stack may have many other activities happening that are reducing 
TCP performance, so shutdown any unwanted services, especially those using 
TCP without need for them.  10 msg / second is a "sleeper" compared to what 
QF can do when coded tightly and setup in a properly prepared environment to 
run hard, even under C# NET. ;)

Even if all you do is receive data, the day may come when you move on to 
forwarding or relay operation and so it's best to not only prepare well, but 
labor the system intentionally in those areas so when it is time to use 
them, they don't punish your performance unrealistically.  Iow design to the 
worst case demand, in the best case possible environment.


Mike


----- Original Message ----- 
From: "Dan Guo" <dua...@ya...>
To: "Djalma Rosa dos Santos Filho" <drs...@gm...>
Cc: <qui...@li...>
Sent: Friday, February 08, 2008 1:16 PM
Subject: Re: [Quickfix-users] how can i NOT generate a bigFIX.4.2-xxxxx.body 
file?


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Djalma,
> thank you. that is it!
>
> i guess since i am a client (not a brokerage), i do not need 
> re-transmission feature. i would expect my broker DO RETRAN on my behalf 
> (if i miss a msg and ask them to retrans from an older sequence #), not 
> the other around.
>
> Is my understanding correct?
>
> Dan
>
> ----- Original Message ----
> From: Djalma Rosa dos Santos Filho <drs...@gm...>
> To: "Qui...@li..." 
> <qui...@li...>
> Sent: Friday, February 8, 2008 1:10:28 PM
> Subject: Re: [Quickfix-users] how can i NOT generate a big 
> FIX.4.2-xxxxx.body file?
>
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
>
> -----Inline Attachment Follows-----
>
>
> The .body file is one of the files used by the FileStore, it is useful 
> only if you want the engine to be able to respond to resend requests.
>
> When I want to get rid of this file, I use the MemoryStoreFactory and/or 
> put PersistMessages=N in the configuration file. Better performance, less 
> disk space consumption, but no message retransmission.
>
>
> On Feb 8, 2008 3:53 PM, Dan Guo <dua...@ya...> wrote:
>
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello! I use QuickFix for our trading. I run multiple instances, each with 
> a FIX session.
>
> I notice in a typical day, each instance generates a huge log file named 
> FIX.4.2.xxxx(our firm name).body. It can be about 100MB each.
>
> I tried to use ScreenLogFactory(false, false, true). It however did not 
> decrease the log file size.
>
> ScreenLogFactory( bool incoming, bool outgoing, bool event ).
>
> Does anyone have similiar issue and have a solution?
>
> thank you very much,
> Dan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>
>
>
> -----Inline Attachment Follows-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users 

Re: [Quickfix-users] Isn't it time for a new

[Rodrick B. <rod...@gm...>]

On Jan 21, 2008 4:42 PM, Jonathan Kalbfeld <jon...@gm...>
wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>

> Is there a timeframe on using FIX 5.0?  I am building my order book system
> and will probably base it on 5.0?  Sorry, if this question has already
> been answered.
>

Unless you plan to trade other asset classes besides equities there's isnt
really a big need for FIX 5.0 ill rather see focus geared to FAST support.


> Thanks,
>
> Jonathan
>
> On Jan 21, 2008 8:59 AM, <sou...@sp...> wrote:
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi Drazen.
> >
> > Yes, we are definately overdue for an official release.  To put your
> > mind at ease a bit the current version has had very little in the way
> > of issues in the real world.  Certainly nothing that would be
> > considered a critical flaw.  The issue that you see is preemptive,
> > but not terribly critical.  It only effects you if you have no access
> > to your persistence, and even then the effects aren't really
> > detrimental.  It would cause a message to be sent out even though
> > persistence is down.  Basically you would have sent what you intended
> > to send, but there would be no record of it in the message store
> > making it unavailable for resend should the other side request it.
> >
> > But yes, we are looking on getting an official release out soon.  I
> > know it's been longer than usual, but development is moving along as
> > always.  There are a few things that need to be done to the current
> > sourse before I would consider it releasable (the tests aren't the
> > only criteria), but not much at this point.
> >
> > --oren
> >
> > On Jan 21, 2008, at 10:11 AM, <+sourceforge+draza+a8ee29347d.quickfix-
> > users#lis...@sp... > wrote:
> >
> > > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> > > html/index.html
> > > QuickFIX Support: http://www.quickfixengine.org/services.html
> > >
> > > Hi,
> > >
> > > first of all, a big thanks to all the contributors to this great
> > > FIX implementation. I was able in relatively short time to
> > > integrate FIX processing into our system. The build process is
> > > flawless, the documentation sufficient (could be better, though)
> > > and really, all around, great work.
> > >
> > > I was wondering if there were any plans on the next official
> > > version? Looking at some of the commit logs done after the latest
> > > official version, for example 1920 which states "Persistance is
> > > done before sending and will fail if message cannot be stored or
> > > sequence number cannot be incremented" I am worried that what I'm
> > > using now (latest official version 1.12.4) might unnecessarily
> > > cause issues down the road while the issues are actually already
> > > fixed in the SVN (this one in particular is interesting).
> > >
> > > Yes, I am well aware of the possibility of pulling down the sources
> > > as they are now, but I hate using "nightly" builds for production.
> > > Looking at the suite of tests for QuickFIX, if they run
> > > successfully, it shouldn't be that hard to simply declare current
> > > source as 1.12.x or 1.13 (or whatever) and publish it.
> > >
> > > Thanks in advance,
> > >
> > > Drazen
> > >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > ---
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > Quickfix-users mailing list
> > > Qui...@li...
> > > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> > >
> >
> >
> > -------------------------------------------------------------------------
> >
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Quickfix-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> >
>
>
>
> --
> --
> Jonathan Kalbfeld
> ThoughtWave Technologies LLC
> www.thoughtwave.com
> +1 424 354 1814
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>


-- 
Rodrick R. Brown
http://www.rodrickbrown.com

Re: [Quickfix-users] Two more questions about QuickFix

[Djalma R. d. S. F. <drs...@gm...>]

Yes, I have this kind of problem when dealing with hundreds or thousands of
messages per second and most of the times with applications in C# using the
QuickFIX .NET API.

I agree that 10 msg/sec should not be so hard for QF.

On Feb 8, 2008 8:20 PM, Oren Miller <or...@qu...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Yeah, please keep in mind that as long as you are in your callback,
> QuickFIX cannot pull the next message.  Everything that goes into fromApp
> becomes part of the message processing, and if the code in there takes time,
> then QuickFIX is essentially blocked from processing on that thread.  If you
> must do a lot of processing, then stick your message in a queue and get out
> of there.  In the end this probably won't solve your real problem because it
> indicates you cannot handle the messages as fast as they are being sent to
> you.  If you are building a real time system, this will be an issues for you
> regardless.
> --oren
>
> On Feb 8, 2008, at 3:18 PM, Ted Graham wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> You are talking about 10 msg/sec.  At that sending rate, QFJ will have NO
> trouble keeping up.  Look in your code to find what is wrong, QFJ can handle
> significantly higher message rates that what you are describing.
>
>
>
> As for C++ QF vs .NET or Java, I did a fair amount of testing and saw
> negligible differences in speed between C++ QF w/ JNI and the 100% Java
> QFJ.  QFJ may actually be faster, depending on your scenario.
>
>
>
> Ted
>
>
>  ------------------------------
>
> *From:* qui...@li... [
> mailto:qui...@li...<qui...@li...>]
> *On Behalf Of *ying shi
> *Sent:* Friday, February 08, 2008 1:11 PM
> *To:* Qui...@li...
> *Subject:* Re: [Quickfix-users] Two more questions about QuickFix
>
>
>
> Dan:
>
>
>
> Djalma's analysis is not bad. And I suggest that if you have enough time
> to trace the bottleneck, you'd better integrate
>
> QF's source code into your app and build together, so that you can debug
> and profile inside its code to find it.
>
>
>
> I would also suggest use C++ QF lib rather than .Net or Java ones.
>
>
>
> On 08/02/2008, *Djalma Rosa dos Santos Filho* <drs...@gm...>
> wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
> Hi,
>
> This really looks like the TCP buffer is getting full too fast. If
> possible, try to set a larger TCP window or find and improve the bottleneck
> in your application or in QuickFIX.
>
> With my experience, I've noticed that even with a very fast application
> routine in FromApp, QuickFIX is always faster when sending and much slower
> when receiving and I believe that this is the main reason for the issue you
> are reporting, which is not so uncommon for applications that use QF and
> ocassionally are required to process at a higher rate.
>
> In part this is a TCP issue, but I believe that the message receiving
> process in QuickFIX must be optimized at some point in the long road where
> the bytes travel in the engine.
>
> {Recv}->{Parser}->{Validation}->[.NET Interop]->[Message
> Cracker]->{Application Code}
>
> I have some suspicions, but without a deeper investigation and some
> profiling I would not dare to cast the first stone.
>
> Djalma
>
>  On Feb 8, 2008 4:31 PM, Ajay Kamdar <Aja...@tr...> wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
> Dan,
>
> You should also take a look at the application specific processing logic
> in the fromApp() method and determine how long it takes to run, because
> it too could be contributing to the slow processing of FIX messages sent
> by your counter party.
>
> - Ajay
>
>
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of Dan
> Guo
> Sent: Friday, February 08, 2008 1:03 PM
> To: qui...@li...
> Subject: [Quickfix-users] Two more questions about QuickFix
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Everyone!
>
> we notice two issues and want to hear whether anyone knows what is going
> on.
>
> 1. when i sent FIX msgs at higher rate (10 msg per second), there seems
> a longer latency for the msg to hit market.
>
>   i have strong suspecion QuickFix responsible for the longer latency,
> as i isolated other segments' contributions to the overall latency.
>
>   can anyone comment on this?
>
> 2. our broker's network engineers noticed there is TCP back-pressure
> alert on their site. It basically means the FIX messages got queued on
> our broker's side. Either because our network connection is not adequate
> or (and) our QuickFix code cannot process them fast enough.
>
>  did anyone in this list encounter the similiar issue? any comments?
>
> Thank you in advance.
>
> Dan
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
>
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>

Re: [Quickfix-users] Two more questions about QuickFix

[Oren M. <or...@qu...>]

Yeah, please keep in mind that as long as you are in your callback,  
QuickFIX cannot pull the next message.  Everything that goes into  
fromApp becomes part of the message processing, and if the code in  
there takes time, then QuickFIX is essentially blocked from  
processing on that thread.  If you must do a lot of processing, then  
stick your message in a queue and get out of there.  In the end this  
probably won't solve your real problem because it indicates you  
cannot handle the messages as fast as they are being sent to you.  If  
you are building a real time system, this will be an issues for you  
regardless.

--oren

On Feb 8, 2008, at 3:18 PM, Ted Graham wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> You are talking about 10 msg/sec.  At that sending rate, QFJ will  
> have NO trouble keeping up.  Look in your code to find what is  
> wrong, QFJ can handle significantly higher message rates that what  
> you are describing.
>
>
>
> As for C++ QF vs .NET or Java, I did a fair amount of testing and  
> saw negligible differences in speed between C++ QF w/ JNI and the  
> 100% Java QFJ.  QFJ may actually be faster, depending on your  
> scenario.
>
>
>
> Ted
>
>
>
> From: qui...@li... [mailto:quickfix- 
> use...@li...] On Behalf Of ying shi
> Sent: Friday, February 08, 2008 1:11 PM
> To: Qui...@li...
> Subject: Re: [Quickfix-users] Two more questions about QuickFix
>
>
>
> Dan:
>
>
>
> Djalma's analysis is not bad. And I suggest that if you have enough  
> time to trace the bottleneck, you'd better integrate
>
> QF's source code into your app and build together, so that you can  
> debug and profile inside its code to find it.
>
>
>
> I would also suggest use C++ QF lib rather than .Net or Java ones.
>
>
>
> On 08/02/2008, Djalma Rosa dos Santos Filho  
> <drs...@gm...> wrote:
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
>
> Hi,
>
> This really looks like the TCP buffer is getting full too fast. If  
> possible, try to set a larger TCP window or find and improve the  
> bottleneck in your application or in QuickFIX.
>
> With my experience, I've noticed that even with a very fast  
> application routine in FromApp, QuickFIX is always faster when  
> sending and much slower when receiving and I believe that this is  
> the main reason for the issue you are reporting, which is not so  
> uncommon for applications that use QF and ocassionally are required  
> to process at a higher rate.
>
> In part this is a TCP issue, but I believe that the message  
> receiving process in QuickFIX must be optimized at some point in  
> the long road where the bytes travel in the engine.
>
> {Recv}->{Parser}->{Validation}->[.NET Interop]->[Message Cracker]-> 
> {Application Code}
>
> I have some suspicions, but without a deeper investigation and some  
> profiling I would not dare to cast the first stone.
>
> Djalma
>
>
> On Feb 8, 2008 4:31 PM, Ajay Kamdar <Aja...@tr...> wrote:
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
> Dan,
>
> You should also take a look at the application specific processing  
> logic
> in the fromApp() method and determine how long it takes to run,  
> because
> it too could be contributing to the slow processing of FIX messages  
> sent
> by your counter party.
>
> - Ajay
>
>
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of Dan
> Guo
> Sent: Friday, February 08, 2008 1:03 PM
> To: qui...@li...
> Subject: [Quickfix-users] Two more questions about QuickFix
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Everyone!
>
> we notice two issues and want to hear whether anyone knows what is  
> going
> on.
>
> 1. when i sent FIX msgs at higher rate (10 msg per second), there  
> seems
> a longer latency for the msg to hit market.
>
>   i have strong suspecion QuickFix responsible for the longer latency,
> as i isolated other segments' contributions to the overall latency.
>
>   can anyone comment on this?
>
> 2. our broker's network engineers noticed there is TCP back-pressure
> alert on their site. It basically means the FIX messages got queued on
> our broker's side. Either because our network connection is not  
> adequate
> or (and) our QuickFix code cannot process them fast enough.
>
>  did anyone in this list encounter the similiar issue? any comments?
>
> Thank you in advance.
>
> Dan
>
> ---------------------------------------------------------------------- 
> --
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users

Re: [Quickfix-users] Two more questions about QuickFix

[Ted G. <tg...@Co...>]

You are talking about 10 msg/sec.  At that sending rate, QFJ will have NO
trouble keeping up.  Look in your code to find what is wrong, QFJ can handle
significantly higher message rates that what you are describing.

 

As for C++ QF vs .NET or Java, I did a fair amount of testing and saw
negligible differences in speed between C++ QF w/ JNI and the 100% Java QFJ.
QFJ may actually be faster, depending on your scenario.

 

Ted

 

  _____  

From: qui...@li...
[mailto:qui...@li...] On Behalf Of ying shi
Sent: Friday, February 08, 2008 1:11 PM
To: Qui...@li...
Subject: Re: [Quickfix-users] Two more questions about QuickFix

 

Dan:

 

Djalma's analysis is not bad. And I suggest that if you have enough time to
trace the bottleneck, you'd better integrate

QF's source code into your app and build together, so that you can debug and
profile inside its code to find it.

 

I would also suggest use C++ QF lib rather than .Net or Java ones.

 

On 08/02/2008, Djalma Rosa dos Santos Filho <drs...@gm...> wrote:


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html





Hi,

This really looks like the TCP buffer is getting full too fast. If possible,
try to set a larger TCP window or find and improve the bottleneck in your
application or in QuickFIX.

With my experience, I've noticed that even with a very fast application
routine in FromApp, QuickFIX is always faster when sending and much slower
when receiving and I believe that this is the main reason for the issue you
are reporting, which is not so uncommon for applications that use QF and
ocassionally are required to process at a higher rate.

In part this is a TCP issue, but I believe that the message receiving
process in QuickFIX must be optimized at some point in the long road where
the bytes travel in the engine.

{Recv}->{Parser}->{Validation}->[.NET Interop]->[Message
Cracker]->{Application Code}

I have some suspicions, but without a deeper investigation and some
profiling I would not dare to cast the first stone.

Djalma



On Feb 8, 2008 4:31 PM, Ajay Kamdar <Aja...@tr...> wrote:

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

 

Dan,

You should also take a look at the application specific processing logic
in the fromApp() method and determine how long it takes to run, because
it too could be contributing to the slow processing of FIX messages sent
by your counter party.

- Ajay


-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Dan
Guo
Sent: Friday, February 08, 2008 1:03 PM
To: qui...@li...
Subject: [Quickfix-users] Two more questions about QuickFix

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Everyone!

we notice two issues and want to hear whether anyone knows what is going
on.

1. when i sent FIX msgs at higher rate (10 msg per second), there seems
a longer latency for the msg to hit market.

  i have strong suspecion QuickFix responsible for the longer latency,
as i isolated other segments' contributions to the overall latency.

  can anyone comment on this?

2. our broker's network engineers noticed there is TCP back-pressure
alert on their site. It basically means the FIX messages got queued on
our broker's side. Either because our network connection is not adequate
or (and) our QuickFix code cannot process them fast enough.

 did anyone in this list encounter the similiar issue? any comments?

Thank you in advance.

Dan

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users
 



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

 

Re: [Quickfix-users] Two more questions about QuickFix

[ying s. <sy8...@gm...>]

Dan:

Djalma's analysis is not bad. And I suggest that if you have enough time to
trace the bottleneck, you'd better integrate
QF's source code into your app and build together, so that you can debug and
profile inside its code to find it.

I would also suggest use C++ QF lib rather than .Net or Java ones.


On 08/02/2008, Djalma Rosa dos Santos Filho <drs...@gm...> wrote:
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hi,
>
> This really looks like the TCP buffer is getting full too fast. If
> possible, try to set a larger TCP window or find and improve the bottleneck
> in your application or in QuickFIX.
>
> With my experience, I've noticed that even with a very fast application
> routine in FromApp, QuickFIX is always faster when sending and much slower
> when receiving and I believe that this is the main reason for the issue you
> are reporting, which is not so uncommon for applications that use QF and
> ocassionally are required to process at a higher rate.
>
> In part this is a TCP issue, but I believe that the message receiving
> process in QuickFIX must be optimized at some point in the long road where
> the bytes travel in the engine.
>
> {Recv}->{Parser}->{Validation}->[.NET Interop]->[Message
> Cracker]->{Application Code}
>
> I have some suspicions, but without a deeper investigation and some
> profiling I would not dare to cast the first stone.
>
> Djalma
>
>
> On Feb 8, 2008 4:31 PM, Ajay Kamdar <Aja...@tr...> wrote:
>
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> >
> > Dan,
> >
> > You should also take a look at the application specific processing logic
> > in the fromApp() method and determine how long it takes to run, because
> > it too could be contributing to the slow processing of FIX messages sent
> > by your counter party.
> >
> > - Ajay
> >
> > -----Original Message-----
> > From: qui...@li...
> > [mailto:qui...@li...] On Behalf Of Dan
> > Guo
> > Sent: Friday, February 08, 2008 1:03 PM
> > To: qui...@li...
> > Subject: [Quickfix-users] Two more questions about QuickFix
> >
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi Everyone!
> >
> > we notice two issues and want to hear whether anyone knows what is going
> > on.
> >
> > 1. when i sent FIX msgs at higher rate (10 msg per second), there seems
> > a longer latency for the msg to hit market.
> >
> >   i have strong suspecion QuickFix responsible for the longer latency,
> > as i isolated other segments' contributions to the overall latency.
> >
> >   can anyone comment on this?
> >
> > 2. our broker's network engineers noticed there is TCP back-pressure
> > alert on their site. It basically means the FIX messages got queued on
> > our broker's side. Either because our network connection is not adequate
> > or (and) our QuickFix code cannot process them fast enough.
> >
> >  did anyone in this list encounter the similiar issue? any comments?
> >
> > Thank you in advance.
> >
> > Dan
> >
> > ------------------------------------------------------------------------
> > -
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Quickfix-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Quickfix-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>

Re: [Quickfix-users] Two more questions about QuickFix

[Djalma R. d. S. F. <drs...@gm...>]

Hi,

This really looks like the TCP buffer is getting full too fast. If possible,
try to set a larger TCP window or find and improve the bottleneck in your
application or in QuickFIX.

With my experience, I've noticed that even with a very fast application
routine in FromApp, QuickFIX is always faster when sending and much slower
when receiving and I believe that this is the main reason for the issue you
are reporting, which is not so uncommon for applications that use QF and
ocassionally are required to process at a higher rate.

In part this is a TCP issue, but I believe that the message receiving
process in QuickFIX must be optimized at some point in the long road where
the bytes travel in the engine.

{Recv}->{Parser}->{Validation}->[.NET Interop]->[Message
Cracker]->{Application Code}

I have some suspicions, but without a deeper investigation and some
profiling I would not dare to cast the first stone.

Djalma


On Feb 8, 2008 4:31 PM, Ajay Kamdar <Aja...@tr...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Dan,
>
> You should also take a look at the application specific processing logic
> in the fromApp() method and determine how long it takes to run, because
> it too could be contributing to the slow processing of FIX messages sent
> by your counter party.
>
> - Ajay
>
> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...] On Behalf Of Dan
> Guo
> Sent: Friday, February 08, 2008 1:03 PM
> To: qui...@li...
> Subject: [Quickfix-users] Two more questions about QuickFix
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Everyone!
>
> we notice two issues and want to hear whether anyone knows what is going
> on.
>
> 1. when i sent FIX msgs at higher rate (10 msg per second), there seems
> a longer latency for the msg to hit market.
>
>   i have strong suspecion QuickFix responsible for the longer latency,
> as i isolated other segments' contributions to the overall latency.
>
>   can anyone comment on this?
>
> 2. our broker's network engineers noticed there is TCP back-pressure
> alert on their site. It basically means the FIX messages got queued on
> our broker's side. Either because our network connection is not adequate
> or (and) our QuickFix code cannot process them fast enough.
>
>  did anyone in this list encounter the similiar issue? any comments?
>
> Thank you in advance.
>
> Dan
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-users] Two more questions about QuickFix

[Ajay K. <Aja...@tr...>]

Dan, 

You should also take a look at the application specific processing logic
in the fromApp() method and determine how long it takes to run, because
it too could be contributing to the slow processing of FIX messages sent
by your counter party.

- Ajay

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Dan
Guo
Sent: Friday, February 08, 2008 1:03 PM
To: qui...@li...
Subject: [Quickfix-users] Two more questions about QuickFix

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Everyone!

we notice two issues and want to hear whether anyone knows what is going
on.

1. when i sent FIX msgs at higher rate (10 msg per second), there seems
a longer latency for the msg to hit market.

   i have strong suspecion QuickFix responsible for the longer latency,
as i isolated other segments' contributions to the overall latency. 

   can anyone comment on this? 

2. our broker's network engineers noticed there is TCP back-pressure
alert on their site. It basically means the FIX messages got queued on
our broker's side. Either because our network connection is not adequate
or (and) our QuickFix code cannot process them fast enough. 

  did anyone in this list encounter the similiar issue? any comments?

Thank you in advance. 

Dan

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

Re: [Quickfix-users] how can i NOT generate a big FIX.4.2-xxxxx.body file?

[Dan G. <dua...@ya...>]

Djalma,
thank you. that is it!

i guess since i am a client (not a brokerage), i do not need re-transmission feature. i would expect my broker DO RETRAN on my behalf (if i miss a msg and ask them to retrans from an older sequence #), not the other around. 

Is my understanding correct? 

Dan

----- Original Message ----
From: Djalma Rosa dos Santos Filho <drs...@gm...>
To: "Qui...@li..." <qui...@li...>
Sent: Friday, February 8, 2008 1:10:28 PM
Subject: Re: [Quickfix-users] how can i NOT generate a big FIX.4.2-xxxxx.body file?

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html




-----Inline Attachment Follows-----


The .body file is one of the files used by the FileStore, it is useful only if you want the engine to be able to respond to resend requests.

When I want to get rid of this file, I use the MemoryStoreFactory and/or put PersistMessages=N in the configuration file. Better performance, less disk space consumption, but no message retransmission.


On Feb 8, 2008 3:53 PM, Dan Guo <dua...@ya...> wrote:

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hello! I use QuickFix for our trading. I run multiple instances, each with a FIX session.

I notice in a typical day, each instance generates a huge log file named FIX.4.2.xxxx(our firm name).body. It can be about 100MB each.

I tried to use ScreenLogFactory(false, false, true). It however did not decrease the log file size.

ScreenLogFactory( bool incoming, bool outgoing, bool event ).

Does anyone have similiar issue and have a solution?

thank you very much,
Dan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users





-----Inline Attachment Follows-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


-----Inline Attachment Follows-----

_______________________________________________
Quickfix-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-users

Re: [Quickfix-users] how can i NOT generate a big FIX.4.2-xxxxx.body file?

[Djalma R. d. S. F. <drs...@gm...>]

The .body file is one of the files used by the FileStore, it is useful only
if you want the engine to be able to respond to resend requests.

When I want to get rid of this file, I use the MemoryStoreFactory and/or put
PersistMessages=N in the configuration file. Better performance, less disk
space consumption, but no message retransmission.

On Feb 8, 2008 3:53 PM, Dan Guo <dua...@ya...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello! I use QuickFix for our trading. I run multiple instances, each with
> a FIX session.
>
> I notice in a typical day, each instance generates a huge log file named
> FIX.4.2.xxxx(our firm name).body. It can be about 100MB each.
>
> I tried to use ScreenLogFactory(false, false, true). It however did not
> decrease the log file size.
>
> ScreenLogFactory( bool incoming, bool outgoing, bool event ).
>
> Does anyone have similiar issue and have a solution?
>
> thank you very much,
> Dan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

[Quickfix-users] Two more questions about QuickFix

[Dan G. <dua...@ya...>]

Hi Everyone!

we notice two issues and want to hear whether anyone knows what is going on.

1. when i sent FIX msgs at higher rate (10 msg per second), there seems a longer latency for the msg to hit market.

   i have strong suspecion QuickFix responsible for the longer latency, as i isolated other segments' contributions to the overall latency. 

   can anyone comment on this? 

2. our broker's network engineers noticed there is TCP back-pressure alert on their site. It basically means the FIX messages got queued on our broker's side. Either because our network connection is not adequate or (and) our QuickFix code cannot process them fast enough. 

  did anyone in this list encounter the similiar issue? any comments?

Thank you in advance. 

Dan

[Quickfix-users] how can i NOT generate a big FIX.4.2-xxxxx.body file?

[Dan G. <dua...@ya...>]

Hello! I use QuickFix for our trading. I run multiple instances, each with a FIX session. 

I notice in a typical day, each instance generates a huge log file named FIX.4.2.xxxx(our firm name).body. It can be about 100MB each. 

I tried to use ScreenLogFactory(false, false, true). It however did not decrease the log file size.

ScreenLogFactory( bool incoming, bool outgoing, bool event ).

Does anyone have similiar issue and have a solution? 

thank you very much,
Dan

[Quickfix-users] Disconnect handling

[<urb...@sb...>]

Hi,

We're in QF C# version with our latest change log showing 1.12.4.

We're handling a connection with a vendor and finding that after we place an 
order with them, they sometimes disconnect us abruptly with a TCP control 
RST and drop the connection on us.  We are set as an initiator, heartbeat of 
30, with a reconnect interval of 60.  We believet that the vendor is 
possibly holding us out of re-connect, or possibly has a sandbox kind of 
lock on the login for some period we're now attempting to verify.

We're logging as "filelog factory" but we found no indication in the "event 
log" that show the engine recognized it became disonnected.

What behaviour ?
And what logging should we normally see in QF, when a RST abruptly 
terminates from the connected provider?

Thanks for any help or suggestions.

Mike W. 

[Quickfix-users] Unhandled exception in SessionSettings constructor

[ying s. <sy8...@gm...>]

Hi, all:

I am new to QuickFix. I tested the library with the tutorial basic example,
code is listed below. It builds and run in Visual Studio 2005. Command
argument I give is arbitrary
file name. It crashes on this line:


    FIX::SessionSettings settings(fileName);

I get unhandled exception: access violation regardless what fileName is. Can
anyone give me help on this?

Thanks a lot



*Source code:*


#include "stdafx.h"
#include "quickfix/SessionID.h"
#include "quickfix/FileStore.h"
#include "quickfix/FileLog.h"
#include "quickfix/SocketAcceptor.h"
#include "quickfix/Session.h"
#include "quickfix/SessionSettings.h"
#include "quickfix/Application.h"

using namespace FIX;

class MyApplication : public FIX::Application
{
public:
 ~MyApplication() {}
public:
 virtual void onCreate(const SessionID &) {}
 virtual void onLogon(const SessionID &) {}
 virtual void onLogout(const SessionID &) {}
 virtual void toAdmin(Message &, const SessionID &) {}
 virtual void toApp(Message &, const SessionID &) throw (DoNotSend) {}
 virtual void fromAdmin(const Message &, const SessionID &) throw
(FieldNotFound, IncorrectDataFormat, IncorrectTagValue, RejectLogon) {}
 virtual void fromApp(const Message &, const SessionID &) throw
(FieldNotFound, IncorrectDataFormat, IncorrectTagValue,
UnsupportedMessageType) {}
};

int main( int argc, char** argv )
{
  try
  {
    if(argc < 2) return 1;
    std::string fileName = argv[1];

    FIX::SessionSettings settings(fileName);

    MyApplication application;
    FIX::FileStoreFactory storeFactory(settings);
    FIX::FileLogFactory logFactory(settings);
    FIX::SocketAcceptor acceptor
      (application, storeFactory, settings, logFactory /*optional*/);
    acceptor.start();
    // while( condition == true ) { do something; }
    acceptor.stop();
    return 0;
  }
  catch(FIX::ConfigError& e)
  {
    std::cout << e.what();
    return 1;
  }
}

Re: [Quickfix-users] TransactTools - OpenFix TestSuite.

[Oren M. <or...@qu...>]

Yeah, it's a nice service.  We certified QuickFIX on it early in its  
development.

--oren

On Jan 27, 2008, at 10:29 AM, Rodrick Brown wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I'm not sure if many are aware of OpenFIX by TransactTools but its  
> a really wonderful service provide for free. OpenFix can be used to  
> test your engine's compatibility against the FIX spec. It works in  
> two modes client or server and performs various tests and gives you  
> a nice report on the behavior of your FIX Engine.
>
> -- 
> Rodrick R. Brown
> http://www.rodrickbrown.com
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users

Re: [Quickfix-users] TransactTools - OpenFix TestSuite.

[Rodrick B. <rod...@gm...>]

I guess it would be nice to provide a url in the original email :)
http://www.openfix.net/

On Jan 27, 2008 11:29 AM, Rodrick Brown <rod...@gm...> wrote:

> I'm not sure if many are aware of OpenFIX by TransactTools but its a
> really wonderful service provide for free. OpenFix can be used to test your
> engine's compatibility against the FIX spec. It works in two modes client or
> server and performs various tests and gives you a nice report on the
> behavior of your FIX Engine.
>
> --
> Rodrick R. Brown
> http://www.rodrickbrown.com

[Quickfix-users] TransactTools - OpenFix TestSuite.

[Rodrick B. <rod...@gm...>]

I'm not sure if many are aware of OpenFIX by TransactTools but its a really
wonderful service provide for free. OpenFix can be used to test your
engine's compatibility against the FIX spec. It works in two modes client or
server and performs various tests and gives you a nice report on the
behavior of your FIX Engine.

-- 
Rodrick R. Brown
http://www.rodrickbrown.com