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?
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:
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.