1

キュー内のアイテムを処理するためのオープンソースのJavaAPIまたはフレームワークが必要です。私は自分で何かを開発することはできますが、車輪の再発明をしたくありません（そして、マルチスレッドの経験はあまりありません）。そんなことあるの？

私が考えることができる最も近いソリューションは、ビジネスプロセス管理（BPM）ソリューションです。

現在、キュー内のアイテムを処理するために複数のQuartzジョブを使用しています。スケーラビリティと同時実行性の問題のため、実際には機能していません。

4

6 に答える 6

2

エグゼキュータを使用したいようです

于 2011-01-13T04:03:09.347 に答える
0

アクターモデルはあなたのプロセスに適合しますか？これは、他のアクター間でメッセージを非同期的に渡すという考えに基づいています。したがって、単純なステートマシンをセットアップしてプロセスをモデル化し、すべての遷移を同時に処理することができます。

于 2011-01-13T05:59:21.990 に答える
0

どんな行列？アイテム数は？クォーツは大きすぎたり小さすぎたりしてうまくいかないのでしょうか?

OpenMQのようなものでメッセージキューを使用することを真剣に考えます。

于 2011-01-13T04:07:32.117 に答える
0

JMS を ActiveMQ で使用でき、最適化されたキュー システムと ESB を作成できます。ワークフローベースのシステムを管理したい場合は、 tpdiが適しています。JBoss jbpm を使用します。

ThreadPool を使用して JMS メッセージを処理することもできます。この場合、Executor を使用できます。

于 2011-01-13T04:17:42.643 に答える
0

問題が使用しているフレームワークにあるのか、コードにあるのかを判断する必要があります。アプリケーションの実行速度と、何も実行していない場合のフレームワークの速度を測定することをお勧めします。(些細なタスクを渡すだけです) インプロセス フレームワークを使用して、1 秒あたり 10 万から 100 万のタスクを実行できるはずです。JMS を使用しても、1 秒あたり 10K メッセージを達成できるはずです。1 秒あたり 1000 万近くのタスクを実行する必要がある場合は、タスクをグループ化して、各タスクがより多くの作業を行えるようにすることをお勧めします。

あなたのフレームワークがボトルネックであるとしたら、私は非常に驚くでしょう。その場合、Executor を使用することをお勧めします。

フレームワークがスケーラビリティと同時実行性の問題の原因ではない場合 (その可能性が高い)、コードを再構築して相互依存なしで長期間実行できるようにする必要があります。つまり、コードを修正する必要があります。フレームワークはそれを行いません。

于 2011-01-13T07:20:49.590 に答える