{{Quickfixn}} FW: Execution report not coming for few trades

Rajkumar R kraj232 at gmail.com
Wed Sep 2 08:00:05 PDT 2020


Hi Lanfranco,

Thanks for the clarification. Attached code snippet which i used in
OnMessage event.


With Regards.
R.Rajkumar





On Wed, Sep 2, 2020 at 7:04 PM Lanfranco Morini <Lanfranco.Morini at cegeka.it>
wrote:

> Yes, it’s another possibility...
>
> In this case Rajkumar should decouple the OnMessage callbacks with their
> implementation using an internal layer of queues…
>
>
>
> Lan
>
>
>
> *From:* Quickfixn <quickfixn-bounces at lists.quickfixn.com> *On Behalf Of *Grant
> Birchmeier
> *Sent:* mercoledì 2 settembre 2020 15:28
> *To:* Mailing list for QuickFIX/n <quickfixn at lists.quickfixn.com>
> *Cc:* Arun Sivaprakash <arunsivaprakash at gmail.com>
> *Subject:* Re: {{Quickfixn}} FW: Execution report not coming for few
> trades
>
>
>
> I suspect that Rajkumar's QF OnMessage callbacks are doing too much work
> and taking too much time to return.
>
>
>
> Messages in QF are processed serially; message-2 will not be processed
> until OnMessage(message-1) returns.
>
>
>
> If OnMessage takes too long to return, the receiving queue will start to
> back up during heavy traffic.  This would result in TestRequests and
> connection drops, as the counterparty tries to deal with your lagginess.
>
>
>
> On Wed, Sep 2, 2020 at 5:20 AM Lanfranco Morini <
> Lanfranco.Morini at cegeka.it> wrote:
>
> Hi Rajkumar,
>
> I’m quite sure that no bugs are affecting your QuickFIX/n.
>
>
>
> I can add some further considerations to this premise (which surely will
> not be exhaustive)
>
>    1. A Logon message with 141=Y during the trading day is very
>    dangerous: after this kind of logon, you (and your counterparty) “lose”
>    every application message sent before (read: a resend request for some
>    execution reports exchanged before the new logon will not returns anything,
>    because both of FIX Engines erase every sequence numbers and their related
>    messages)
>    2. From the messages log that you sent (even if partial), it can be
>    deducted that the disconnection comes from a network failure (no test
>    request, nor logout messages are in your log)
>    3. FXALL seems to have some problem in managing your messages, in fact
>    they sent a test request (35=1) at 20200828-13:29:53.409 (you registered it
>    at 20200828-13:30:15.911) even if you sent a previous message at
>    52=20200828-13:29:57.833 (less than 60 seconds configured as HeartBeat
>    interval)
>
>
>    1. Another alternative can be that there are some latency on the
>       network (it can also cause a forced closure of the network connection
>       between you and FXALL): this can be deducted looking at the timestamp
>       differences in several messages
>
> example
>
> 20200828-13:28:42.130 : 8=FIX.4.4  9=74  35=A  34=1  49=xxxxxxx
> 52=20200828-13:28:42.130  56=FXALL  98=0  108=60  141=Y  10=200
>
> 20200828-13:28:43.005 : 8=FIX.4.4  9=74  35=A  49=FXALL  56=xxxxxxx  34=1
> 52=20200828-13:28:42.963  108=60  141=Y  98=0  10=214
>
> From this two logon message we can note that comparing tag 52 timestamp
> and the log time stamp (written before the message) you received the FXALL
> message at least after 42ms they sent it 13:28:43.963 vs. 13:28:43.005
>
> But if we look at the test request sent by FXALL you received it after 22
> seconds they sent it
>
> 20200828-13:30:15.911 : 8=FIX.4.4  9=78  35=1  49=FXALL  56=xxxxxxx  34=8
> 52=20200828-13:29:53.409  112=20200828-13:29:53  10=198
>
>
>
> We can say that changing the 141=1 settings can help to better understand
> what is causing the disconnection and probably the loss of messages, in
> fact without a forced sequence reset during logon, an automatic alignment
> of the lost messages should happen after logon…
>
>
>
> Last but not least: if FXALL is sure that they sent the execution reports
> that you miss, they should be able to provide you their MsgSeqNum: in this
> case you are able to look for them in your log and verifiy if really lost
> themo or if they never arrived\never been sent
>
>
>
> I wait for your feedback related to my considerations,
>
>
>
> Best regards,
>
> Lanfranco
>
>
>
>
>
> *From:* Quickfixn <quickfixn-bounces at lists.quickfixn.com> *On Behalf Of *Rajkumar
> R
> *Sent:* mercoledì 2 settembre 2020 09:35
> *To:* Mailing list for QuickFIX/n <quickfixn at lists.quickfixn.com>
> *Cc:* Arun Sivaprakash <arunsivaprakash at gmail.com>
> *Subject:* Re: {{Quickfixn}} FW: Execution report not coming for few
> trades
>
>
>
> Hi LanFranco,
>
>
>
> Thanks for your concern.
>
>
>
> Below attached files are
>
> 1.FIX Connectivity (FIX.4.4-olam-eur-FXALL.event.current)
>
> 2.FIX Message Logs ( FIX.4.4-olam-eur-FXALL.messages.current)
> 3.configuration file (QfSettings.txt)
>
>
>
> The message logs is extracted based on the event logs disconnectivity
> timings
>
>
>
> Note : I have already shared the event & message on  28-Aug-2020
>
>
>
> If any more inputs required do please let me know
>
>
>
> Thanks in advance
>
>
>
> With Regards,
>
> R.Rajkumar
>
>
>
>
>
>
>
> On Mon, Aug 31, 2020 at 9:58 PM Lanfranco Morini <
> Lanfranco.Morini at cegeka.it> wrote:
>
> Rajkumar,
>
> we never received the messages log that you wrote you have sent, and also
> config file never arrive: without messages it is impossible to understand
> what went wrong on your Fix Engine
>
>
>
> That’s why Grant said that is impossible to help you: FIX Protocol is
> message based and each message is the consequence of the previous one, we
> need them to understand if you missed\discard the execution reports or if
> your counterparty never sent (even if they say the opposite)…
>
>
>
> Hope it can help…
>
>
>
> Lanfranco
>
>
>
>
>
> *From:* Quickfixn <quickfixn-bounces at lists.quickfixn.com> *On Behalf Of *Rajkumar
> R
> *Sent:* lunedì 31 agosto 2020 17:45
> *To:* Mailing list for QuickFIX/n <quickfixn at lists.quickfixn.com>
> *Subject:* Re: {{Quickfixn}} Execution report not coming for few trades
>
>
>
> Hi,
>
>
>
> Thanks for your help
>
>
>
> With regards,
>
> R. Rajkumar
>
> On Mon, 31 Aug, 2020, 8:51 PM Grant Birchmeier, <gbirchmeier at connamara.com>
> wrote:
>
> No, we can't.
>
>
>
> The information that you've provided is not sufficient, and my attempts to
> get better info out of you have failed.
>
>
>
> You didn't try the actions that I suggested.   You didn't provide the info
> that I requested.  Your last email did not make any sense.
>
>
>
> If you want help, re-read my last email and do what I have asked.
>
>
>
> -Grant
>
>
>
>
>
>
>
>
>
> On Mon, Aug 31, 2020 at 10:10 AM Rajkumar R <kraj232 at gmail.com> wrote:
>
> Hi,
>
>
>
> Can anybody help please.
>
>
>
> With regards,
>
> R. Rajkumar
>
>
>
> On Fri, 28 Aug, 2020, 10:27 PM Rajkumar R, <kraj232 at gmail.com> wrote:
>
> Hi,
>
> Am sorry in my previous mail I have taken a wrong date of current and
> message logs, that is the reason I have resent the 18jul2020 logs of
> current and message log which match the timestamps. Just to have clarity I
> have added the config file as well.
>
>
>
> With regards,
>
> Rajkumar
>
>
>
>
>
>
>
> Regards,
>
> Rajkumar
>
>
>
> On Fri, 28 Aug, 2020, 9:07 PM Grant Birchmeier, <gbirchmeier at connamara.com>
> wrote:
>
> With all due respect, I get the impression that you don't really know what
> you're doing.
>
>
>
> It's like you're sending me pastes of errors that you aren't even
> reading.  They have nothing to do with app-layer messaging.  Do these
> timestamps even correspond with any ExecutionReports that you're supposedly
> missing?
>
>
>
> You're sending logs for connection drops.  I already told you what I think
> of these.  I think they have nothing to do with your missed messages.
>
>
>
> Do this:
>
>    1. Ask your counterparty for a message that they sent that you missed.
>    2. Go in your message log, find that time, and look at what's
>    happening.
>
> If you wish to ask for further help, please send details about (1) and (2).
>
>
>
> -Grant
>
> _______________________________________________
> 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
>
>
>
>
> --
>
> Grant Birchmeier
>
> *Connamara Systems, LLC*
>
> *Made-To-Measure Trading Solutions.*
>
> Exactly what you need. No more. No less.
>
> http://connamara.com
>
>
> This email, along with any attachments, is confidential. If you believe
> you received this message in error, please contact the sender immediately
> and delete all copies of the message. Thank you from Connamara Systems, LLC.
> _______________________________________________
> Quickfixn mailing list
> 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/20200902/53afeb32/attachment.htm>
-------------- next part --------------
       public void OnMessage(QuickFix.FIX44.ExecutionReport OrderExecutionReport, SessionID s)
        {

            int fxallStatus = 0;
            string fxhedgeSummary_Id = string.Empty;
            string exportFileName = string.Empty;

            try
            {
                #region Save the FIX Message String and OrderExeuction Report from FXALL  - for our internal purpose
                try
                {
                    fxallStatus = client.InsertFXALLMessages(DateTime.Now, Convert.ToString(OrderExecutionReport));

                    if (fxallStatus > 0)
                    {
                        logFile.WriteErrorLog("FXALL FIX message insert successfully");
                        DataSet dsfxallExecReportFields = client.GetFxallExecutionReportFields(); //SP will check if the fix message present for today
                        if (dsfxallExecReportFields.Tables[0].Rows.Count > 0)
                        {
                            logFile.WriteErrorLog("FXALL FIX execution report inserted successfully");
                        }
                    }
                }
                catch (SqlException ex)
                {
                    logFile.WriteErrorLog("FXALL order execution report - FIX message string insert failed " + ex.Message.ToString());
                }
                #endregion

                #region Update/Insert internal OMS tables 
                try
                {
		    //SP will process the execution report and updates back to internal OMS tables respectively
                    int fxHedgeSumHeader_Detail_Status = client.InsertUpdate_FxHedgeSummaryHeaderDetail(); 

                    if (fxHedgeSumHeader_Detail_Status > 0)
                    {
                        logFile.WriteErrorLog("FxHedge Summary Header/Detail Update/Insert Success");

                    }
                }
                catch (SqlException e)
                {
                    logFile.WriteErrorLog("FxHedge Summary Header/Detail Update/Insert failed " + e.Message.ToString());
                }
                #endregion

            }
            catch (Exception ex)
            {
                logFile.WriteErrorLog("OrderExeuction Report and FxHedge Summary Header/Detail insert failed" + ex.Message.ToString());

            }
        }


More information about the Quickfixn mailing list