Re: [Quickfix-developers] 1.9.3 release date??

[Oren M. <or...@qu...>]

What we have in CVS is the 1.9.3 release candidate.  This will be the =20=

release once we are happy with it.  The current expectation is the =20
release will go out this week.

--oren

On Nov 2, 2004, at 1:01 AM, Shamanth wrote:

> Hi Oren
>
> Can you give a rough idea of when we can expect 1.9.3 release of =20
> quickfix. I very badly want to use the weeklong session feature of =20
> 1.9.2, but am unable to do so due the the problem of "body length =20
> mismatch" error in 1.9.2.
>
> Please refer the attached mails for the problems I am facing.
>
> thansk
>  R Shamanth
>
>
>
>
>
>  <<Re: [Quickfix-users] Logon Ack seqNo>> <<Re: [Quickfix-users] 1.9.2 =
=20
> body lenght mismatch>>
>
> From: "Oren Miller" <or...@qu...>
> Date: October 19, 2004 10:05:58 AM CDT
> To: "Oren Miller" <or...@qu...>
> Cc: <qui...@li...>, "Shamanth" =20
> <sha...@in...>, <qui...@li...>
> Subject: Re: [Quickfix-users] Logon Ack seqNo
>
>
> Correction:
>
>
>
>  That condition should read, 'endSeqNo >=3D getExpectedSenderNum()'
>
>
>
>  On Oct 19, 2004, at 9:59 AM, Oren Miller wrote:
>
>
>
>  Answer1:
>
>
>
>  No. This is in fact normal behavior. Whenever a message is sent the =20=

> sequence number has to be incremented. Just because we did not receive =
=20
> an ack, does not necessarily mean the counter-party did not receive =20=

> the logon. If the sequence number was not incremented, and they had =20=

> actually received it without acknowledging, you would then encounter =20=

> disconnect scenarios due to too low sequence numbers at some point. A =20=

> much worse position to be in as it cannot be resolved automatically.
>
>
>
>  Having a sequence number that is too high isn't much of a problem =20
> since the two engines can resolve this on their own. And since in this =
=20
> case we are talking about logon messages, all that is required is a =20=

> single gap fill message to put everything in order.
>
>
>
>  Answer2:
>
>
>
>  Depends on the version. For FIX.4.2 and higher, the value should be =20=

> 0. For versions 4.1 and earlier, a special value of 999999 is used. =20=

> I'm a bit curious as to what is going on here. Is both the initiator =20=

> and acceptor QuickFIX. It seems strange because since QuickFIX 1.6, =20=

> the EndSeqNo is always send either 0 or 999999, never another value. =20=

> Based on this I'm guessing the acceptor in this scenario is not =20
> QuickFIX, is this correct?
>
>
>
>  As to the effect of the value 2147483647, I suspect your application =20=

> has stopped responding because you now got the message store trying to =
=20
> look up a hell of a lot of messages in a tight loop. I suspect we can =20=

> have QuickFIX handle this situation more gracefully if we consider =20
> such a situation equivalent to an infinite request as such:
>
>
>
>  if ( beginString >=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 0 ||
>
>  beginString <=3D FIX::BeginString_FIX42 && endSeqNo =3D=3D 999999 ||
>
>  endSeqNo >=3D getExpectedSeqNum() ) // new condition to handle =20
> bizarrely large numbers
>
>  { endSeqNo =3D getExpectedSenderNum() - 1; }
>
>
>
>
>  On Oct 19, 2004, at 7:08 AM, Shamanth wrote:
>
>
>
>
> Hi
>
>
>
> I am using quickfix 1.8,
>
>
>
> While testing due to some network problems we got disconnected from =20=

> the "Acceptor". In the mean time, our "initiator" tried reconnecting =20=

> to the "acceptor" every 30secs.
>
>
>
> It tried it 8 times before it could get an ack for its logon message.
>
>
>
>
> Problem1: Our initiator, sent 8 logon messages and only the 9th logon =20=

> message was ack by the acceptor. But in the meantime, our initiator =20=

> incremented its MsgSeqNo, so when both the initiator and acceptor got =20=

> connected, there was a mismatch of SeqNo, and the =E2=80=9Cacceptor=E2=80=
=9D send a =20
> resendRequest to the =E2=80=9Cinitiator=E2=80=9D
>
>
>
> Question: Is there a way we can prevent the quickfix initiator from =20=

> incrementing its SeqNo, if it did not receive Ack for its Logon msg.
>
>
>
> NOTE: Only the SeqNo of the messages sent was incremented, while the =20=

> SeqNo of the messages received was correct.
>
>
>
>
>
> Problem2: After connecting again the Acceptor sent, a resend request =20=

> FROM: 0 TO: 2147483647, our initiator had not sent so many messages, =20=

> so it considers it as an error condition and stops responding to the =20=

> acceptor. Is =E2=80=9C2147483647=E2=80=9D the maximum value in resend =
request as per =20
> fix protocol or should =E2=80=9C0=E2=80=9D(infinity) be considered as =
the max valueis =20
> considered as the maximum number?
>
>
>
>
> thanks
>
>
>
>
> R Shamanth
>
>
> From: "Oren Miller" <or...@qu...>
> Date: October 20, 2004 9:56:52 AM CDT
> To: "Shamanth" <sha...@in...>
> Cc: <qui...@li...>, =20
> <qui...@li...>
> Subject: Re: [Quickfix-users] 1.9.2 body lenght mismatch
>
>
> Shamanth,
>
>
>
>  This looks like a problem that has been fixed. The fix is available =20=

> in CVS and will be released with 1.9.3
>
>
>
>  --oren
>
>
>
>  On Oct 20, 2004, at 4:23 AM, Shamanth wrote:
>
>
>
>  Hi
>
> =C2=A0
>
>  I am currently using quickfix 1.8, I wanted to upgrade to 1.9.2, so I =
=20
> downloaded the source and build them in windows.
>
> Both my Initiator and Acceptor are quickfix 1.9.2, I use JNI wrappers, =
=20
> and not the C++ code directly
>
> =C2=A0
>
>  Problem:
>
> When I send a MarketDataRequest, I get the following error in the =20
> Acceptor, I have pasted the original message also below.
>
> =C2=A0
>
>  <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, incoming>
>
> =
=C2=A0(8=3DFIX.4.2=E2=98=BA9=3D151=E2=98=BA35=3DV=E2=98=BA34=3D2=E2=98=BA4=
9=3DITLClientMD=E2=98=BA52=3D2004102008:37:=20
> =
50.617=E2=98=BA56=3DITLServer=E2=98=BA146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA=
146=3D1=E2=98=BA55=3DEUR/USD=E2=98=BA146=3D1=E2=98=BA55=3DEUR/=20
> =
USD=E2=98=BA262=3D123456=E2=98=BA263=3D1=E2=98=BA264=3D0=E2=98=BA265=3D1=E2=
=98=BA267=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA267=3D2=E2=98=BA269=3D=
0=E2=98=BA269=3D1=E2=98=BA26=20
> 7=3D2=E2=98=BA269=3D0=E2=98=BA269=3D1=E2=98=BA10=3D165=E2=98=BA)
>
> <20041020-08:37:50, FIX.4.2:ITLServer->ITLClientMD, event>
>
> =C2=A0 (Invalid message: Expected BodyLength=3D197, Recieved =
BodyLength=3D151)
>
> =C2=A0
>
>  In my initiator log, I am printing the XML of the message before =20
> sending, I see that it is not getting resolved properly
>
> <message>
>
>
>
> =C2=A0 <header>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8"><![CDATA[FIX.4.2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35"><![CDATA[V]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34"><![CDATA[2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49"><![CDATA[ITLClientMD]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field =
number=3D"52"><![CDATA[20041020-08:37:50.617]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56"><![CDATA[ITLServer]]></field>
>
>
>
> =C2=A0 </header>
>
>
>
> =C2=A0 <body>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262"><![CDATA[123456]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264"><![CDATA[0]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267"><![CDATA[2]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"55"><![CDATA[EUR/USD]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[0]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field =
number=3D"269"><![CDATA[1]]></field>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0 </body>
>
>
>
> =C2=A0 <trailer>
>
>
>
> =C2=A0 </trailer>
>
>
>
> =C2=A0
>
>  Note: If I replace the quickfix.jar, quickfix.lib and =20
> quickfix_jni.dll of 1.8, then every thing works fine. I notice this =20=

> problem only with 1.9.2 jars and dlls.
>
> =C2=A0
>
>  This is how the XML looks with 1.8 jars and dlls
>
> =C2=A0
>
>  <message>
>
>
>
> =C2=A0 <header>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"8" value=3D"FIX.4.2"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"35" value=3D"V"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"34" value=3D"2"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"49" value=3D"ITLClientMD"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"52" =
value=3D"20041020-08:47:49.679"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"56" value=3D"ITLServer"/>
>
>
>
> =C2=A0 </header>
>
>
>
> =C2=A0 <body>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"146" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"262" value=3D"123456"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"263" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"264" value=3D"0"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"265" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <field number=3D"267" value=3D"2"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"55" value=3D"EUR/USD"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"0"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0=C2=A0=C2=A0 <group>
>
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <field number=3D"269" value=3D"1"/>
>
>
>
> =C2=A0=C2=A0=C2=A0 </group>
>
>
>
> =C2=A0 </body>
>
>
>
> =C2=A0 <trailer>
>
>
>
> =C2=A0 </trailer>
>
>
>
> </message>
>
>
>
> =C2=A0
>
>  any idea what could be the problem, has any one else faced the same =20=

> problem.
>
> =C2=A0
>
>  thanks
>
> R Shamanth