{{Quickfixn}} Issue 22

[Matt Wood]

I was running a relatively recent snapshot of the repo, probably only a few
days before the recent release. In any event, I've updated to the latest.
Looking quickly, it seems that the particular part of the code in question
was untouched between the version I experienced the problem on and the
latest. Regardless, I'll verify that it happens tomorrow to be sure.

-Matt

On Wed, May 23, 2012 at 1:06 PM, Grant Birchmeier <gbirchmeier at connamara.com
> wrote:

> I guess you're done here then.  See you around.
>
>
> On Wed, May 23, 2012 at 12:05 PM, Thomas Tomiczek <
> t.tomiczek at nettecture.com> wrote:
>
>>  Great ;) SO happy I am not getting market data with FIX or Fast then ;)
>>
>>
>>
>> Mine actually DOES redeliver everything ;) Every tick on all 200.000 or
>> so symbols it tracks ;)
>>
>>
>>
>> *From:* quickfixn-bounces at lists.quickfixn.com [mailto:
>> quickfixn-bounces at lists.quickfixn.com] *On Behalf Of *Grant Birchmeier
>> *Sent:* 23 May 2012 19:04
>>
>> *To:* Mailing list for QuickFIX/n
>> *Subject:* Re: {{Quickfixn}} Issue 22
>>
>>
>>
>> Between EndTime and StartTime, the acceptor will refuse all connections.
>>  The initiator should not even try.
>>
>>
>>
>> The session's first connection after StartTime should start both seq
>> numbers at 1.  No exceptions.
>>
>>
>>
>> In a persistent session, there should be some catch-up behavior on
>> reconnection, but only as it pertains to sequence numbers of messages that
>> you didn't get.  If you're monitoring market data, for example, and your
>> client goes down for 3 minutes, the acceptor probably won't spend that 3
>> minutes queuing up messages to send you on reconnection.  I mean, they
>> could, but they probably won't.  Most likely, they stopped sending anything
>> the second you went down, and you're recovery will consist of only the few
>> messages that were in transit when you went down.  (There may be acceptors
>> that work differently, but this scenario is more inline with my
>> experiences.)
>>
>>
>>
>> As always, don't assume anything about your counterparty's FIX interface.
>>  Check their specs.  FIX is an extraordinarily flexible protocol.
>>
>>
>>
>> -Grant
>>
>>
>>
>>
>>
>> On Wed, May 23, 2012 at 11:39 AM, Thomas Tomiczek <
>> t.tomiczek at nettecture.com> wrote:
>>
>> As someone new to FIX _ how SHOULD it be have?
>>
>>
>>
>> If the session is persistent, then should it not continue playing back
>> the stored messages?
>>
>>
>>
>> Imagine at 23:14 internet goes down – then 23:15 I do not get the rest of
>> the data?
>>
>>
>>
>> That sounds to me like a normal continuation behaviour – at least how I
>> would have done it. Keep numbers until next start time ;)
>>
>>
>>
>> Just talking  here- but one thing that really interests me. Because I
>> just happen to sit behind internet connections going down to the MOST
>> inconvenient time. I am SURE if that would session parameters for me, and I
>> would have a machine in my office relying on that, next day I would get
>> exactly this down time. ;)
>>
>>
>>
>> *From:* quickfixn-bounces at lists.quickfixn.com [mailto:
>> quickfixn-bounces at lists.quickfixn.com] *On Behalf Of *Grant Birchmeier
>> *Sent:* 23 May 2012 18:22
>> *To:* Mailing list for QuickFIX/n
>> *Subject:* Re: {{Quickfixn}} Issue 22
>>
>>
>>
>> Hm... you're ending *before* EndTime, then manually starting *after*
>> EndTime...?
>>
>>
>>
>> That might be the bit of info we were lacking.  Myself, I was only
>> checking on the auto-start/end that is triggered when the times are reached.
>>
>>
>>
>> I'd hope that it's using the same startup-time checking code regardless
>> of whether it's started manually or automatically, but it's possible it's
>> not.
>>
>>
>>
>> I've added this info to the issue.  Will have to make time to give it a
>> shot later.
>>
>>
>>
>> (You are using the new release, right?)
>>
>>
>>
>> -Grant
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 23, 2012 at 11:13 AM, Matt Wood <mjwood7 at gmail.com> wrote:
>>
>> Related to issue 22:
>>
>> https://github.com/connamara/quickfixn/issues/22
>>
>>
>>
>>
>>
>> I believe I'm also encountering this. Basically if I'm manually
>> disconnecting a session before EndTime, then manually starting it up again
>> after StartTime on the following day, my session doesn't get reset.
>> QuickfixN throws the "MsgSeqNum too low, expecting... " message. Relevant
>> config values are included below:
>>
>>
>>
>> config.cfg:
>>
>>
>>
>> [DEFAULT]
>>
>> ConnectionType=initiator
>>
>> StartDay=monday
>>
>> EndDay=friday
>>
>> StartTime=11:00:00
>>
>> EndTime=23:15:00
>>
>> ResetOnLogon=N
>>
>> ResetOnLogout=N
>>
>> ResetOnDisconnect=N
>>
>>
>>
>> I took a look into the code prior to running into "Session.Verify(Message
>> logon, false, true)" and I haven't found state_.Reset() being called for
>> this type of scenario (logoff before EndTime, logon after StartTime the
>> next day). Could anyone verify this?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Matt
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> --
>>
>> 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
>>
>>
>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120523/d4b083d6/attachment-0002.htm>