Message processing after stopping the stream

[mrFloony]

trafficstars

I apologize for my English, translate using Google Translate.

In general, the situation is as follows: In the Session.next method, each message is checked using the Session.verify. When the thread is started, the checks pass as expected. But, if for some reason the connection is interrupted, the processing of messages goes from the internal queue of messages that have not yet been processed (for example, this is shown in a private method SingleThreadedEventHandlingStrategy.block -> SessionMessageEvent event.processMessage -> Session.next(message). -> Session.verify). Inside the Session.verify method there is a check implemented as a private method Session.validLogonState, and when the thread is stopped, messages from the internal queue do not pass the check (the Session.verify throws a SessionException ("Logon state is not valid for message (MsgType ="+ msgType + ")"). As a result, if a sufficient number of messages has accumulated in the queue, these messages automatically (except for possible Logout messages) are considered incorrect and go to the logs.

My question is: is this behavior correct when the message queue, after stopping the flow, continues to process messages with unsuccessful results? Or is it possible to implement queue clearing in case of loss of communication or skipping messages that do not fit the condition?

An example of a situation might be the following: If the message does not pass the time check when the stream is turned on (Session.isGoodTime method), the stream is automatically turned off. But, a Logout message may not yet be sent due to the presence of other messages in the queue, and the stream is already disabled (methods is Session.doBadTime -> Session.logoutWithErrorMessage -> Session.disconnect). As a result, the rest of the queue messages will not be checked by Session.verify.

[chrjohn]

My question is: is this behavior correct when the message queue, after stopping the flow, continues to process messages with unsuccessful results? Or is it possible to implement queue clearing in case of loss of communication or skipping messages that do not fit the condition?

You are right: the messages will be skipped. However, the sequence number is not incremented in that case. So on the next Logon, these messages should get retransmitted via ResendRequest processing. Of course it would be better to process these messages than to throw a SessionException.

[mrFloony]

So on the next Logon, these messages should get retransmitted via ResendRequest processing

It seems to me that for messages related to obtaining currency quotes, it is better to skip it, because after reconnecting a new snapshot should be requested, and then the currency quotes will be received, in fact, from scratch, and they will be relevant (onMessage for 35=W and 35=X).

[chrjohn]

If you are receiving volatile data, such as currency or market data it is better to use ResetOnLogon=Y. Then seqnums will be reset to 1 on each Logon and then you can request a new snapshot.