What causes the "Disconnecting: Encountered END_OF_STREAM" session message in QuickFIX/J?

Question

I am using QuickFIX/J version 1.6.4 within Apache Camel 2.17.0 and I get the session message Disconnecting: Encountered END_OF_STREAM. It is not an error, but in my case it leads to an unintentional Logoff.

What circumstances can lead to this message and how do I analyze which circumstance in my case is the cause?

Answer 1

Since the accepted answer covers only an application specific behaviour I am going to name some of the possible causes for the END_OF_STREAM event.

Basically it is kind of like the "connection reset by peer" event of a TCP connection. Meaning that the connection went down without cleanly ending it with a Logout message.

Network related things aside, this can occur whenever the counterparty decides to not send a Logout. Most of the time the reason they are not sending a Logout is due to security, i.e. the counterparty does not want to disclose information about their system.

Examples:

• SSL certificate mismatch
• unknown CompIDs or Session (i.e. CompID or FIX version mismatch)
• duplicate CompIDs (as it was the case in this specific question)
• sequence number too low (although a decent FIX engine will send a Logout indicating this)

As @macemers suggested, another application-specific problem at the counterparty could be that their FIX engine is somehow stuck. This eventually will lead to an abrupt disconnection since the other side fails to process messages or reply to heartbeat messages.

From the FIX spec (FIX Session Protocol, FIX Session-level Test Cases and Expected Behaviors):

When to send a Logout vs. when to just disconnect

In general a Logout message should always be sent prior to shutting down a connection. If the Logout is being sent due to an error condition, the Text field of the Logout should provide a descriptive reason, so that operational support of the remote FIX system can diagnosis the problem.

There are exceptions, when it is recommended that a Logout message not be sent, these include:

• If during a logon either the SenderCompID, TargetCompID or IP address of the session initiator is invalid, it is recommended that the session be immediately terminated and no Logout message sent. This login attempt might be an unauthorized attempt to break into your system; hence one does not want to divulge any information about one’s FIX system, such as: which SenderCompID/TargetCompID values are valid or which version of FIX is supported.

• If during a Logon one receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, it is recommended that the session acceptor immediately terminate the second connection attempt and not send a Logout message. Sending a Logout message runs the risk of interfering with and possibly adversely affecting the current active FIX connection. For example, in some FIX system implementations, sending a Logout message might consume a sequence number that would cause an out of sequence condition for the established FIX session.

In all other cases, if sending a Logout does not create risk or violate security, a Logout message should be sent with a descriptive text message.

Answer 2

NOTE: In ALL cases except the Sequence Reset - Reset<4> message, the FIX session should be terminated if the incoming sequence number is less than expected and the PossDupFlag(43) is not set. A Logout<5> message with some descriptive text should be sent to the other side before closing the session.

https://www.onixs.biz/fix-dictionary/fixt1.1/section_message_recovery.html

Answer 3

I found the answer of this question in this blog post by bhageera.

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.

In my case, two clients with the same credentials were active on two different test environments.