2

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?

baron
  • 149
  • 3
  • 11

2 Answers2

1

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.

Yannick
  • 663
  • 1
  • 10
  • 33
0

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.

Hemant Singh
  • 1,487
  • 10
  • 15
  • I think my case (as an intiator), I am sending a to low seqnum that the acceptor will disconnect immediatly at my logon message. When you say " lower than expected SeqNum, logout", what does it mean? I am disconnected, so I can't log out. Also, when you say "if higher, send a resend request". do you mean that I should handle the disconnect message and send in a 35=4 with a smaller seqNum? – baron Jun 13 '18 at 19:22
  • Sorry for not being clear. There are 2 sequence numbers SenderSeqNum: Sequence number used for sending the messages. TargetSequenceNumber: Sequence number expected in receive messages. Verification is done against the sequence number received against TargetSequenceNumber. Sequence numbers between the client and the server have to be sync. In your case even if other party reset the sequence number, you will get the error because the client will send a lower sequence number that you are expecting. – Hemant Singh Jun 14 '18 at 13:50
  • This case is an error scenario and QuickFixJ(Other party custom logic) may automatically disconnect the connection, I need to confirm the default QuickFixJ behavior. But, It is a common practice that both the client and the server resets the sequence numbers on an agreement(on logon, each day or sending 141=Y etc.). Can you please paste some FIX logs for same so that I can analyze it further? – Hemant Singh Jun 14 '18 at 13:50