Imported from previous forum
The initiator of a logout is generally required to wait for a reasonable period for the Logout (or Resend Request) of the counterparty before disconnecting.
If the initiator is, for a business or implementation reason, unable to process any incoming business messages (e.g. new orders) after it generates its Logout, should it ignore or reject such messages? Should the same logic (ignore or reject) apply to incoming session-level messages other than a Logout or Resent Request?
The initiator of a logout is generally required to wait for a reasonable period for the Logout (or Resend Request) of the counterparty before disconnecting.
If the initiator is, for a business or implementation reason, unable to process any incoming business messages (e.g. new orders) after it generates its Logout, should it ignore or reject such messages? Should the same logic (ignore or reject) apply to incoming session-level messages other than a Logout or Resent Request?
Hi Lalin,
You must still handle the incoming messages until the other side completes the logout handshake.
Either rejecting with the appropriate message (e.g. new order → exec report) indicating reason (e.g. market closed, system shutting down) or, if no appropriate message is available, fall back to the business level reject indicating system unavailable.
A resend request must be serviced. Note that since you will gap fill the original logout you should follow your retransmission with another logout. It is advisable to include text stating “resending logout after servicing retransmission request” in case someone has to come along and examine logs. This will help them understand what they are looking at.
Cheers,
Dennis
Thanks Dennis.
Page 29 of the FIXT 1.1 spec (March 2008) includes the text “After sending the Logout message, the logout initiator should not send any messages unless requested to do so by the logout acceptor via a ResendRequest.” That seems to imply that messages received after a Logout is sent should be ignored.
However, page 40 of the spec states “Send Logout message to counterparty. Wait a reasonable period of time for Logout response. During this time handle “new” inbound messages and/or ResendRequest if possible.”
Once a Logout is sent, is it acceptable to ignore all messages from the counterparty other than a Resend Request or Logout?
The initiator of a logout is generally required to wait for a reasonable period for the Logout (or Resend Request) of the counterparty before disconnecting.
If the initiator is, for a business or implementation reason, unable to process any incoming business messages (e.g. new orders) after it generates its Logout, should it ignore or reject such messages? Should the same logic (ignore or reject) apply to incoming session-level messages other than a Logout or Resent Request?
Hi Lalin,
You must still handle the incoming messages until the other side completes the logout handshake.
Either rejecting with the appropriate message (e.g. new order → exec report) indicating reason (e.g. market closed, system shutting down) or, if no appropriate message is available, fall back to the business level reject indicating system unavailable.
A resend request must be serviced. Note that since you will gap fill the original logout you should follow your retransmission with another logout. It is advisable to include text stating “resending logout after servicing retransmission request” in case someone has to come along and examine logs. This will help them understand what they are looking at.
Cheers,
Dennis
Hello again Lalin,
The spec says “should not send any messages” meaning that if you initiate the logout you should not initiate any more transactions.
The “unless requested by the logout acceptor via a resend request” again is referring to sending anything transactional from the logout initiator (you in this case).
The other party may have transactions already in the pipe. Those transactions should still be serviced by the logout initiator.
In a nut shell, resend a new order, etc. if the logout acceptor asks you to, but don’t send a new order, etc. after initiating logout since under normal processing it will be lost.
(The logout acceptor will drop the message since their is no logged on session, just as the logout initiator will ignore any messages following the logout acceptor’s logout response due to no logged on session.)
Basically you are obligated to help the logout acceptor complete transactions they start before they receive and process your logout message.
Does that make sense?
Best regards,
Dennis
Thanks Dennis.
Page 29 of the FIXT 1.1 spec (March 2008) includes the text “After sending the Logout message, the logout initiator should not send any messages unless requested to do so by the logout acceptor via a ResendRequest.” That seems to imply that messages received after a Logout is sent should be ignored.
However, page 40 of the spec states “Send Logout message to counterparty. Wait a reasonable period of time for Logout response. During this time handle “new” inbound messages and/or ResendRequest if possible.”
Once a Logout is sent, is it acceptable to ignore all messages from the counterparty other than a Resend Request or Logout?
The initiator of a logout is generally required to wait for a reasonable period for the Logout (or Resend Request) of the counterparty before disconnecting.
If the initiator is, for a business or implementation reason, unable to process any incoming business messages (e.g. new orders) after it generates its Logout, should it ignore or reject such messages? Should the same logic (ignore or reject) apply to incoming session-level messages other than a Logout or Resent Request?
Hi Lalin,
You must still handle the incoming messages until the other side completes the logout handshake.
Either rejecting with the appropriate message (e.g. new order → exec report) indicating reason (e.g. market closed, system shutting down) or, if no appropriate message is available, fall back to the business level reject indicating system unavailable.
A resend request must be serviced. Note that since you will gap fill the original logout you should follow your retransmission with another logout. It is advisable to include text stating “resending logout after servicing retransmission request” in case someone has to come along and examine logs. This will help them understand what they are looking at.
Cheers,
Dennis