{{Quickfixn}} Issue 22

Wed May 23 11:08:06 PDT 2012

I'm pretty sure you're correct.  We didn't fix anything in that area,
because we couldn't confirm the bug.

On Wed, May 23, 2012 at 1:03 PM, Matt Wood <mjwood7 at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120523/ee2954e2/attachment-0002.htm>