RE: [Quickfix-developers] Incorrect handling of SequenceReset

[Ajay K. <Aja...@tr...>]

-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...]=20
Sent: Saturday, April 29, 2006 8:10 AM
To: Ajay Kamdar
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Incorrect handling of SequenceReset


On 4/28/06, Ajay Kamdar <Aja...@tr...> wrote:
>
> I am testing QuickFIX 1.11.0 to see if I can use it for a new project=20
> instead of our current production FIX engine. During my tests I saw=20
> incorrect behavior in QuickFIX's handling of a SequenceReset message.=20
> It looks like (a) QuickFIX failed to reset its next expted target=20
> number in response to a SequenceReset, and (b) subsequenly refused to=20
> send another resend request for ever because it had already sent a=20
> previous resend request. I saw this happen once, but unfortunately=20
> can't reproduce it consistently. Is this something that rings a bell=20
> with anyone?

Given the event log you included, the application clearly received and
processed the SequenceReset and looking at the code, there's nothing
else that could happen but it changing the state's next expected
sequence number.

What sort of Store are you using for this NullApplication?  Perhaps its
not behaving correctly w/r/t updating sequence numbers.

Given that there are extensive tests to exercise SequenceResets, it
seems likely that there is something in your application or
configuration thats leading to this behavior.


<snip>

In practice, the Session should eventually disconnect due to heartbeat
timeouts if the SequenceReset isn't processed properly.  Did you wait
long enough for this to happen in your tests?

> Here's the relevant excerpt from the FIX message and event log:
>
> 20060428-15:41:27 Incoming FIX :=20
> =
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D5=0149=3DCAPISIM=0152=3D20060428-15:=
41:27.349=0156=3DCAPIGW
> =0110=3D166=01
> 20060428-15:41:27 : MsgSeqNum too high, expecting 1 but received 5
> 20060428-15:41:27 Outgoing FIX :
>
8=3DFIX.4.4=019=3D65=0135=3D2=0134=3D6=0149=3DCAPIGW=0152=3D20060428-15:4=
1:27.349=0156=3DCAPISIM=017
=3D1=0116=3D0=0110=3D036=01
> 20060428-15:41:27 : Sent ResendRequest FROM: 1 TO: 0
> 20060428-15:41:27 Incoming FIX :
>
8=3DFIX.4.4=019=3D98=0135=3D4=0134=3D1=0143=3DY=0149=3DCAPISIM=0152=3D200=
60428-15:41:27.349=0156=3DCAP
IGW=01122=3D20060428-15:41:27.349=0136=3D6=01123=3DY=0110=3D192=01
> 20060428-15:41:27 : Received SequenceReset FROM: 1 TO: 6
> 20060428-15:41:57 Incoming FIX :
>
8=3DFIX.4.4=019=3D56=0135=3D0=0134=3D6=0149=3DCAPISIM=0152=3D20060428-15:=
41:57.349=0156=3DCAPIGW=011
0=3D170=01
> 20060428-15:41:57 : MsgSeqNum too high, expecting 1 but received 6

This makes me suspect something wrong with your Application's Store.=20
Clearly QF handled the SequenceReset above, so it should be expecting
SeqNum 6 here.

--
Caleb Epstein
caleb dot epstein at gmail dot com

Caleb,

For these tests I was using the builtin FIX::FileStoreFactory and the
builtin FIX::NullApplication. The SequenceReset was received at
15:41:27, and then the "Already sent Resend Request" message kept on
showing up every 30 seconds upon every heartbeat (there was no other
traffic) until 15:48:57 after which I disconnected the session manually.


Unfortunately other than this one instance, I have been unable to
reproduce the problem. I have included the configuration below in case
something stands out.=20

Thanks,

- Ajay

[DEFAULT]
ConnectionType=3Dacceptor
SocketAcceptPort=3D5001
FileStorePath=3Dstore
FileLogPath=3Dlog
StartTime=3D00:00:00
EndTime=3D00:00:00
MillisecondsInTimeStamp=3DY	=09
DataDictionary=3Dspec/FIX44.xml
UseDataDictionary=3DY
SocketNodelay=3DY
ResetOnLogout=3DY				I
ResetOnDisconnect=3DY		=09
SendResetSeqNumFlag=3DY			# undocumented flag

[SESSION]
BeginString=3DFIX.4.4
ConnectionType=3Dinitiator
SenderCompID=3DCAPISIM
TargetCompID=3DCAPIGW
SocketConnectHost=3Dlocalhost
SocketConnectPort=3D5001
HeartBtInt=3D30			=09
ReconnectInterval=3D30		=09
SendResetSeqNumFlag=3DY			# undocumented flag

[SESSION]
BeginString=3DFIX.4.4
SenderCompID=3DCAPIGW
TargetCompID=3DCAPISIM

-------------------------------------------------------------------------=
--

The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by anyone =
else
is unauthorized. If you are not the intended recipient, any disclosure, =
copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.

TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.