{{Quickfixn}} Acceptor not reacting to tag 141 (ResetSeqNumFlag) in logon request

Mon May 14 06:37:28 PDT 2012

Hi Grant,

Thank you for your reaction. Please find attached the following 6 files:

initiator.cfg, initiator.event.log, initiator.messages.log,
acceptor.cfg, acceptor.event.log and acceptor.messages.log.

Please note that I'm streaming the config into the SessionSettings, instead of
actually using a file on disk to contain the config.

Kind regards,
        Remco de Koning

On Sun, May 13, 2012 at 09:25, Grant Birchmeier <mailto:quickfixn%40lists.quickfixn.com?Subject=Re%3A%20%7B%7BQuickfixn%7D%7D%20Acceptor%20not%20reacting%20to%20tag%20141%0A%20%28ResetSeqNumFlag%29%20in%20logon%20request&In-Reply-To=%3CCAMq4opM5Rq2ExSgqJZP-bnGqvHKWWnm8NOHieo7p91ynUSczRg%40mail.gmail.com%3E> wrote:

> Hi Can you send the message logs from each?  Just the first few lines with the
> login messages and a little after should be enough.
>
> Also, please send the configurations for each side.
>
> -Grant

> On Sat, May 12, 2012 at 4:35 PM, Remco de Koning <remco at solid-trading.com<http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com>>wrote:

>> Hi all,
>>
>>
>>
>> I'm new to this mailing list, so I'm not quite sure whether this question
>> was already asked and answered, so I'll give it a try.
>>
>>
>>
>> I have an acceptor and an initiator that are both using the QuickFIXn
>> library (new release 1.2.0). When the initiator is sending
>>
>> a logon request, it sends tag 141(ResetSeqNumFlag)=Y, as it wants to reset
>> the sequence numbers. The acceptor seems to
>>
>> ignore this flag which could lead to sequence numbers not being, nor
>> becoming, in sync. A short snip from the event.log and
>>
>> the messages.log (note: SFX_ADMIN_INTERFACE is the acceptor, CPPTestClient
>> is the initiator):
>>
>>
>>
>> Event.log
>>
>> 20120512-21:12:40.675 : Connecting to 127.0.0.1 on port 9500
>>
>> 20120512-21:12:40.675 : Connection succeeded
>>
>> 20120512-21:12:40.706 : Initiated logon request
>>
>> 20120512-21:12:40.768 : Received logout request
>>
>> 20120512-21:12:40.768 : Sending logout response
>>
>> 20120512-21:12:40.768 : Session
>> FIX.4.2:CPPTestClient->>SFX_ADMIN_INTERFACE disconnecting: Received logout
>> request
>>
>> Messages.log
>>
>> 20120512-21:12:40.706 : 8=FIX.4.29=9335=A34=149=CPPTestClient52=
>> 20120512-21:12:40.69056=SFX_ADMIN_INTERFACE98=0108=30141=Y10=174
>>
>> 20120512-21:12:40.768 : 8=FIX.4.29=12635=534=71549=SFX_ADMIN_INTERFACE52=
>> 20120512-21:12:40.76856=CPPTestClient58=MsgSeqNum too low, expecting 9
>> but received 110=153
>>
>> 20120512-21:12:40.768 : 8=FIX.4.29=7535=534=249=CPPTestClient52=
>> 20120512-21:12:40.76856=SFX_ADMIN_INTERFACE10=099
>>
>>
>>
>> I had expected a logon-response such as the following (actually copied
>> from older logs, when the same acceptor was linked to the old .NET wrapper
>>
>> around the C++ version of QuickFIX):
>>
>> 20120507-08:24:31.401 : 8=FIX.4.29=9335=A34=149=BigBoss_Keiga52=
>> 20120507-08:24:31.37056=SFX_ADMIN_INTERFACE98=0108=30141=Y10=188
>>
>> 20120507-08:24:31.401 : 8=FIX.4.29=9335=A34=149=SFX_ADMIN_INTERFACE52=
>> 20120507-08:24:31.40156=BigBoss_Keiga98=0108=30141=Y10=183
>>
>>
>>
>> I am able to fix this in the code of the library (actually in the
>> NextLogon-method of Session.cs) by replacing the line
>>
>> if (!state_.IsInitiator && this.ResetOnLogon)
>>
>> with
>>
>> if (!state_.IsInitiator && (this.ResetOnLogon || state_.ReceivedReset))
>>
>> which leads to a behavior that seems to work:
>>
>> 20120512-21:13:59.908 : 8=FIX.4.29=9335=A34=149=CPPTestClient52=
>> 20120512-21:13:59.84556=SFX_ADMIN_INTERFACE98=0108=30141=Y10=187
>>
>> 20120512-21:14:00.095 : 8=FIX.4.29=9335=A34=149=SFX_ADMIN_INTERFACE52=
>> 20120512-21:14:00.06456=CPPTestClient98=0108=30141=Y10=167
>>
>>
>>
>> My question is the following: Have any of you ran into the same situation
>> and  - if so - how did you solve it? I doubt that my change in the code is
>> the correct
>>
>> way to solve it ...
>>
>>
>>
>>
>>
>> Kind regards,
>>
>>                 Remco de Koning

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120514/0dbff6b4/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initiator.cfg
Type: application/octet-stream
Size: 532 bytes
Desc: initiator.cfg
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120514/0dbff6b4/attachment-0012.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initiator.event.log
Type: application/octet-stream
Size: 1366 bytes
Desc: initiator.event.log
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120514/0dbff6b4/attachment-0013.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initiator.messages.log
Type: application/octet-stream
Size: 1754 bytes
Desc: initiator.messages.log
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120514/0dbff6b4/attachment-0014.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acceptor.cfg
Type: application/octet-stream
Size: 704 bytes
Desc: acceptor.cfg
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120514/0dbff6b4/attachment-0015.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acceptor.event.log
Type: application/octet-stream
Size: 2061 bytes
Desc: acceptor.event.log
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120514/0dbff6b4/attachment-0016.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: acceptor.messages.log
Type: application/octet-stream
Size: 1266 bytes
Desc: acceptor.messages.log
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120514/0dbff6b4/attachment-0017.obj>