QuickFIX / J中針對斷開連接的客戶端的消息隊列行為

Question

我想闡明在以下情況下QuickFIX/J （FIX 4.2）的行為。 QuickFIX/J通訊涉及兩方：

1. 客戶端啟動器，稱為I。
2. 我們公司的接受方程序稱為A。

當我登錄到A時 ，它們交換標記為35=A FIX消息。 建立連接后， 我開始提交訂單。 可能有但是一個點，在那里我意外斷開，此時A決定發送取消所有的所有的我的未結訂單的（這是有效的 ，因為不知道為什么我失敗了，或者當我活着回來）。

請注意，整個斷開時取消過程都是由A單獨啟動和處理的-它是從A的onLogout(...)方法啟動的，並由其常規訂單管理機制處理。 對於I的每個未結訂單，將生成一條35=F消息，並且在每次成功取消時都將生成ExecutionReport （ 35=8 ）。

當我復活時，必須以某種方式將這些ExecutionReport傳遞給我，以使它知道之前的所有訂單已被取消。 我的印象是， QuickFIX/J的消息隊列實現無需應用程序級別的幫助即可處理此問題。 確保所有QuickFIX消息都可以傳遞給對方（ http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/169 ）。

但是，與我的理解相反， A的QuickFIX日志中未顯示ExecutionReport也沒有在我重新連接時將其發送給我 ，導致我不知道其先前的訂單已被取消。 我注意到由於QuickFIX/J中Session的sendRaw(Message message, int num)方法的以下源代碼，因此未發生日志記錄：

/**
 * 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"
            }
        }
    ...
}

在為我的斷開連接而發起的取消生成ExecutionReport消息時，該會話未登錄，因此它從未命中send(messageString); 並沒有記錄。 我相信，出於相同的原因，沒有消息排隊（基於我還沒有收到任何消息的事實）。

我們公司基於QuickFIX/J保證所有消息都能毫無損失地傳遞的信念而進行了許多實現，但是我對上述情況的觀察卻相反。

在未登錄會話的情況下， QuickFIX/J的消息隊列在這種情況下應如何表現？ 它是否應該對消息進行排隊，是等待會話在將來再次可用時發送，還是在會話關閉時在整個持續時間內停止排隊？

Answer 1

private boolean sendRaw(Message message, int num)方法的末尾有以下代碼：

if (num == 0) {
    final int msgSeqNum = header.getInt(MsgSeqNum.FIELD);
    if (persistMessages) {
        state.set(msgSeqNum, messageString);
    }
    state.incrNextSenderMsgSeqNum();
}

state.set(msgSeqNum, messageString)將調用messageStore.set(sequence, message) ，該存儲實際上存儲了消息，以便在未連接會話時稍后傳遞。

據我所知，所有消息都將排隊，直到會話成功登錄。

Answer 2

這是我的10美分：當QF / J保證用於活動會話的消息傳遞時，基於序列號和空白填充...

如果會話丟失，則無法保證任何事情。 一旦發現序列號不匹配，您需要做的是將啟動器和接收器配置為在重新連接時填空。 嗯，您的ResetOnDisconnect標志在配置中怎么說？ ResetOnLogout怎么樣？

我認為在QF中沒有消息等待隊列中的消息，因為會話可能會出現迪斯科舞廳，並且從不偵察，這意味着QF隊列一直處於填充狀態或一直處於活動狀態，這不是QF能夠做到的開箱即用。

如果您有迪斯科舞廳，那么您都不能使用OnLogout將執行報告發送到斷開連接的客戶端！ 首先，並非總是在每個迪斯科中都調用OnLogout，其次，正如您所說，我們進入了QF內部，它找不到會話向其發送消息，因此除外。 我不希望QF內部隊列為我處理這種情況。 同樣，保證的傳送是在連接建立時進行的……這是一個依賴項。 不過，我希望它在某處被記錄下來。 您的日志記錄配置是什么？

我認為您需要查看原因： “當/重新恢復運行時，必須將這些ExecutionReports發送到/以某種方式，以便它知道以前的所有訂單都已取消。” 是不是整個過程都比迪斯科舞會的所有訂單都被取消了？ 為什么/需要確認？ 這是既定的，不是嗎？ 這可能是您必須單獨對QF基礎進行編碼的內容。

Answer 3

閱讀此 。

某些公司在LOGON消息中支持標記35002 （斷開時取消），其值可能為：

• 0：請勿使用COD
• 1：僅在發送“正常”注銷時使用COD
• 2：在任何“網絡”斷開連接上使用COD
• 3：1和2

找出對方是否支持。 我尚未檢查QuickFIX支持，但您始終可以自己手動添加標簽，也可以自定義FIX詞典以支持該標簽。

顯然，這是高頻交易者經常使用的。 我對該行業不熟悉，因此在評論部分提出了問題。