問題タブ [actor]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
multithreading - アクター ベースの開発 - 実装に関する質問
ここでの最初のメッセージです。このコミュニティに参加できてうれしいです。
すべてがマルチスレッド開発に向かっているようです。大きな魚は、数百のコアに到達するのにそれほど時間はかからないと言います。
私は最近、アクター ベースの開発について読み、メッセージ パッシングが並行プログラミングを処理するのにいかに優れているかについて読みました。さらに、メソッド呼び出しの手段として実装できることも読みました。この場合、特定のオブジェクトはアクターでもあります。
つまり、任意にメソッドを呼び出すことはなくなりました。それらは、後処理のためにキューにポストされます。メッセージはすべてシリアル化されるため、キューはオブジェクトの状態 (var) が同時に変更されないようにします。
このモデルは実装が非常に簡単であることを理解しています (少なくとも実験的なものです)。おそらくそれが、技術的な詳細を見つけるのが難しすぎる理由です。
私の質問はキューに関するものです。これは、複数のプロデューサーと 1 つのコンシューマーの典型的なケースであり、ある種の同期が必要であると思われます。本当?別の解決策があるでしょうか?ロックフリー構造として実装できると聞きました。
それについてはよくわかりません。どんなコメントでも大歓迎です。
良い一日をお過ごしください
scala - scala アクターのスレッド監視
実際にいくつのスレッドが生きていて、自分の scala アクターを実行しているかを監視する方法はありますか?
multithreading - アクター モデルはいつ使用する必要がありますか?
アクター モデルはいつ使用する必要がありますか?
もちろん、デッドロックのない環境を保証するものではありません。
アクター A は、B が A を待っている間、B からのメッセージを待つことができます。
また、アクターが次のタスクに移る前にメッセージが処理されたことを確認する必要がある場合、メッセージを送信し、単純なブロックではなく「メッセージが処理されました」というメッセージを待つ必要があります。
モデルの力は?
scala - 別のクラスから送信するときに正しい scala アクターの送信者参照を取得する
アクター内で、別のアクターにメッセージを送信するクラスを作成する必要があります。他のアクターはアクター A に返信する必要があります
問題は、内部クラスから送信している間、私はもうアクター自体の中にいないということです。その結果、アクター B はアクター B への正しい参照を取得しません。これを修正する 1 つの方法は、A への参照を 経由で渡すことです。メッセージですが、これは私にはかなり醜いようです。
これを解決するよりエレガントな方法はありますか?
scala - アクター「スレッドレス」(受信なし...)を使用してScalaでプロデューサー/コンシューマーobjを作成することは可能ですか?
そこで、実際にスレッドをブロックすることなく、ブロックしているように見えるネットワーク コードを書きたいと思います。いくつかのデータを有線で送信し、ネットワーク経由で返される応答の「キュー」を用意します。http://www.scala-lang.org/node/242にあるアクター チュートリアルのプロデューサー/コンシューマーの例に触発されて、非常に単純な概念実証を作成しました。
問題は、受信を使用するとスレッドを占有しているように見えるため、スレッドを占有せずに「ブロッキング感」を得る方法があるかどうか疑問に思っています。私のコードサンプルは次のとおりです。
受信を使用せずにこれを実行して、スレッドレスにする方法はありますか?
scala - Scala Actors を使用してパイプラインのような sth を作成する
現在、次の問題に 1 週間苦労しており、アドバイスが必要です。
次のようなパイプラインを構築したい:
これまでのところ、すべての Pipeline-Segment をアクターとして実装しました。filterXXX や consolidate などの一部のアクターは、クエリごとに状態を維持する必要があるため、クエリごとに専用のアクター インスタンスを作成する必要があります。
askIMDB のような関数は、同時に処理したい複数の結果を生成します (それぞれ別のアクターに対して)。したがって、 query() を実行する前にアクターのグラフ全体を事前に構築する方法も、実行時にそれを変更するエレガントな方法も見つかりませんでした。
私の最初の試みは、アクターのチェーンと、メッセージ内のトランザクション ID のような sth を渡すことでした。そのため、各アクターには Map[TransactionID->State] がありましたが、これはかなり見苦しく感じました。2 番目の試みは、アクターのダイグラフを 1 つのフローに抽象化する一種のパイプラインを作成することでしたが、これまでのところ失敗しました。
これは私の最初の投稿です。何かを忘れていたり、質問が一般的/疑似コード化されていたりした場合は申し訳ありません。アドバイスをいただければ幸いです。ありがとう!
objective-c - PLActorKit を使用したオープンソースの例はありますか?
Plausible Labs の PLActorKit に興味をそそられました。
http://code.google.com/p/plactorkit/
しかし、ドキュメントには単一の Echo の例しかありません。さらに掘り下げる前に、PLActorKit を使用したオープンソース プロジェクトを調べてみることができるかどうか知りたいです。
scala - アクターのプールを使用する意味はありますか?
私は Actor パターンを学んでいて、とても気に入っています。現在は Scala を使用していますが、Scala、Erlang、Groovy などで使用されているアーキテクチャ スタイル全般に興味があります。
私が考えているケースは、「ジョブを実行する」など、並行して行う必要がある場合です。
スレッド化では、スレッド プールとブロッキング キューを作成し、各スレッドにブロッキング キューをポーリングさせ、キューに出入りするジョブを処理します。
アクターの場合、これを処理する最善の方法は何ですか? アクターのプールを作成し、何らかの形でアクターにジョブを含むメッセージを送信することは理にかなっていますか? たぶん「コーディネーター」アクターと一緒ですか?
注: 言及するのを忘れていたケースの側面は次のとおりです。アプリが同時に処理するジョブの数を制限したい場合はどうすればよいでしょうか? 多分構成設定で?プールを使えばこれが簡単にできるのではないかと考えていました。
ありがとう!
performance - scala アクター: 長時間実行される io 操作
私の場合、永続的なソケット接続など、長時間実行される操作を含むアクターにはかなりの問題があります。作成するサーバー インスタンスが 4 つ未満の場合は正常に動作するテスト コードを次に示しますが、それ以上のインスタンスを作成すると、他のソケット接続がタイムアウトするため、常に 3 つまたは場合によっては 4 つの同時ソケット接続のみになります。それはなぜなのか、私のコードに明らかに問題があるのか どうか疑問に思います。
ところで。私はscala 2.7.6 finalを使用しています。
scala - Scalaアクターアプリケーションの奇妙なGC動作
私はかなり多くのアクターを使用するアプリケーションを持っています:正確には25,000です。Scala 2.7.7を使用し、 jdk6_u18で実行されています。基本的に市場データをリッスンして処理し、状態はほとんどありません。
毎日午前8時2分に開始し、1時間以内に。でクラッシュしましたOutOfMemoryError
。「あは」と言うと、「メモリリークがあります!」私がそれを再起動したときを除いて、それは決して、その日の残りの間再びクラッシュすることはありません!これは、米国市場が午後2時30分にオープンしたときに、GCとCPUの両方のオーバーヘッドが増加したにもかかわらずです。
いくつかの事例調査結果:
- Solaris上で動作します。Linuxで実行していたときは、まったくクラッシュしませんでした。
- 世代ヒープのサイジング、より多くのメモリの割り当てなどをいじってみました。違いはないと思います。
verbose:gc
電源を入れたときのコレクターの動作が異なるようです
いくつかの質問があります。
- LinuxとSolarisでこのプログラムの動作が異なるのはなぜですか?
- 8.02で開始する場合と8.42で開始する場合で、動作が異なるのはなぜですか?
- アクターライブラリにメモリリークの問題があると聞きました。それらは何でしたか、いつ修正されましたか、そしてここで「類似した」何かが起こっている可能性があるかどうかをどのように発見しますか?( jhatなどで探すもの)
- 何が起こっているのかについて誰かが考えを持っていますか?
私は今G1
、それが何か違いを生むかどうかを見ようとしています。この質問は明日更新します!
verbose:gcをオンにしたG1からの出力
私はちょうどそれを行為で捕まえたと思います:
600.290:[フルGC 255M-> 144M(256M)、1.5772616秒]
602.084:[GC一時停止(若い)227M-> 145M(256M)、0.0556769秒]
602.418:[フルGC 254M-> 144M(256M)、1.6415216秒]
604.279:[GC一時停止(若い)227M-> 145M(256M)、0.0415157秒]
604.602:[フルGC 255M-> 145M(256M)、1.6041762秒]
606.422:[GC一時停止(若い)227M-> 145M(256M )、0.0237441秒]
606.710:[フルGC 254M-> 145M(256M)、1.6022185秒]
そして少し後で(完全なGCに時間がかかり、再利用が少なくなっていることがわかります)
849.084:[フルGC 254M-> 176M(256M)、1.9658754秒]
851.191:[GC一時停止(若い)228M-> 176M(256M)、0.0218611秒]
851.414:[フルGC 254M-> 176M(256M)、1.9352357秒]
853.492:[GC一時停止(若い)228M-> 176M(256M)、0.0224688秒]
853.716:[フルGC 254M-> 176M(256M)、1.9339705秒]
855.793:[GC一時停止(若い)228M-> 176M(256M )、0.0215707秒]
856.009:[フルGC 254M-> 176M(256M)、1.9805797秒]
858.137:[GC一時停止(若い)228M-> 176M(256M)、0.0223224秒]
verbose:gcをオフにしたG1からの出力
また大丈夫です!*はぁ*
303.656:[GC一時停止(若い)225M-> 93M(256M)、0.1680767秒]
308.060:[GC一時停止(若い)226M-> 94M(256M)、0.1793724秒]
312.746:[GC一時停止(若い)227M-> 93M (256M)、0.1674851秒]
316.162:[GC一時停止(若い)227M-> 95M(256M)、0.1826145秒]
320.147:[GC一時停止(若い)226M-> 94M(256M)、0.1656664秒]
325.978:[GC一時停止(若い)226M-> 93M(256M)、0.1475760秒]
330.176:[GC一時停止(若い)226M-> 94M(256M)、0.1727795秒]
そして、ずっと後で、それはまだ大丈夫です!
25882.894:[GC一時停止(若い)224M-> 125M(256M)、0.2126515秒]
25884.880:[GC一時停止(若い)224M-> 126M(256M)、0.2059802秒]
25887.027:[GC一時停止(若い)224M-> 125M (256M)、0.1851359秒]
25889.940:[GC一時停止(若い)223M-> 126M(256M)、0.2046496秒]
25891.567:[GC一時停止(若い)224M-> 126M(256M)、0.1600574秒]
そして後でまだ、完全なGC
37180.191:[GC一時停止(若い)225M-> 154M(256M)、0.1716404秒]
37182.163:[GC一時停止(若い)(初期マーク)225M-> 153M(256M)37182.326:[GC同時マーク開始]、 0.1622246秒]
37183.089:[GC同時カウント終了、0.7635219秒]
37183.090:[GC注釈、0.0032547秒]
37183.093:[GC同時カウント開始]
37183.297:[GC同時カウント終了、0.2043307]
37183.393:[ GCクリーンアップ198M->198M(256M)、0.0068127秒]
37183.400:[GC同時クリーンアップ開始]
37183.400:[GC同時クリーンアップ終了、0.0000393]
37183.648:[GC一時停止(若い)222M-> 153M(256M) 、0.1483041秒]
37184.235:[GC一時停止(部分)171M-> 91M(256M)、0.2520714秒]
37187.223:[GC一時停止(若い)221M-> 92M(256M)、0.1721220秒]
アップデート
jdk1.6.0_18でG1ガベージコレクタに切り替えてから、アプリケーションは3日間連続して動作しました。エリックは、VMがオブジェクトを終身世代に昇格させた高スループットのケースで、VM自体がデススパイラルに陥る状況の分析において正しいと思います。