問題タブ [quickfixj]

FIX.4.2 を使用して OrderCancelRequest を作成しようとしていますが、OrderID、OrigClOrdID、および ClOrdID と混同しています。Webで検索しましたが、よくわかりませんでした。これらのパラメータについて説明し、可能であれば OrderCancelRequest のコード スニペットを提供してください。

前もって感謝します。

Fix.4.2 プロトコルを実装しようとしていますが、以下に添付したメッセージ ログがわかりにくいです。ここでは、Logon(35=A) 要求がクライアントから MsgSeqNum(34=1) で送信されました。次に、ResendRequest および SequenceReset セッション レベル メッセージをテストするために、MsgSeqNum=7 を指定して NewOrderSingle 要求を送信しました (MsgSeqNum=2 の代わりに、後続のメッセージはログオン要求後に msgseqnum をインクリメントする必要があるため)。予想どおり、MsgSeqNum が受信した値よりも高すぎるため、1 つの Fiximulator が ResendRequest(35=2) で応答して 2 から 0 (つまり、2 から 7) に送信しました。ここで、Fiximulator がクライアントの応答を待っていないのはなぜですか? 代わりに、ハートビート メッセージを送信しています。クライアントが SequenceReset メッセージを送信する代わりに、Fiximulator の ResendRequest に応答して ResendRequest を送信するのはなぜですか?

可能であれば、残りのケースについても説明してください。

前もって感謝します。

私のクライアント修正エンジンは、quickfix4j を使用してサーバー修正エンジンに接続しています。

サーバー修正エンジンは、日曜日の午前 1 時から金曜日の午後 5 時まで実行されます。

これは私のイニシエーター構成です

セッションは 19:00: EST (つまり 00:00:00 UTC) にログアウトします。正解です。

ここでも、クライアント修正エンジンがログイン要求を送信し、サーバーからログイン応答を取得します。ログイン応答の直後に、修正エンジンが作成している resendRequest (35=2) が表示されます。

ログイン リクエスト 35=A のシーケンス番号は 0 ですが、サーバーの結果ははるかに高いことがわかりました。

このクライアント修正エンジンにより、ResendRequest が送信されます。

この問題を解決するには、構成を更新する必要がありますか?

私のサーバー修正エンジンには 1 週間のセッションがあります。しかし、私のクライアント修正エンジンには 1 日の長いセッションがあります。

EOD でログアウトして再度ログインすると、ResetOnLogout=N を設定していても、シーケンス番号がリセットされます (ログオン メッセージには 34=0 があります)。これは正しいです？

週の半ばにシーケンス番号をリセットしたくない場合は、クライアント セッションをサーバー セッションと同じにする必要がありますか (1 週間の開始 -> 日から終了 -> 金)?

QuickFIX/J以下のシナリオでの (FIX 4.2) の動作を明確にしたかったのです。このQuickFIX/J通信には、次の 2 つの関係者が関係しています。

1. Iと呼ばれるクライアント イニシエーター。
2. Aと呼ばれる当社のアクセプタープログラム。

Aにログオンすると、彼らは FIX メッセージを tag と交換します。接続が確立されると、注文の送信を開始します。しかし、私が予期せず接続を切断し、その時点でAがIのすべてのオープン注文に対してキャンセルを送信することを決定する可能性があります(これは有効です。なぜなら、Aは私が失敗した理由や、いつ生き返るかを知らないからです) 。35=A

この切断時のキャンセル手順全体は、Aのみによって開始および処理されることに注意してください。これは、 AのonLogout(...)メソッドから開始され、通常の注文管理メカニズムによって処理されます。I35=Fのオープン注文ごとに1 つのメッセージが生成され、キャンセルが成功するたびに( ) が生成されます。ExecutionReport35=8

私が生きて戻ってきたとき、以前の注文がすべてキャンセルされたことを認識できるように、これらのs を何らかの方法で私ExecutionReportに届ける必要があります。のメッセージ キューの実装は、アプリケーション レベルの支援なしでこれを処理するという印象を受けました。すべてのメッセージは、相手方 ( http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/169 )に確実に配信されます。QuickFIX/JQuickFIX

しかし、私の理解に反して、AのログにExecutionReports が表示されなかったり、再接続したときにsが配信されなかったりしたため、以前の注文がキャンセルされたことに気づきませんでした。inのメソッドの次のソース コードが原因で、ログが記録されないことに気付きました。QuickFIXsendRaw(Message message, int num)SessionQuickFIX/J

Iの切断ExecutionReportによって開始されたキャンセルのメッセージが生成されている間、セッションはログオンしていませんでした。同じ理由で、メッセージがキューに入れられなかったと思います（生き返ったときにメッセージを受信しないという事実に基づいています）。send(messageString);

QuickFIX/J私たちの会社は、すべてのメッセージが損失なく配信されることを保証するという信念に基づいて多くの実装を行いましたが、上記のシナリオに関する私の観察はそうではありません。

QuickFIX/Jセッションがログオンしていない場合、このシナリオで のメッセージ キューはどのように動作すると予想されますか? 関係なくメッセージをキューに入れ、セッションが将来再び利用可能になったときに送信されるのを待つべきですか、それともセッションがダウンしている間キューイングを停止するべきですか?

メッセージを追跡する非常に単純なアプリケーションを実装するために QuickFIX/J を使用していTradeCaptureReportます。基本的に、アプリケーションは受信しpublic void fromApp(Message message, SessionID session)たすべてのメッセージのみをデータベースに保存します。

何らかの理由でデータベースが一時的にダウンしているとします。このような状況に対処する最善の方法は何でしょうか?

1. RuntimeExceptionfrom を投げるだけpublic void fromApp(Message message, SessionID session)です。これにより、メッセージがキューから削除されなくfromAppなり、データベースが再び起動するまで、このメッセージで何度も呼び出されます。私のFIXエンジンに到着する他のメッセージは、私たちの側に積み上げられます.

2. データベース接続の問題を検出するとすぐに、ログアウトして から RuntimeException をスローしfromAppます。これにより、最後のメッセージがキューから削除されず、それ以降のメッセージが FIX セッションの反対側 (カウンターパーティー) に積み上げられます。データベースが再び起動するまで、データベースのポーリングを続けます。もう一度、ログオンして、前の場所から続行します。

他のオプションはありますか？

TradeCaptureReportFIX メッセージを作成する必要があります。作成しようとするまで、これを行う方法は明らかでしたParties：

誰かがJavaコードサンプルを作成してリンクする方法を教えてもらえますかRptSide (803)?

QuickFIX/J を使用し、Groovy 2.4.5 で作成され、Gradle 2.10 でビルドされたアプリケーションのトラブルシューティングを行っています。この FIX サーバーは、Spring-boot 1.2.6 を介して API も提供します。

アプリケーションは、OS X から実行すると SSL 接続を介してテスト ピア アクセプターに接続できますが、Ubuntu 14.04 から実行すると機能しません。

Linux イベント ログ:

[タイムスタンプ]: 切断: ソケット例外 (/[ip:ポート]): javax.net.ssl.SSLHandshakeException: SSL ハンドシェイクに失敗しました。

で証明書を確認しようとしましkeytoolたが、証明書に問題は見つかりませんでした。また、OSX のファイル システムの大文字と小文字を区別しない性質を排除して、ファイルへのパスが大文字と小文字を区別することも確認しました。

証明書は、アクセプターを実行している会社によって生成および署名されます。Ubuntu でのこのハンドシェイクの失敗をさらにトラブルシューティングするにはどうすればよいですか?

アップデート

QuickFIX/J のロギングをさらに実装すると、追加情報が得られます。私が試したすべての Google 検索では、エラーの意味について適切な説明が得られませんでした。

[timestamp] [NioProcessor-3] DEBUG o.apache.mina.filter.ssl.SslHandler - SSLEngine.closeInbound() からの予期しない例外。javax.net.ssl.SSLException: ピアの close_notify を受信する前に受信が閉じられました: トランケーション攻撃の可能性がありますか?

QuickFIX/Jアプリケーション ( は のJ略)を実装しましたJava。ここで、固定テスト ケースをセットアップする方法を検討します。

私は少し慣れていますが、コールバックがあるため（たとえば、クラスのメソッド） JUnit、その問題に適しているかどうかはわかりません。QuickFIX/JfromAppApplication

同じ問題を抱えていて、その問題に対する優れた解決策を見つけた人がいるかもしれません。;)