{{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