問題タブ [actor]

A が拡張ユース ケース (基本ユース ケースではない) の場合、アクターは A を直接参照できますか?

Scala アクターを単体テストする良い方法を知っている人はいますか? 一般的な意味では、メッセージを受信し、それに応答して他のメッセージを送信するアクターがあります。これは複数のスレッドで行われ、正しくないアクターは間違ったメッセージを送信するか、メッセージをまったく送信しない可能性があります。テスト対象のアクターにメッセージを送受信するモックアップ アクターを作成する簡単な方法が必要です。この分野での経験はありますか？

最近、私はアクター/エージェント/シェアード ナッシング アーキテクチャをサポートする代替言語に取り掛かっています。scala、clojure など (clojure は共有状態もサポートしています)。

これまでに読んだドキュメンテーションのほとんどは、イントロ レベルに焦点を当てています。私が探しているのは、4 つのギャングに沿ったより高度なドキュメントですが、代わりに何も共有されていません。

なんで ？デザイン思考の変化を理解するのに役立ちます。単純な例は簡単ですが、実際の Java アプリケーション (シングル スレッド) では、複雑な関係を持つ数千のメンバーを持つオブジェクト グラフを作成できます。しかし、エージェント ベースの同時実行開発では、大規模なシステムを設計するときに理解すべきまったく新しい一連のアイデアが導入されます。すなわち。エージェントの粒度 - 1 つのエージェントが管理する状態の量 - パフォーマンスなどへの影響、または共有状態オブジェクト グラフをエージェント ベースのシステムにマッピングするための適切なパターンです。ドメイン モデルを設計にマッピングするためのヒント。技術についてではなく、設計で技術を最大限に活用する方法についての議論 (現実世界の「複雑な」例は素晴らしいでしょう)。

私はJavaで金融アプリケーションに取り組んでおり、並行性を正しく取得するのは苦痛です。Erlangとアクターモデルは大規模な並行アプリケーションに適しているはずですが、Javaでそれを行う方法がわかりません。Jetlang、FunctionalJava、kilimなどのライブラリがあることは知っていますが、それらは通常、単純な例を超えるものではありません。

市場データフィード、注文/取引フィードからいくつかの数値を計算し、このデータの派生物を「出力」するなど、3つまたは4つの異なるイベントを処理する必要があるとします。ほとんどの場合、これらのイベントまたはデータストリームは順番に処理する必要があります（少なくともいくつかのキーに関しては...たとえば、特定のシンボルのすべての順序を順番に処理する必要がありますが、並行して処理する必要があります）無関係な記号に関して）

状態を変更するメソッドを使用して、通常のJavaオブジェクトを作成します。これらのメソッドに直接状態を変更させるのではなく、パラメーターを（コマンドオブジェクトに変換して）fifoキュー（erlangのメールボックス）と、そのキューを処理するreact（）メソッドに配置します。このように、すべての更新は単一のキューを通過する必要があり、react（）メソッドは一度に1つの更新にのみアクセスできます。理論的には、これにより、このメソッドをロックまたは同期する必要がなくなります。

ただし、このキューは基本的にプロデューサー/コンシューマーキューであり、ブロッキングキューであることを意味します。ブロッキングはスケーラビリティにとって非常に悪いです。また、単一のキューがあるということは、（異なるタイプの）すべての更新コマンドオブジェクトが（Objectのような）過度に一般的なスーパータイプでキューから出てくることを意味し、それらを正しいタイプにキャストして、react（）に処理させる必要があります。

このアクター化されたオブジェクトが出力を生成し、別のそのようなオブジェクトによって消費されると、私は同じプロセスを実行します。言い換えれば、プログラミングモデルを、結果を返すメソッドを使用するオブジェクト指向から、すべてのメソッドが非同期になる悪夢を渡すある種の継続に変更しました。

これにどのようにアプローチできるかについてのアイデアはありますか？

ScalaActors.pdfのこのスライドショーでは、メッセージがポンアクターに送信されるときに一重引用符は何を示していますか？

次のコードがあります。

f.get私が理解しているように、外側のアクターは実際には別のアクター (SomeEventハンドラー内で作成されたアクター) によって実行されているため、ブロックされません。

これは正しいです？

私は問題を解決するためのJavaのかなり標準的なメカニズムを持っています：

• 作業項目は、特定の時間に実行するようにスケジュールする必要があります
• 次に、各作業項目は、条件が真になるのを待つ必要があります
• 作業項目はキャンセル可能である必要があります

私が使用する解決策は次のとおりです。

1. 作業項目をスケジュールするためのシングルスレッドスケジューラを用意する
2. ExecutorService（マルチスレッドの場合があります）
3. 次に、スケジュールされた各作業項目は、実際の作業をに送信しExecutorServiceます。返さFutureれたものはマップにキャッシュされます。完了サービスは、作業が完了したときにキャッシュから未来を削除するために使用されます
4. アイテムは、キャッシュされた先物を介してキャンセルできます

もちろん、私のエグゼキュータは、少なくとも私が期待するブロッキング作業項目の数と同じくらいの数である必要がありますが、これは実際には問題ではありません。

だから今、私はScalaでコーディングし、アクターフレームワークを使用しています。私の作業項目をアクターに送信されるイベントにカプセル化できると仮定すると、次のようになります。

1. 特定の時間に作業項目をスケジュールするためにどのメカニズムを使用しますか？
2. 作業項目がアクターに送信されるイベントである場合、バッキングスレッドプールが同時にブロックできる項目の数よりも大きいことを確認するにはどうすればよいですか？
3. 以前にスケジュールされた作業項目をキャンセルするにはどうすればよいですか？

Erlangのアクターモデルの特徴の1つは、透過的な配布です。私が誤解していない限り、アクター間でメッセージを送信する場合、理論的には、アクターが同じプロセススペースにある、または同じ物理マシン上に同じ場所にあると想定するべきではありません。

私は常に、分散型のフォールトトレラントシステムでは、順序付け/因果関係およびコンセンサス（とりわけ）に関する固有の問題を解決するために、注意深いアプリケーション設計が必要であるという印象を受けてきました。

Erlangはこれらのクラスの問題を透過的に解決することを約束していないと確信しているので、私の質問は、Erlang開発者がこれにどのように対処するかということです。すべてのアクターが同じプロセススペースにあるかのようにアプリケーションを設計し、実際にそれらを配布するときにのみ配布の問題を解決しますか？

もしそうなら、Erlangのこの透過的な分散機能は本当にリモートメッセージングに使用されるワイヤープロトコルに関係していて、真の分散アプリケーションがまだアプリケーション層で注意深い設計を必要とするという意味で実際には透過的ではありませんか？

プレゼンテーション用に Actor Model について読んでいますが、デッドロックや競合状態などの多くの落とし穴を回避できるため、共有状態の並列プログラミングよりも優れていると誰もが主張しています。私は、この主張の詳細が何であるかを自問しています。これらの問題を回避する場合、どのようにそれを行うのでしょうか?