Re: [Quickfix-developers] Network disconnect recovery testing

[Mike G. <mg...@co...>]

Dermot,

This is one of the reasons the qf/j implementation has config options like
JdbcLogHeartBeats/FileLogHeartbeats.
I don't think it would be too hard to add this to MySQLLog for qf/c++.

--
Mike Gatny
Connamara Systems, LLC

On Thu, Apr 13, 2017 at 11:18 AM, <daw...@ya...> wrote:

> Hi Mike,
>
> Thanks for the quick response. I haven't included PersistMessages in the
> config file but I can see it defaults to 'N' so that makes sense.
>
> Ok noted on the onLogon()/onLogout(). Up to now I've just been catching
> the event text "Received logon response" and "Disconnecting" which is a bit
> hacky but the result is the same. The only issue I have is I've been trying
> to keep HeartBtInt=120 so as not to flood MySql with too many messages -
> this means that it takes a minute or two for quickfix to realise there's a
> network problem and disconnect and in the meantime my app will still be
> sending orders. I guess I can't have my cake and eat it so if I want to
> catch it sooner I'll have to up the heartbeat frequency, right?
>
> Dermot
>
>
>
> ----- Original Message -----
> *From:* Mike Gatny <mg...@co...>
> *To:* daw...@ya...
> *Cc:* Grant Birchmeier <gbi...@co...>; "
> qui...@li..." <quickfix-developers@lists.
> sourceforge.net>
> *Date:* 2017/4/13, Thu 23:55
> *Subject:* Re: Network disconnect recovery testing
>
> Dermot,
>
> Have you set PersistMessages=N in your SessionSettings? This is one way
> to prevent resend (i.e. cause GapFill over App-level msgs).
>
> Another way is to throw DoNotSend in toApp for possdup msgs:
>
> *void App::toApp(FIX::Message& msg, const
> FIX::SessionID&) throw(FIX::DoNotSend)*
> *{*
> *  try *
> *  {*
> *    FIX::PossDupFlag possDupFlag;*
>     *msg**.getHeader().getField(possDupFlag);*
> *    if (possDupFlag)*
> *      throw FIX::DoNotSend();*
> *  }*
> *  catch (FIX::FieldNotFound&)*
> *  { }*
> *}*
>
>
> As you say, this is almost certainly the behavior you want for sending
> orders, and that's the two main ways to achieve it.  If you are not doing
> either of those things, QF will indeed resend instead of sending GapFills.
>
> If you want to detect a connection problem, you can use onLogon() and
> onLogout() to alert or set some state.  You can think of onLogout() as
> "onDisconnect" as well -- it will get called even if you didn't get a clean
> Logout.
> Another way to do it on the fly is:
>
> *FIX::Session * pSession = FIX::Session::lookupSession(sessionID);*
> *if (pSession->isLoggedOn()) { /* ... */  }*
>
>
> --
> Mike Gatny
> Connamara Systems, LLC
>
> On Thu, Apr 13, 2017 at 10:37 AM, <daw...@ya...> wrote:
>
> Hi Guys, I've been doing some recovery testing and I have a couple of
> questions.
>
> Firstly, my setup is pretty simple - my trading application (initiator)
> and sell-side simulator (acceptor) are set up on two different networked
> machines, both are quickfix apps. Here's what I'm doing:-
>
> 1. Establish a connection between initiator and acceptor.
> 2. Send some orders and ack them on the acceptor side.
> 2. Break the network connection on the initiator side.
> 3. Send some more orders from the initiator.
> 4. Fill existing orders on acceptor side.
> 5. Reconnect the initiator to the network.
>
> At this point quickfix handles the reconnect and all the executions flow
> back to the initiator. However the new orders I sent from the initiator
> during the downtime are not resent to the executor [they are gap filled
> instead]. Is this the correct behaviour? Actually this is exactly the
> behaviour I want but I thought quickfix would resend them. So that's my
> first question.
>
> My second question is what is the best way to determine a connection
> problem before sending any order?
>
> Thanks!
> Dermot
>
>
>
>
>