{{Quickfixn}} Crack Message from String

Mon Nov 4 12:08:20 PST 2013

Hi,

i personally had bad experience with TPL regarding speed. I use instead
"ConcurrentQueue" which is also thread safe together with async methods "var
t = Task.Run<T>(async () => {})". My app performece pretty good - something
out of fix, writing log entry, each in 0.3ms beside the QF/n o the same
host.

Walter.

From: quickfixn-bounces at lists.quickfixn.com
[mailto:quickfixn-bounces at lists.quickfixn.com] On Behalf Of Phillip Wei
Sent: Montag, 4. November 2013 20:43
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} Crack Message from String

Mike's answer seems right.

I would consider using the TPL Dataflow package (if you can) instead of an
explicit MessageQueue to consume the messages on a seperate task
(http://msdn.microsoft.com/en-us/library/hh228601(v=vs.110).aspx).  This
seems like it would be easier (and maybe more performant).

Phil

From: quickfixn-bounces at lists.quickfixn.com
<mailto:quickfixn-bounces at lists.quickfixn.com>
[mailto:quickfixn-bounces at lists.quickfixn.com] On Behalf Of Mike Gatny
Sent: Monday, November 04, 2013 2:28 PM
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} Crack Message from String

The usual way to do this is to have your OnMessage callbacks do nothing but
put a copy of the msg onto a queue for later processing.  I.e. similar to
what you are doing, but you let QF do the parsing for you before you do the
queueing.  That should be doable at way faster than 60/sec.  Not sure if
anyone has any QF/n perf numbers lying around...  

Anyway, in general you want to return from the QF callbacks asap, otherwise
you are blocking its processing thread.

On Nov 4, 2013 1:10 PM, "Gaull, James" <JGaull at ftportfolios.com
<mailto:JGaull at ftportfolios.com> > wrote:

Thank you very much for your reply.  I will look into getting this to work
with a FIX42.Message.

If it's not out of scope for this forum, I'd like to explain my thought
process behind using the message queue.  I need to be able to receive about
1000 messages per second through my C# application from the FIX hub we're
using but I don't have a requirement to process all of these messages that
quickly.  I started out by writing code to process the execution report
messages in the FromApp function but found that I was only able to process
about 60 messages per second which was unacceptable since it will slow down
the FIX hub.  My thought was that if my FromAdmin function just writes the
FIX messages to a queue, I could then have another process pop these FIX
messages off the queue and I could process them without slowing down the FIX
hub.

Maybe I'm overthinking this.  I'd really be interested in hearing how others
are delegating the processing of the messages so they're not slowing down
the receiving of messages.  But I understand this may be out of scope for
this forum.

From: quickfixn-bounces at lists.quickfixn.com
<mailto:quickfixn-bounces at lists.quickfixn.com>
[mailto:quickfixn-bounces at lists.quickfixn.com
<mailto:quickfixn-bounces at lists.quickfixn.com> ] On Behalf Of Mike Gatny
Sent: Monday, November 04, 2013 10:53 AM
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} Crack Message from String

The cracker delegates to OnMessage using the (C#) Type of the Message.  So
you need to create a FIX42.Message instead of a Message in order for your
call to crack() to work.  See line 505 of Session.cs in the master branch to
see how QF itself does this.

_______________________________________________
Quickfixn mailing list
Quickfixn at lists.quickfixn.com <mailto:Quickfixn at lists.quickfixn.com> 
http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20131104/7b469342/attachment-0002.htm>