{{Quickfixn}} CheckLatency Setting
Kamal Saxena
kamal.saxena at systematixindia.com
Thu Sep 24 21:57:15 PDT 2015
Hello Expert,
I need one help,
I am using FIX42.xml
Qus : 1
My FIX Client has successfully connected to FIX Drop Copy session and
X_TRADER.
I am able to telnet both IP/Port.
I have Getting Fix Message Including status 146.
How to face this tag problem? Tag RefTagID => 371=146
Qus : 2
FIX Client application rejects execution messages.
Returns: Tag not defined for this message type
Example:
8=FIX.4.29=15235=334=249=SYSTEMATIX50=NONE52=20150924-08:53:21.84856=TTDS68BO57=TTORDDS51000145=258=Tag
not defined for this message type371=146372=8373=210=238
On Thu, Sep 24, 2015 at 8:42 PM, Gaull, Jim <JGaull at ftportfolios.com> wrote:
> 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>
> 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
> <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>
> 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] *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>
> 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
> 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
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>
>
>
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>
>
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>
--
*Kamal Saxena*
Software Engineer
*Systematix Infotech Pvt. Ltd.*
*India *| Australia | United Kingdom | United States
Plot No. 67, PU-4 Commercial, Behind C21 Mall | AB Road Indore
*Mob:* +91-9644122296 | *Tel:* 0731-2570282| *Skype:* kamal_sipl
*Website Address:* http://systematixinfotech.com
*Follow Us:* Facebook <https://www.facebook.com/SystematixInfotech> |
Google+ <https://plus.google.com/u/0/+Systematixinfotech/posts> | LinkedIn
<https://www.linkedin.com/company/systematix-infotech-pvt.ltd> | Twitter
<https://twitter.com/SystematixInfo>
Disclaimer: This e-mail, including any attachments, is for the sole use of
the intended recipient(s) and may contain confidential and/or privileged
information. Any unauthorized review, use, disclosure, or distribution is
prohibited. If you are not the intended recipient, please contact the
sender immediately and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20150925/a0086fae/attachment-0002.htm>
More information about the Quickfixn
mailing list