Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Not a bug
-
Affects Version/s: 1.5.3, 1.6.0
-
Fix Version/s: None
-
Component/s: Build
-
Labels:None
-
Environment:this happens on window and linux
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.