アクセプターアプリケーションを作成し、永続的なFIXセッションを使用しています。オフラインになったり、プログラムが再起動したりした場合に、再接続したときに、日中に送信されたすべてのメッセージを再処理して現在の状態に戻すように、リカバリモードを作成しようとしています。
これを行うには、起動時にすべてのメッセージの再送信要求をサーバーに送信します。それらは関連するすべてのメッセージを私に送り返し、possdupflag=Yおよびpossresend=Yとマークされます。各メッセージの前に、送信しようとしている繰り返しメッセージのシーケンスリセットを送信します。
問題は、これらのメッセージが私のメッセージクラッカーによって処理されていないようです。fromAdminとfromAppの両方がこれらのメッセージを受け取りません。重複フラグや再送のために無視されていると思います。では、これらのメッセージを見たいことをQuickFIXに伝える方法はありますか？
その点について-誰かがより良い回復プロセスに関する推奨事項を持っているなら、私は彼らにオープンになります。
ありがとう。
この回復戦略には、少なくとも 2 つの潜在的な問題があります。1 つ目は、取引相手に対してあまり友好的ではないことです。セッション中に少数のメッセージしか受信しない場合は問題にならない可能性がありますが、数十万のメッセージを受信した場合は、大量の再送信について相手から苦情が寄せられる可能性があります。
もう 1 つの問題は、メッセージの再送信がエラー回復を目的としており、セッション プロトコル層によって管理されることです。QuickFIX/J (およびその他の FIX エンジン) では、セッションは、シーケンス番号のギャップを検出すると ResendRequest を自動的に送信することに加えて、回復状態を維持します。次に予想される受信シーケンス番号を 1 にリセットすると、このアプローチが機能する可能性があります。セッションがより高いシーケンス番号を持つ次のメッセージを受信すると、ギャップが検出され、不足しているメッセージが要求されます。メッセージが検証されると、PossDup フラグが設定された状態でアプリケーション層に転送されます。自分で ResendRequest メッセージを送信した場合、セッション状態が適切に設定されていないため、動作は未定義です。
MessageLog 実装を使用して、アプリケーションの起動時に回復に使用できる形式で受信メッセージを保存することをお勧めします。既存のメッセージ ログ (FileLog、JdbcLog) の実装を見て、アイデアを得ることができます。
この動作は、エンジンの永続化システムが、受信したメッセージが再送信されたメッセージであり、(FIX プロトコル仕様に従って) 破棄されることをエンジンに通知するために発生します。ここでは、FIXml 文字列をデータベースに保存して、説明したものと同様の回復機能を提供します (他の理由でディスク上の xml ファイルにも書き込まれます)。重複したメッセージを表示したいことをクイックフィックスに伝える方法はないと思いますが、接続のオーバーヘッドを節約するために別の形式または永続性を使用する方がおそらく良いでしょう。Quickfix は、メッセージが届いたときにメッセージをファイルに出力する方法を提供します。