messages470-480.txt
[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: |
messages470-480.txt
|
| Description |
|
Hi, 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 Execution Report Field Field Name Value 20141215-14:41:57: Enqueued at pos 474: Field 20141215-14:41:57: Sent ResendRequest FROM: 473 TO: 473 and at this point we get a general repeat of this deadlock From mesages log you can see that a resend request got sent the next message from MA is Field Field Name Value 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. 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. |
| 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, Can you verify this? 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, 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: |
