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

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

That line is an artifact of how QuickFIX used to resend requests.  =20
You are correct that it will in all cases be overwritten, but it is =20
intentional that resend requests are done the new way.  It has been =20
recommended for some time that all resend requests be done to =20
infinity instead of asking for specific ranges.  The relevant section =20=

of the specification is this:

Ordered Message Processing:
The FIX protocol assumes complete ordered delivery of messages =20
between parties.  Implementers should
consider this when designing message gap fill processes.  Two options =20=

exist for dealing with gaps, either request
all messages subsequent to the last message received or ask for the =20
specific message missed while maintaining
an ordered list of all newer messages.  For example, if the receiver =20
misses the second of five messages, the
application could ignore messages 3 through 5 and generate a resend =20
request for messages 2 through 5, or,
preferably 2 through 0 (where 0 represents infinity).  Another option =20=

would involve saving messages 3 through 5
and resending only message 2.  In both cases, messages 3 through 5 =20
should not be processed before message 2.

The spec doesn't explain why this is, but asking for specific ranges =20
can lead into some unfortunate resend-request loops.  Either way you =20
will not miss messages.  The protocol is designed to handle infinite =20
resend requests in this fashion.  The sequence numbers are always =20
used to verify the next messages that needs to be passed to your =20
application.  The PossDup is just what is says, a possible =20
duplicate.  QuickFIX will always verify if the message is an actual =20
duplicate and pass it on to you if it has not seen the message before =20=

regardless of the contents of that field.

--oren

On Oct 31, 2006, at 9:51 AM, Nick Fortescue wrote:
> I=92m taking this up with the counterparty, but there is a quickfix =20=

> related issue here to I think, related to quickfix=92s resend =20
> request. The code in Session.java has:
>
>     private void generateResendRequest(String beginString, int =20
> msgSeqNum) {
>
>         Message resendRequest =3D messageFactory.create(beginString, =20=

> MsgType.RESEND_REQUEST);
>
>         int beginSeqNo =3D getExpectedTargetNum();
>
>         int endSeqNo =3D msgSeqNum - 1; // Why initialized when it =20
> 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 + =20=

> " TO: " + endSeqNo);
>
>         state.setResendRange(beginSeqNo, msgSeqNum - 1);
>
>     }
>
>
>
> I don=92t understand why it has these lines:
>
>
>
>         if (beginString.compareTo("FIX.4.2") >=3D 0) {
>
>             endSeqNo =3D 0;
>
>         } else if (beginString.compareTo("FIX.4.1") <=3D 0) {
>
>             endSeqNo =3D 999999;
>
>         }
>
>
>
> The line before, setting it to msgSeqNum-1 seems much more correct, =20=

> and more consistent with the state.setResendRange(beginSeqNo, =20
> msgSeqNum - 1) code as well. Hopefully if the counterparty =20
> responded with a GapFill for just these, then any messages coming =20
> afterwards would not be lost.
>
>
>
> Nick
>
>
>
>
>
> From: Oren Miller [mailto:or...@qu...]
> Sent: 30 October 2006 15:40
> To: qui...@li...
> Cc: ni...@ox...
> Subject: Re: [Quickfixj-users] Logon and resend after connection lost
>
>
>
> Indeed.  For whatever reason they chose to gap fill this message.  =20
> This is most commonly done with administrative messages (heartbeats =20=

> etc), but is occasionally done for application messages as well =20
> (Orders that are too old to go into market).  This is analysis is =20
> correct.  For some reason they put TradingSessionStatus in this =20
> category, which may or may not be intentional or an oversight.
>
>
>
> FYI, here is the relevant section in the specifications:
>
>
>
> "The sending application will initiate the Sequence Reset. The =20
> message in all situations specifies NewSeqNo
>
> to reset to as the value of the next sequence number to be expected =20=

> by the message receipient immediately
>
> following the messages and/or sequence numbers being skipped."
>
>
>
> 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 =20=

> its
>
> expected incoming sequence number to 295, thereby skipping over =20
> message
>
> 294.  You need, somehow, to get your counterparty to adjust the =20
> 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=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642________________________=
______=20
> _________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users