[Quickfix-developers] frustrating "problem" with Resend Request

[Shawn Y. <sya...@ge...>]

I'm dealing with an exchange that uses a broken FIX.4.2
implementation.  After working around some issues, I'm
stuck on this one.

The exchange believes that every exchange message
following a gap in the sequence numbers should trigger
a Resend Request from my client, apparently until the
gap has been fully resent.

QuickFIX has code in file Session.cpp, member function
Session::doTargetTooHigh(), around line 1500, to
prevent exactly the redundant Resend Requests that
this exchange requires.

I believe QuickFIX is correct, but is there an easy way
for me to workaround this behavior so that QuickFIX
will send the redundant Resend Requests?

Logs included below so you can see what I'm talking
about.  The missing messages are numbered 6, 7, and 8.
They all get properly resent by the exchange even with
my client only sending a single Resend Request (third
message in the log below).

The exchange believes the fourth message in the log
(exchange message numbered 10) should trigger another
Resend Request even though as you can see the bottom
three messages are the successfully-resent messages
coming in.  The exchange doesn't look like they are
going to budge even though QuickFIX probably knows
better than they do what's correct.

If anyone can suggest an easy workaround not
requiring changes to QuickFIX code, I could really
use it.



20060412-00:08:15 : Created session
20060412-00:08:15 : Connecting to 10.1.63.82 on port 7001
20060412-00:08:15 : Connection succeeded
20060412-00:08:15 : Initiated logon request
20060412-00:08:21 : Received logon response
20060412-00:08:21 : MsgSeqNum too high, expecting 6 but received 9
20060412-00:08:21 : Sent ResendRequest FROM: 6 TO: 0
20060412-00:08:21 : MsgSeqNum too high, expecting 6 but received 10
20060412-00:08:21 : Already sent ResendRequest FROM: 6 TO: 8. Not =
sending another.
20060412-00:08:25 : ResendRequest for messages FROM: 6 TO: 8 has been =
satisfied.



8=3DFIX.4.2|9=3D98|35=3DA|34=3D6|49=3DJ79519N|50=3DLZL|52=3D20060412-00:0=
8:15.899|56=3DCME|57=3DG|142=3D3|95=3D6|96=3D???|98=3D0|108=3D30|10=3D102=
|

8=3DFIX.4.2|9=3D79|35=3DA|49=3DCME|56=3DJ79519N|52=3D20060412-00:08:21|34=
=3D9|369=3D6|50=3DG|57=3DLZL|108=3D30|98=3D0|10=3D080|

8=3DFIX.4.2|9=3D80|35=3D2|34=3D7|49=3DJ79519N|50=3DLZL|52=3D20060412-00:0=
8:21.304|56=3DCME|57=3DG|142=3D3|7=3D6|16=3D0|10=3D085|

8=3DFIX.4.2|9=3D86|35=3D1|49=3DCME|56=3DJ79519N|52=3D20060412-00:08:21|34=
=3D10|369=3D6|50=3DG|57=3DLZL|112=3D1144800501323|10=3D175|

8=3DFIX.4.2|9=3D288|35=3D8|43=3DY|122=3D20060412-00:08:00|34=3D6|49=3DCME=
|56=3DJ79519N|52=3D20060412-00:08:25|369=3D7|50=3DG|1=3D1234|6=3D0|11=3D0=
000C|17=3D0020060411080743TN0064|20=3D0|31=3D102975|32=3D1|37=3D200604110=
034|38=3D1|39=3D2|40=3D2|41=3D0|44=3D102975|54=3D1|55=3DES|60=3D20060412-=
00:07:43|75=3D20060411|107=3DESM6|150=3D2|151=3D0|14=3D0|167=3DFUT|9717=3D=
0000C|10=3D096|

8=3DFIX.4.2|9=3D288|35=3D8|43=3DY|122=3D20060412-00:08:00|34=3D7|49=3DCME=
|56=3DJ79519N|52=3D20060412-00:08:25|369=3D7|50=3DG|1=3D1234|6=3D0|11=3D0=
000D|17=3D0020060411080751TN0066|20=3D0|31=3D102975|32=3D1|37=3D200604110=
035|38=3D1|39=3D2|40=3D2|41=3D0|44=3D102975|54=3D1|55=3DES|60=3D20060412-=
00:07:51|75=3D20060411|107=3DESM6|150=3D2|151=3D0|14=3D0|167=3DFUT|9717=3D=
0000D|10=3D100|

8=3DFIX.4.2|9=3D288|35=3D8|43=3DY|122=3D20060412-00:08:00|34=3D8|49=3DCME=
|56=3DJ79519N|52=3D20060412-00:08:25|369=3D7|50=3DG|1=3D1234|6=3D0|11=3D0=
000E|17=3D0020060411080800TN0068|20=3D0|31=3D102975|32=3D1|37=3D200604110=
036|38=3D1|39=3D2|40=3D2|41=3D0|44=3D102975|54=3D1|55=3DES|60=3D20060412-=
00:08:00|75=3D20060411|107=3DESM6|150=3D2|151=3D0|14=3D0|167=3DFUT|9717=3D=
0000E|10=3D096|



Thanks,

Shawn Yarbrough
Senior E-Trading Developer
Gelber Group, LLC
sya...@ge...