[QFJ-820] quickfixj ignores the first message on sequence reset Created: 15/Dec/14  Updated: 19/Dec/14  Resolved: 19/Dec/14

Status: Closed
Project: QuickFIX/J
Component/s: Build
Affects Version/s: 1.5.3, 1.6.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Emma Wansbrough Assignee: Unassigned
Resolution: Not a bug Votes: 0
Labels: None
Environment:

this happens on window and linux


Attachments: Text File messages470-480.txt    

 Description   

Hi,
I am experiencing the following serious fix issue. This could be config but I am not convinced.

I have used both quickfixj 1.5.3 and the newer 1.6.0 (snapshot)

I get the following issue

I connect to the fix server periodically there is a message that comes in out of sequence

From the event log we get the following issue

20141215-00:01:02: Received logon
20141215-14:41:57: MsgSeqNum too high, expecting 473 but received 474:

Execution Report

Field Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 956
35 MsgType Execution Report (8)
34 MsgSeqNum 474

20141215-14:41:57: Enqueued at pos 474: Field
Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 956
35 MsgType Execution Report (8)
34 MsgSeqNum 474

20141215-14:41:57: Sent ResendRequest FROM: 473 TO: 473
20141215-14:41:57: MsgSeqNum too high, expecting 473 but received 474:
8 BeginString FIXT.1.1
9 BodyLength 956
35 MsgType Execution Report (8)
34 MsgSeqNum 474

and at this point we get a general repeat of this deadlock

From mesages log you can see that a resend request got sent
Field Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 68
35 MsgType Resend Request (2)
34 MsgSeqNum 441
49 SenderCompID NOMXFIXPTM
52 SendingTime 20141215-14:41:57.405
56 TargetCompID MA
7 BeginSeqNo 473
16 EndSeqNo 0

the next message from MA is

Field Field Name Value
8 BeginString FIXT.1.1
9 BodyLength 1095
35 MsgType Execution Report (8)
34 MsgSeqNum 473
43 PossDupFlag Y
49 SenderCompID MA
52 SendingTime 20141215-14:41:57.415
56 TargetCompID NOMXFIXPTM
122 OrigSendingTime 20141215-14:41:43
37 OrderID 1240469
527 SecondaryExecID 8534860-0

And MA keep sending trades with the next sequence up but our client is having none of it.

20141215-14:41:57: Already sent ResendRequest FROM: 473 TO: 473. Not sending another.

The thing that seems to be wrong is the first message sent over after the resend request gets ignored, instead it sees the message after that.
Restarting can put this back to the correct sequencing and thus out of the deadlock

I am hoping someone might have some insight into this issue.



 Comments   
Comment by Christoph John [ 15/Dec/14 ]

You could try specifying SendRedundantResendRequests=Y in your config. But of course this is only a workaround.
Could you please post or attach a message log starting from seqnums 470 until ab out 480?

Comment by Emma Wansbrough [ 16/Dec/14 ]

I am going to look into this abit more but I scan see that the 473 was sent, but got ignored previously. It could be that this message caused an error that got swallowed and prevented a sequence number being updated.

Comment by Emma Wansbrough [ 16/Dec/14 ]

@ Christoph John, thankyou for taking a look this is much appreciated.

Comment by Emma Wansbrough [ 16/Dec/14 ]

I did specify this as suggested I found I got the same type of situation, just alot more resend requests. I will do this and show logs.

Comment by Christoph John [ 16/Dec/14 ]

Hmm, my first guess is also that there might be something wrong with the message (maybe it is failing inside fromApp)? I mean there is plenty of time in between the messages, so there most probably is no race condition.

Comment by Emma Wansbrough [ 16/Dec/14 ]

do you mean from the fix server? @fromApp

Comment by Christoph John [ 16/Dec/14 ]

When you get to process the message of your counterparty then it is passed through the fromApp callback of your application. If there are RuntimeExceptions or other unexpected behaviour inside that method, the target sequence number is not incremented which will lead to a resend on the next message.

Comment by Emma Wansbrough [ 16/Dec/14 ]

Johh,
I did abit of debugging
I am getting an invalid checksum from the message I get. I think at this point it bombs out and never increments the sequence number so I get trapped in the never ending state.

Can you verify this?
if (checkSum != checkSum(messageData))

{ // message will be ignored if checksum is wrong or missing throw new InvalidMessage("Expected CheckSum=" + checkSum(messageData) + ", Received CheckSum=" + checkSum + " in " + messageData); }

I throw this exception. I am not that familiar with the code.

Comment by Christoph John [ 17/Dec/14 ]

Yes, on an invalid checksum, the message is simply ignored and the target seqnum is not incremented. This is in line with the FIX spec and is because FIX is a rather optimistic protocol. It simply assumes that this was a transmission error and re-requests the message. Unfortunately, most of the time the error will repeat.

To get around this, your counterparty should set the correct checksum on the message. Maybe this is caused by special characters on the message?

Comment by Emma Wansbrough [ 19/Dec/14 ]

Hi Chrisoph,
The counterparty have got back and acknowledged an issue on their side with a special character.
Thanks for your input on this.

I think it can safely be closed as not a bug!

Emma.

Comment by Christoph John [ 19/Dec/14 ]

Thanks for the update.

Comment by Christoph John [ 19/Dec/14 ]

Feel free to ask on the mailing list if there are any issues:
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Generated at Sat Nov 23 07:20:47 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.