{{Quickfixn}} CheckLatency Setting

[Gaull, Jim]

Mike,

Thanks for your help!  Our clock is synced up.  Our provider is looking into the issue further as it appears the lag may be network related.

I was able to make a change so that we can now ignore the lag.  I chose to make these “CheckLatency” configurable on our client instead of rebuilding the QuickFIX library.  I’ll remove this code once version 1.6 is available.  I modified the OnLogon function as shown below:


// Proprietary code has been removed
public void OnLogon(SessionID sessionID)
        {
            try
            {
                _session.CheckLatency = Properties.Settings.Default.CheckForLatency;
            }
            catch (Exception ex)
            {
            }
        }

From: Quickfixn [mailto:quickfixn-bounces at lists.quickfixn.com] On Behalf Of Mike Gatny
Sent: Thursday, September 24, 2015 8:46 AM
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} CheckLatency Setting

Jim,

The SessionSettings for CheckLatency and MaxLatency are indeed not configurable in v1.5.  Are you syncing your server's clock with ntp? If not, this alone can cause this problem.  If you already are, then my last suggestion is to pull down the latest qf/n source and build it -- these options have since been implemented, but we have not yet cut the v1.6 release.

--
Mike Gatny
Connamara Systems, LLC

On Thu, Sep 24, 2015 at 9:34 AM, Gaull, Jim <JGaull at ftportfolios.com<mailto:JGaull at ftportfolios.com>> wrote:
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<tel:630.517.7779> | www.ftportfolios.com<http://www.ftportfolios.com/>

From: Quickfixn [mailto:quickfixn-bounces at lists.quickfixn.com<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


_______________________________________________
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/ff823258/attachment-0002.htm>