問題タブ [quasar]

のメソッドを呼び出すClass名前があります。伸びます。 内部には への呼び出しがあります。さて、どれが駐車されるでしょうか？インスタンスまたはインスタンス？ の署名(定義されており、これが私の混乱の主な理由です):Foonon-staticbarMethod()BarBarFiber
barMethod()park()FiberFooBar

park()static

答えがFoo（そうらしい）の場合、どうすれば駐車できBarますか？suspend (park) Bar主にしないつもりFooです。
また、インスタンスをパークする方法について回答があれば、私はBarパークしたいのでBar、 ではなくFooをbarMethod()スローする必要があることを教えてくださいSuspendExecution。のどのインスタンスからもアクセスされず、このメソッド内Barに のインスタンスをパークしたくありませんFoo(のみBar)。

に関するすべての同じ質問に対する回答も提供してくださいunpark()。現在Fiber(Fooこの場合はインスタンス) に適用されますか、それともインスタンスに影響しBarますか? Bar後者の場合、インスタンスではなくインスタンスをパーク解除するにはどうすればよいFooですか?

非同期コードでSettableFutureとして動作すると想定できますか ( と想定する必要があります)?FiberForkJoinTask

Quasar SettableFuture は、スレッドに加えてファイバーをブロックできます。

SettableFuture API
Parallel Universe Comsat ドキュメンテーション

私が見る限り、実行中のファイバーがブロックされている場合、スレッドは別のファイバーを実行できます.しかし、そうではありません.solrを検索する100本のファイバーを作成します.結果は、すべてのファイバーが順番に実行されている.別の.ファイバーは、前のものがスレッドのように終了した場合にのみ実行できます。これが私のコードです。

食物繊維を誤解していませんか？

私たちが積極的に開発している fortran バイナリに裏打ちされた Java アプリケーションがあります。私は主に Java 側にいます。Fortran で作業する人々を、同時実行性や複雑な API を公開するように強制しないなどの厄介なシステムの問題から保護することが私の仕事だと考えています。

これらの方針に沿って私が下した決定の 1 つは、JNA スタイルのコールバックを Java から Fortran バイナリに渡すことでした。このコールバックが実行されると、コールスタックは次のようになります。

私の質問はスレッドの 1 つです。同じメモリ内の Fortran DLL への 2 つのスレッド アクセスはどのように処理されますか? 私の質問は、コールスタックがメモリ内でどのように処理されるかの正確な詳細に根ざしています: Fortran コンパイラが JNA から呼び出すことができるコードを生成するために、一方のプログラムカウンターが他方を壊すことなく、そのコンパイラーには何らかの種類のコードが必要です。コールスタックを格納する場所について、JVM と理解を共有しました。X86 はPthreads、 、java.lang.Thread、およびその他のスレッド化ライブラリがすべて活用して、コールスタックを安全に分離できる、ある種の個別のプログラム カウンター コンテナーを提供しますか?

物事を本当に面白くするために、Quasar の使用についても議論しています。なじみのない人のために、Quasar はスタックフル コルーチンによって実装される「軽量スレッド」である「ファイバー」と呼ばれるものを提供します。つまり、Quasar はスタックの直接操作を実行します。 -フレーム。

問題は、概念的には をコールバックとして公開することに非常に満足している一方でOurCode.computationComponents、一部のビジネス要件ではそれができないことです。著名な Fortran プログラマーに、既存のコードを明示的な開始点と終了点 (戻り点) を持つコードに変換するように依頼するよりも、コルーチンを使用して既存のコードを活用したいと考えています。

の呼び出し元への戻り値としてによってに渡された引数を生成する際に、コルーチンが生成されるという考え方です。呼び出し元はその後、computerCompoennts コールバックが通常行う作業を行い、その結果を with に渡します。OurCode.computationComponents.javacomputationComponentsHeavyComputation.f99doHeavyComputationresumeHeavyComputationcomputationComponentsHeavyComputation.f99

もちろん、これらすべてをブロッキング キューと複数のスレッドで実行できますが、使用するスレッドを 1 つに制限しようとすると、Quasar にさらされることになります。これにはいくつかの理由があります。

Quasar は、私たちが使用しているものと同じくらい複雑なスタックを処理し、安全に復元できますか?

Github でクエーサーのソース コード (RAT) を理解しようとしています。

これは、コマンドを使用したサーバー/クライアント間の高度な通信です。

私が本当に理解していなかった興味深い部分は、Class BuilderMono.cecil リファレンスを使用して、ホスト、ポートなどの空のアセンブリ変数の値を変更することです...

スレッドの代わりとしてクエーサーとその軽量ファイバーに興味がありました。彼らのAPI ドキュメントを参照した後、典型的なThreadPoolExecutorをファイバーのプールに変換する方法を理解できませんでした。

上記のコードは、10 個のスレッドを持つプール、10 個の要素を保持できるプールの前のキュー、および拒否ポリシー (キューがいっぱいの場合) を作成して、メイン スレッドに Runnable タスク自体を実行させます。for ループが 100 個の runnable を作成すると、それらはプールで一度に 10 個実行され、10 個がキューに入れられ、メイン スレッドは、他のものが終了するまで Runnable 自体を取得します。

クエーサーの繊維でこれをどのように行いますか? そもそもそのまま使う意味あるの？

編集:私の元の質問は表現が不十分でした。基本的に、同時に実行できるファイバーの数を制限するメカニズムを見つけようとしていました。たとえば、すでに 200 のファイバーが実行されている場合は、それ以上ファイバーを起動しないでください。最大数のファイバーが実行されている場合は、1 つのファイバーが終了するまで待ってから、新しいファイバーを起動してください。

アプリケーションの説明:

• Comsat の Quasar FiberHttpClient (バージョン 0.7.0) によってラップされた Apache HTTP Async Client (バージョン 4.1.1) を使用して、複数の HTTP エンドポイントに HTTP 要求を内部的に送信するためにファイバーを使用する高度な並行 Java アプリケーションを実行および実行します。
• アプリケーションは tomcat 上で実行されます (ただし、ファイバーは内部要求のディスパッチにのみ使用されます。Tomcat サーブレット要求は引き続き標準のブロッキング方法で処理されます)。
• 各外部リクエストは内部で 15 ～ 20 のファイバーを開き、各ファイバーは HTTP リクエストを作成し、FiberHttpClient を使用してそれをディスパッチします。
• アプリケーションをテストするために c44xlarge サーバー (16 コア) を使用しています
• つまり、ソケットを再利用して維持しようとすると、リクエストの実行試行中に接続が閉じられます。そのため、接続のリサイクルを無効にします。

• 上記のセクションによると、私のファイバー http クライアントの調整は次のとおりです (もちろん、私は の単一のインスタンスを使用しています)。

  /li>

• open-files の ulimits は非常に高く設定されています (ソフト値とハード値の両方で 131072 )

• Eden は 18GB に設定され、合計ヒープ サイズは 24GB です
• OS Tcp スタックも適切に調整されています。

kernel.printk = 8 4 1 7 kernel.printk_ratelimit_burst = 10 kernel.printk_ratelimit = 5 net.ipv4.ip_local_port_range = 8192 65535 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.rmem_default = 16777216 net.core .wmem_default = 16777216 net.core.optmem_max = 40960 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.netdev_max_backlog = 100000 net.ipv4.tcp_max_syn_backlog = 100000 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_sack = 0 net.ipv4.tcp_timestamps = 1

問題の説明

• 低中負荷ではすべて問題なく、接続はリースされ、クローズされ、プールが補充されます
• いくつかの同時実行ポイントを超えると、IOReactor スレッド (16 個) は、死ぬ前に適切に機能しなくなったようです。
• プールの統計を取得して毎秒出力する小さなスレッドを作成しました。約 25K のリース接続で、実際のデータはソケット接続を介して送信されなくなり、Pending統計は急増する 30K の保留中の接続要求にも上昇します。
• この状況は持続し、基本的にアプリケーションは役に立たなくなります。ある時点で、I/O Reactor スレッドが停止します。いつ発生するかわからないため、これまで例外をキャッチできませんでした
• lsofJavaプロセスを実行すると、何万ものファイル記述子があり、それらのほとんどすべてがCLOSE_WAITにあることがわかります（これは、I / Oリアクタースレッドが機能しなくなったり停止したりして、実際にそれらを閉じることができないためです）
• アプリケーションが中断している間、サーバーが過度に過負荷になったり、CPU に負荷がかかったりすることはありません

質問

• 私はどこかである種の境界に到達していると推測していますが、それが何またはどこに存在するかについてはまったくわかりません. 以下を除く
• OSポートに到達している可能性はありますか（すべての適用可能なリクエストは結局単一の内部IPから発信されています）制限し、IO Reactorスレッドを停止させるエラー（open files limit errorsに似たもの）を作成しますか？

Kotlinコンパイラにあると思われるこの紛らわしいエラーが発生しました。コードを変更してもかまいませんが、実際に何か間違ったことをしたかどうかを把握しようとしています. 問題が発生しているコードは次のとおりだと思います。

これ以上何を言うべきかわかりませんが、これをインラインでなくすることはできますが、このコードは機能するはずです。GradleでKotlin 1.0.4を使用しています。別の注意点として、これが実際にパフォーマンスの向上をもたらすインライン化に肯定的ではありません。クロスインライン化についてはまだ少し不明です。しかし、どちらの方法でもうまくいくようで、この内部エラーを除いてIDEまたはコンパイラエラーは発生しません。