Re: [Quickfixj-users] Logon and resend after connection lost

[Nick F. <Nic...@ve...>]

I'm taking this up with the counterparty, but there is a quickfix
related issue here to I think, related to quickfix's resend request. The
code in Session.java has:

=20

    private void generateResendRequest(String beginString, int
msgSeqNum) {

        Message resendRequest =3D messageFactory.create(beginString,
MsgType.RESEND_REQUEST);

        int beginSeqNo =3D getExpectedTargetNum();

        int endSeqNo =3D msgSeqNum - 1; // Why initialized when it will =
be

        // overwritten

        if (beginString.compareTo("FIX.4.2") >=3D 0) {

            endSeqNo =3D 0;

        } else if (beginString.compareTo("FIX.4.1") <=3D 0) {

            endSeqNo =3D 999999;

        }

        resendRequest.setInt(BeginSeqNo.FIELD, beginSeqNo);

        resendRequest.setInt(EndSeqNo.FIELD, endSeqNo);

        initializeHeader(resendRequest.getHeader());

        sendRaw(resendRequest, 0);

        getLog().onEvent("Sent ResendRequest FROM: " + beginSeqNo + "
TO: " + endSeqNo);

        state.setResendRange(beginSeqNo, msgSeqNum - 1);

    }

=20

I don't understand why it has these lines:

=20

        if (beginString.compareTo("FIX.4.2") >=3D 0) {

            endSeqNo =3D 0;

        } else if (beginString.compareTo("FIX.4.1") <=3D 0) {

            endSeqNo =3D 999999;

        }

=20

The line before, setting it to msgSeqNum-1 seems much more correct, and
more consistent with the state.setResendRange(beginSeqNo, msgSeqNum - 1)
code as well. Hopefully if the counterparty responded with a GapFill for
just these, then any messages coming afterwards would not be lost.

=20

Nick=20

=20

=20

________________________________

From: Oren Miller [mailto:or...@qu...]=20
Sent: 30 October 2006 15:40
To: qui...@li...
Cc: ni...@ox...
Subject: Re: [Quickfixj-users] Logon and resend after connection lost

=20

Indeed.  For whatever reason they chose to gap fill this message.  This
is most commonly done with administrative messages (heartbeats etc), but
is occasionally done for application messages as well (Orders that are
too old to go into market).  This is analysis is correct.  For some
reason they put TradingSessionStatus in this category, which may or may
not be intentional or an oversight. =20

=20

FYI, here is the relevant section in the specifications:

=20

"The sending application will initiate the Sequence Reset. The message
in all situations specifies NewSeqNo=20

to reset to as the value of the next sequence number to be expected by
the message receipient immediately=20

following the messages and/or sequence numbers being skipped."

=20

On Oct 30, 2006, at 9:19 AM, Alex McGlashan wrote:





I'm getting a similar problem.  What's happening is that the Sequence

Reset from your counterparty (message 289) causes your QFJ to reset its

expected incoming sequence number to 295, thereby skipping over message

294.  You need, somehow, to get your counterparty to adjust the Sequence

Reset to 294 and the Trading Session Status message should then be

processed.  Unfortunately I have not managed to get my counterparty to

do this so please let me know if you have any success!

=20