Menu
▾
▴
quickfixj-users
|
From: Alex M. <ale...@eu...> - 2006-10-30 15:21:23
|
Hi Nick, 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! Regards, Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Nick Fortescue Sent: 30 October 2006 14:09 To: qui...@li... Subject: [Quickfixj-users] Logon and resend after connection lost QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Eurobase International Limited and its subsidiaries (Eurobase) are = unable to exercise control over the content of information in E-Mails. = Any views and opinions expressed may be personal to the sender and are = not necessarily those of Eurobase. Eurobase will not enter into any = contractual obligations in respect of any part of its business in any = E-mail.=20 Privileged / confidential information may be contained in this message = and /or any attachments. This E-mail is intended for the use of the = addressee(s) only and may contain confidential information. If you are = not the / an intended recipient, you are hereby notified that any use or = dissemination of this communication is strictly prohibited. If you = receive this transmission in error, please notify us immediately, and = then delete this E-mail.=20 Neither the sender nor Eurobase accepts any liability whatsoever for any = defects of any kind either in or arising from this E-mail transmission. = E-Mail transmission cannot be guaranteed to be secure or error-free, as = messages can be intercepted, lost, corrupted, destroyed, contain = viruses, or arrive late or incomplete. Eurobase does not accept any = responsibility for viruses and it is your responsibility to scan any = attachments. Registered Address: Essex House, 2 County Place, Chelmsford, Essex CM2 = 0RE, United Kingdom |
|
From: Nick F. <Nic...@ve...> - 2006-10-31 15:51:48
|
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
|
|
From: Oren M. <or...@qu...> - 2006-10-31 16:51:58
|
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
|
|
From: Oren M. <or...@qu...> - 2006-10-30 16:39:14
|
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. FYI, here is the relevant section in the specifications: "The sending application will initiate the Sequence Reset. The message in all situations specifies NewSeqNo to reset to as the value of the next sequence number to be expected 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 > 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! |
|
From: Nick F. <ni...@ox...> - 2006-10-31 09:24:33
|
Thanks to all. I'll chase it up with the counterparty. 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. 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. FYI, here is the relevant section in the specifications: "The sending application will initiate the Sequence Reset. The message in all situations specifies NewSeqNo to reset to as the value of the next sequence number to be expected 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 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! |
Thanks for helping keep SourceForge clean.
X