私はブログを読んでいましたが、JMSの文脈では、ポイントの1つは「あなたがキューを使用していると、あなたが邪魔しました」でした。JMSの代替
私はJMSを必要としていると思っていましたか？単純な代替案は、非同期的に何かをする必要がある場合、なぜジョブの要求をどこかのテーブルに置くだけで、新しいジョブを探すX時間単位ごとにDBをポーリングするプロセスを持たせるのはなぜですか？
このアプローチは、JMSよりも簡単で、わかりやすく、基本的にアプリケーションからの依存関係を取り除きます。
私が説明した代替手段を使用すれば、何が失われますか？おそらく、JMXを使って物事を管理できる可能性が失われるかもしれませんが、ジョブのキューがテーブルから取り除かれた場合、処理を管理するための簡単なコードを書くことができます。
私はあなたがそれをどこから読んでいるか本当に知りたいです。 JMSはかなり実績のある技術ですが、すべてのソリューションと同様に、誤用する可能性もあります。タスクをスケジュールする必要がある場合は、多くのタスクスケジューリングライブラリの1つを使用できます。ここで は概要です：http://java-source.net/open-source/job-schedulers
ここにありますhttp://teddziuba.com/ – hvgotcodes
確かにTed任意の消費者/プロデューサの問題でJMSを牽制しようとしています。タスクをスケジュールするだけで済む場合は、実際にはJMSは必要ありません。しかし、「キューは悪です」と言っているのはちょっと挑発的です。 –
@jocen、この記事で彼はあまり分析的ではありません。 'http://teddziuba.com/2010/12/the-3-basic-tools-of-systems-engineering.html'キューの検索（悪い言語の警告） – hvgotcodes
私がブログを読んでいた、とJMSの文脈では、「あなたがめちゃめちゃ キューを使用している場合は、」 ポイントの一つでした。
これは単に間違っています。
キューが適切でないときにキューを使用することを選択すると混乱するかもしれませんが、JMSの場合は問題ありません。
私があなただったら私がインターネットで読んだことについて私はもっと分かりやすいでしょう。著者は、ブログに誇りを持ち、Googleアナリティクスの統計情報を盛り上げるための炎症性訴訟を好んだように私に聞こえます。それは一人の意見ですが、それ以上はありません。
ポーリングのソリューションは、複雑で、CPUサイクルが無駄であり、私の意見ではリアルタイムではありません。
非同期処理が必要な場合は、ExecutorまたはFutureTaskを使用できます。 asynchが必要なものがあれば、キューへの妥当な選択肢になります。
@duffymo、私は代わりの考えていた。私は、システムを設計する際に使う新しいパラダイムとして、1行の宣言を受け入れていません。私は、ポーリングのソリューションがより複雑であるとは思わない。そのSQLのルックアップ。そのおそらくより少ないCPUのサイクルを浪費し、すべてのJMSの機械。 – hvgotcodes
1日中5分ごとにポーリングを行い、何も表示しない場合、メッセージがキューに入ったときにそのJMSマシンだけが動作する場合、CPUサイクルを無駄にすることはありますか？あなたはJMSを使うのではなく、投票する言い訳を探しているように思えます。先に進んでください。 – duffymo
@duffymo、まったくありません。私はそのようなアプローチのすべての長所/短所を考えようとしています。私はあなたの最初の考えが「ダム・アイデア」であったと思っています。そこからは、分かりやすく言い訳をすることについて嘲笑したいと思っています。私の最初の反応は「whaaaaaaaat？」と書かれていたとき、私は信じていました。私はそのアイディアにチャンスを与えたいと思っていました。 – hvgotcodes
非常に単純な非同期処理の要件については、java.util.concurrentパッケージの任意の適切なクラスを使用できます。
システム障害（ソフトウェアまたはハードウェアクラッシュ）が発生した場合でもジョブを正常に完了しなければならない、またはジョブ処理を別のプロセスにオフロードしたいという保証が必要な場合は、 。
JMSアプローチは、比較的簡単な労力で非常に洗練されたソリューションを提供できます。
メッセージング（JMS）は、非同期ジョブのサブミットを維持し、実際の処理から切り離されたタスクの提出を維持するという問題を解決できる非常に標準的な統合ソリューションです。メッセージベースのソリューションは、ジョブキューで待機している「ジョブプロセッサ」スレッドの数を増やすことによって簡単に拡大縮小できます。トラフィックは自動的に負荷分散されます。また、メッセージ処理システムは、ジョブの処理が失敗して再試行できるようになった場合に、自動的にメッセージをキューに戻すトランザクションサポートを提供することもできる。
多くのエンタープライズ統合パターンは、メッセージングシステム（メッセージ指向のミドルウェア）に基づいています。 Enterprise Integration Patterns by Gregor Hohpeのこの本には、アプリケーションでメッセージングを使用する方法の最も一般的なパターンがあります。ジョブ処理がいずれかのジョブの行ステータスを更新最終的に処理アプリケーションによって開始したとき
データベースアプローチは、「新しい仕事」のためのテーブルをポーリング行のステータスを更新
1）に他の処理を必要と（または、テーブルからジョブを完全に削除する）ことができます。 2）ジョブ処理中に何か問題が発生した場合は、ジョブのステータスをテーブル上の「新規」に戻して、ポーリング・メカニズムがジョブを再開できるようにします。また、システムの起動時に「回復スレッド」を書き込んで、矛盾した状態になっているジョブを見つけ出し、「新しい」状態に戻して処理を再開する必要が生じます。
要するに、データベースに基づいた統合ソリューションを構築するには多くの労力が必要です。また、「ジョブ・サブミッター」アプリケーションと「ジョブ・プロセッサー」アプリケーションの両方を、データベースのカプセル化を破るデータベース・スキーマと緊密に結合します。あなたの 'ジョブプロセッサー'が複数のスレッドを持っている場合は（スケーリングしたい場合はおそらく必要になります）、1つのスレッドだけがそのジョブを取り出し、 'その行'を更新するようにする必要があります。
JMSソリューションは、このロジックを手作業でコーディングすることなくこの問題を非常に簡単に解決します。
確かに、あなたがキューを使用しているなら、あなたはうんざりしていません。しかし、メッセージングミドルウェアを導入するには、有効なユースケースが必要です。
このアプローチは、JMSよりも簡単で、わかりやすく、基本的にアプリケーションからの依存関係を取り除きます。
これは、データベースの背景から来た場合にのみ当てはまります。私は、すべての州の変更とそれを忘れるためにメッセージを送るよりも簡単なことはないと思います。
メッセージ指向のミドルウェア（JMSなど）のメリットの1つは高性能です。1Ms /秒の速度を実現できますが、大きなメリットは通常、よりクリーンなアーキテクチャです。複数のコンポーネントを接続するメッセージバスです。今はあなたの1対1のコミュニケーションがありますが、2年間でトラフィックをログに記録したい場合があります.3年後にはエラーを監視し、4年間で自動的に記録し、再生してテストすることができます。
このアプローチは、JMSよりも簡単には聞こえません。 –
@kaleb、hmmおそらく。 JMSのアプローチのすべての部分を別のものと並べて配置することは価値があるかもしれません。 – hvgotcodes
JMSのような依存関係は、どこかでテーブル – ChrisBlom