{{Quickfixn}} CheckLatency Setting

Gaull, Jim JGaull at ftportfolios.com
Thu Sep 24 06:34:49 PDT 2015


I’m using version 1.5.

Jim Gaull
Business Unit Developer | First Trust Portfolios LP
120 E. Liberty Drive Suite 400 | Wheaton, IL 60187
630.517.7779 | www.ftportfolios.com<http://www.ftportfolios.com/>

From: Quickfixn [mailto:quickfixn-bounces at lists.quickfixn.com] On Behalf Of Mike Gatny
Sent: Wednesday, September 23, 2015 4:34 PM
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} CheckLatency Setting

What version of qf/n are you using?

--
Mike Gatny
Connamara Systems, LLC

On Wed, Sep 23, 2015 at 3:12 PM, Gaull, Jim <JGaull at ftportfolios.com<mailto:JGaull at ftportfolios.com>> wrote:
Thanks for taking a look at my issue!  I am offloading the processing to another thread so I don’t think I’m backing up the queue.  I looked at the log and up to 30 FIX messages are being written to the log in 1 millisecond.  I’m not sure if that conclusively proves that it’s not the bottleneck.

My co-worker just found this article from 2013 on stackoverflow.
http://stackoverflow.com/questions/18267010/quickfix-n-erroran-existing-was-forcibly-closed-the-remote-host-at-quickfix-so

Someone there said that the CheckLatency flag is not implemented in the .Net version of QuickFIX.  A suggestion was to set the CheckLatency property to false before the connection is initiated.  I’ll look into doing this next.  Thanks again!

From: Quickfixn [mailto:quickfixn-bounces at lists.quickfixn.com<mailto:quickfixn-bounces at lists.quickfixn.com>] On Behalf Of Grant Birchmeier
Sent: Wednesday, September 23, 2015 1:50 PM
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} CheckLatency Setting

I suspect the problem is actually with your program.

Are you doing any time-expensive processing in your OnMessage() callbacks?  These are executed serially (to ensure that received messages are processed in order).  If your OnMessage callback blocks for non-trivial amount of time, it will eventually cause your incoming message queue to back up with accumulated messages waiting to be processed.  Anecdotally, I get the impression that DB-related actions often cause this problem with people.

If you need to do lengthy processing on incoming messages, I recommend you push them into a queue for processing by a separate worker thread.

Does this sound like something that might be happening in your program?

-Grant

On Wed, Sep 23, 2015 at 1:36 PM, Gaull, Jim <JGaull at ftportfolios.com<mailto:JGaull at ftportfolios.com>> wrote:
I’m experiencing a lag between the value in tag 52 (sending time) and the time I’m actually receiving FIX messages from my provider.  As soon as the lag becomes 2 minutes or greater, I am rejecting messages with an error saying “SendingTime accuracy problem” and logging out.  Until my provider can correct the issue with the lag, I’d like to disable checking for the latency.  I found in the documentation that checking for latency is True by default and the MaxLatency is set to 2 minutes.  I changed the config file to not check for latency but it’s not having any effect so I must be doing something wrong.  I’m still rejecting messages that are lagging by over 2 minutes.

Here’s my config file.  Can someone tell me what I’m doing wrong?

[DEFAULT]
ConnectionType=initiator
ReconnectInterval=2
FileStorePath=c:\store
FileLogPath=c:\fixlog
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=Y
DataDictionary=c:\FIX42.xml
SocketConnectHost=127.0.0.1
SocketConnectPort=5002
ResetOnLogon=Y
CheckLatency=N


# standard config elements

[SESSION]
BeginString=FIX.4.2
SenderCompID=ABC
TargetCompID=DEF
HeartBtInt=30

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



--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com

_______________________________________________
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/20150924/95ee1520/attachment-0002.htm>


More information about the Quickfixn mailing list