quickfixj initiator disconnecting due to low seqnum too low

Question

quickfixj initiator getting Disconnecting: Encountered END_OF_STREAM while trying to logon to the acceptor. We are using vendor's fix engine as acceptor. and feedback from acceptor is that logon request for xxxx was not accepted, incoming too small, expect 305, received 27.

I read the quickfix documentation but didn't get it exactly what's the proper solution for the sequence number mismatch. I understand that if I am disconnected, my initiator will send an 35=4 for resend with initiator side seqnum asking acceptor to resend the messages and fill up the gap. But in what case, if initiator is sending a lower seqnum will be rejected by acceptor and refuse the connection? And what's the proper procedure to handle this kind of rejection and reconnect? In order to not loose any message, how should both side do the reset and fill the gap? In case there is a break between the initiator and acceptor, what's the recommended solution to keep the messages in sync and not loosing any?

Answer 1

According to default logic in QuickfixJ: QuickfixJ manages 2 sequence number, expectedSeqNum to receive(targetSeqNum) and nextSeqNumber to sent.

Check the next expected target SeqNum against the received SeqNum.If a mismatch is detected, apply the following logic:

• if lower than expected SeqNum, logout
• if higher, send a resend request

In your case received was lower than expected so it gets disconnected.

Reason for receiving higher than expected SeqNum: Receiver misses some message so it could be a normal scenario.

Reason for lower than expected SeqNum(Your case): One of the counterparties resets its sequence number, which is not expected it should be agreed by both the counterparties.

In a normal scenario, whenever you miss the message you will receive a higher number and it would be managed by QuickFixJ.

Answer 2

Due to the first sentence of your question I would like to show you an answer to the same error message Disconnecting: Encountered END_OF_STREAM. There is a blog post by bhageera quoted.

In the end the reason was pretty silly… the counterparty I was connecting to allows only 1 connection per user/password (i.e. session with those credentials) at a time. As it turns out there was another application using the same credentials against the same TargetCompID. As soon as that application was killed off, the current one logged in fine.

I searched for the cause of the bug for a while, until I realized that I had two initiators with the same credentials running on two different test environments.