問題タブ [mailboxprocessor]

NServiceBus、MSMQ などのメッセージ ベースのアーキテクチャと比較して... F# メールボックス プロセッサの「バックアップを復元」する方法はありますか?

または、MailboxProcessor を拡張してデータのシリアル化を有効にするベスト プラクティスはありますか?

たとえば、ある種のハードウェア障害の場合。

クラスにラップされた F# 3.0 エージェントがあります。

次のようにメッセージを送信すると：

期待される応答が得られます。

ただし、エージェントの let バインディングを削除し、直接 this.agent プロパティに割り当てると:

次に、応答を取得します。

私はこれを何時間も見つめてきましたが、AgentWrapper.Send を呼び出すたびにエージェントが再初期化される理由がわかりません。this.agent を呼び出すたびに再割り当てされているように感じます (つまり、プロパティではなくメソッドのように動作します)。私は何が欠けていますか？

MailboxProcessor を使用する F# プロジェクトの TFS テストの実行を修正するのに苦労しています。問題は、TFS テスト ランナーから受け取る次の警告です。

System.AppDomainUnloadedException: アンロードされた AppDomain にアクセスしようとしました。これは、テストがスレッドを開始したが停止しなかった場合に発生する可能性があります。テストによって開始されたすべてのスレッドが完了前に停止されていることを確認してください。

問題は MailboxProcessor が原因だと思います。次のスニペットは問題を示しています (私は fsi から実行しています)。

出力行には、weakTarget がdeadと表示されるはずです。しかし、それは生きています。何らかのメモリリークを示していると思います。問題は、私が何を間違っているかです。2 つ目の質問は、GC の問題が TFS テスト ランナーの問題に関連しているかどうかです。

MailboxProcessor が破棄された (または停止された) ときに PostAndAsyncReply をすぐに返すことは可能ですか? または、デッドロックを作成せずに PostAndReply メソッドを安全に使用する方法に関する「パターン」/ベストプラクティスはありますか?

現在、MailboxProcessor が破棄されたときに PostAndAsyncReply が返されないという問題があります。私は待つことができないので、タイムアウトパラメータを使用することはオプションではありません (また、あまりにも多くの要因に依存するため、合理的なタイムアウトを選択することは非常に困難または不可能です)。

編集: 私が見た MailboxProcessors のほとんどの例 (MSDN のものを含む) は、MailboxProcessors を破棄することさえ気にしません。また、MSDN では、破棄されたときに MailboxProcessors がどのように反応するかについて説明していません。処分する必要はありませんか？

次のコードをコンパイルできません。

行にエラーがありますmember this.CrossoverA(genomeIn: Genome<'T>):

エラー 1 ジェネリック メンバ 'CrossoverA' は、このプログラム ポイントの前に不均一なインスタンス化で使用されています。このメンバーが最初に現れるように、メンバーの順序を変更することを検討してください。または、引数の型、戻り値の型、および追加のジェネリック パラメーターと制約を含む、メンバーの完全な型を明示的に指定します。

エラー 2 このバインディングの明示的なクラスまたは関数型変数の 1 つ以上を一般化できませんでした。他の型に制約されていたためです

また、並んでいmailbox.Post(CrossoverMessage genomeIn)ます：

エラー 3 型 ''T' は型 ''a' と一致しません

プロジェクトのどこにも変数「a」を使用していません。また、CrossoverA という名前は、このファイルでのみ使用されます。プロジェクトの他のクラスは同様のタイピング パターンで作成され、うまく機能します。

非同期メッセージ ベースのメソッドの使用方法を学ぼうとしています。以下は、私がやろうとしていたことの簡略化されたバージョンです。MailboxProcessorオブジェクト内で有限状態マシンを使用しようとしています。全体として、イベント ベースのメソッドを使用する場合に比べて、ロジックがはるかに簡単になるようです。を使用しようとすると問題が発生しますAsync.Parallel。次のコードでは、printfn "Eval %i" vステートメントがi1&i2に対してそれぞれ 1 回だけではなく 2 回評価されています。これは、私が適切に使用していないと信じるように導きますAsync.Parallel。非同期ワークフロー内で使用すべき代替方法はありますか?

F# エージェントについて学んでいます ( MailboxProcessor)。

私はかなり型破りな問題に取り組んでいます。

• dataSourceストリーミング データのソースである1 つのエージェント ( ) があります。データは一連のエージェント ( dataProcessor) によって処理される必要があります。dataProcessorある種の追跡装置と考えることができます。
• dataProcessorが入力を処理できる速度よりも速くデータが流れ込む場合があります。
• 多少の遅れがあってもOKです。ただし、エージェントがその作業を常に把握し、時代遅れの監視が重ならないようにする必要があります。

この問題に対処する方法を模索しています。

最初のアイデアは、スタック(LIFO)を に実装することdataSourceです。データを受信して​​処理できるようdataSourceになったときに、利用可能な最新の観測を送信します。このソリューションは機能する可能性がありますが、ブロックして再アクティブ化する必要があるdataProcessorため、複雑になる可能性があります。dataProcessorとそのステータスを に通信するdataSourceため、双方向通信の問題が発生します。この問題はblocking queue、消費者と生産者の問題に要約される可能性がありますが、私にはわかりません..

2 番目のアイデアは dataProcessor、メッセージの並べ替えを処理することです。このアーキテクチャでは、 は更新をのキューdataSourceに投稿するだけです。キューで利用可能な最新のデータをフェッチするために使用します。これが進むべき道かもしれません。ただし、現在の設計でメッセージのキューをクリアして、古い古いメッセージを削除できるかどうかはわかりません。さらに、ここでは、次のように書かれています。dataProcessordataProcessorScanMailboxProcessor

残念ながら、現在のバージョンの F# の TryScan 関数は 2 つの点で壊れています。まず、要点はタイムアウトを指定することですが、実装は実際にはそれを尊重しません。具体的には、無関係なメッセージがタイマーをリセットします。第 2 に、他の Scan 関数と同様に、メッセージ キューはロックされた状態で検査されます。これにより、任意の長い時間になる可能性があるスキャンの間、他のスレッドがポストすることを防止できます。その結果、TryScan 関数自体が並行システムをロックアップする傾向があり、呼び出し元のコードがロック内で評価されるため、デッドロックが発生することさえあります (たとえば、関数の引数から Scan または TryScan へのポストは、ロックの下のコードが待機をブロックしているときにエージェントをデッドロックする可能性があります)。すでに下にあるロックを取得します)。

最新の観測値が跳ね返ることが問題になる場合があります。この投稿の著者である @Jon Harrop は、次のように提案しています。

私はそれを中心に設計することに成功し、結果として得られたアーキテクチャは実際にはより優れたものになりました. 本質的に、私は熱心にReceiveすべてのメッセージを処理し、独自のローカル キューを使用してフィルタリングします。

このアイデアは確かに検討する価値がありますが、コードをいじり始める前に、ソリューションをどのように構築できるかについていくつかの意見を歓迎します。

ありがとうございました。

SynchronizationContext を使用して GUI と対話するエージェントを作成しました。

その中に危険はありますか？エージェントが 20 人いる場合はどうなりますか? これらの発生したイベントは同期されていますか? このイベントの長い計算関数があるとします。他のエージェントのイベント ハンドラーがその終了を待っていることを確認できますか?