Re: [Quickfix-developers] Network disconnect recovery testing

[<daw...@ya...>]

Got it. Will take a look at that. Thanks a lot.
Dermot


----- Original Message -----
>From: Mike Gatny <mg...@co...>
>To: daw...@ya... 
>Cc: Grant Birchmeier <gbi...@co...>; "qui...@li..." <qui...@li...>
>Date: 2017/4/14, Fri 00:31
>Subject: Re: Network disconnect recovery testing
> 
>
>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...>; "quickfix-developers@lists. sourceforge.net" <quickfix-developers@lists. sourceforge.net>
>>>Date: 2017/4/13, Thu 23:55
>>>Subject: Re: Network disconnect recovery testing
>>> 
>>>
>>>Dermot,
>>>
>>>
>>>Have you set PersistMessages=Nin your SessionSettings? This is one way to prevent resend (i.e. cause GapFill over App-level msgs).
>>>
>>>
>>>Another way is to throw DoNotSendin 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
>>>
>>>
>>>
>
>
>