Message queue behavior in QuickFIX/J for disconnected clients
<p>I wanted to clarify a behavior of <code>QuickFIX/J</code> (FIX 4.2) under the following scenario. There are two parties involved in this <code>QuickFIX/J</code> communication: </p>

<ol>
<li>A client initiator, called <strong>I</strong>. </li>
<li>Our firm's acceptor program, called <strong>A</strong>. </li>
</ol>

<p>When <strong>I</strong> logs onto <strong>A</strong>, they exchange FIX messages with tag <code>35=A</code>. Once a connection is established, <strong>I</strong> starts to submit orders. There may be a point however, where <strong>I</strong> disconnects unexpectedly, at which point <strong>A</strong> decides to send cancels for all of the open orders of <strong>I</strong> (this is valid, because <strong>A</strong> has no idea why <strong>I</strong> failed or when <strong>I</strong> would come back alive).</p>

<p>Note that this entire cancel-on-disconnect procedure is initiated and handled by <strong>A</strong> alone - it gets initiated from <strong>A</strong>'s <code>onLogout(...)</code> method and handled by its normal order management mechanisms. A single <code>35=F</code> message gets generated for each of the open orders of <strong>I</strong>, and an <code>ExecutionReport</code> (<code>35=8</code>) gets generated on each successful cancel. </p>

<p>When <strong>I</strong> comes back alive, these <code>ExecutionReport</code>s must be delivered to <strong>I</strong> somehow so that it becomes aware all its previous orders have been cancelled. I had an impression that <code>QuickFIX/J</code>'s message queue implementation handles this without an application-level aid. All <code>QuickFIX</code> messages are ensured for delivery to counter-parties (<a href="http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/169" rel="nofollow">http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/169</a>). </p>

<p>Contrary to my understanding, however, no <code>ExecutionReport</code>s were not shown in <strong>A</strong>'s <code>QuickFIX</code> logs, or delivered to <strong>I</strong> when <strong>I</strong> reconnected, resulting <strong>I</strong> to be unaware that its previous orders have been cancelled. I noticed that logging does not occur because of the following source code of the <code>sendRaw(Message message, int num)</code> method of <code>Session</code> in <code>QuickFIX/J</code>: </p>

<pre><code>/**
 * Send the message
 *
 * @param message is the message to send
 * @param num is the seq num of the message to send, if 0, the next expected sender seqnum is used.
 * @return
 */
private boolean sendRaw(Message message, int num) {
    ...
        } else {
            try {
                application.toApp(message, sessionID);
            } catch (final DoNotSend e) {
                return false;
            } catch (final Throwable t) {
                logApplicationException("toApp()", t);
            }
            messageString = message.toString();
            if (isLoggedOn()) { // happens only if session is connected
                result = send(messageString); // logging happens within "send"
            }
        }
    ...
}
</code></pre>

<p>The session was not logged on while <code>ExecutionReport</code> messages were being generated for cancels initiated by <strong>I</strong>'s disconnect, and therefore it never hit the <code>send(messageString);</code> and no logging happened. I believe no message got queued (based on the fact that <strong>I</strong> does not receive any messages when it comes back alive) for the same reason. </p>

<p>Our firm made many implementations based on the belief that <code>QuickFIX/J</code> guarantees all messages to be delivered without a loss, but my observation on the scenario above speaks otherwise.</p>

<p>How is <code>QuickFIX/J</code>'s message queue expected to behave in this scenario, when a session is not logged on? Should it queue messages regardless, waiting to be sent once the session becomes available again in the future, or stop queuing for the duration while the session is down?</p>