Re: [Quickfix-developers] it there known quickfix performance problem ?

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

I assume you are using the JNI version?  This is something I have
encountered using the C# version with high volume data.  The problem was
apparently caused by the large amount of messages being created combined
with the relatively large amount of time it takes to delete a message
and garbage collecting a whole bunch of them all at once.  I'm guessing
you are encountering a similar issue.  The solution in C# was to make
the messages disposable allowing the user to delete the message as soon
as they are done processing it.  This seemed to solve the problem by
allowing a steadier processing rate.  I think we need to add the same
ability to the JNI wrapper to solve your problem.

--oren

> -------- Original Message --------
> Subject: [Quickfix-developers] it there known quickfix performance
> problem ?
> From: "serdar ozay" <ser...@gm...>
> Date: Thu, October 09, 2008 10:57 am
> To: qui...@li...
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html<hr>Hi all,
> we are developing the QuickFix engine both for the Market Data and the order
> route with java. We are using quickfix 4.2 protocol.
> Normaly our program and quickfix api is working very good. But when the
> markets price moving  to fast, only our cruide oil's products
> prices are frozen about 3 - 20 second. When we analyse our logs, we are
> seeing, our price provider is cutting cruide oil price data and collecting
> price during this frozen. And then sending all price in one message. ( Like
> 215 price in only one  fix message after 20 second) When we speak these
> guys,
> they are saying, their software is cutting and collecting price -only cruide
> oil- because of our quickfix engine client is too slow.  But I can not
> understand,
> how can be this sitiuation happen; the session is not broking also all the
> other prices are running.
> we are watching  all this logs on quickfix.Application class level and also
> in our code, we have taken all the parsing process the fix message seperate
> thread.
> Is there any known quick fix engine performance problem with taking message?
> Is that can be true ?
> please help
> Thanks.
> Serdar<hr>-------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/<hr>_______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers