JMSキューがいっぱいです

Question

Java EEアプリケーションがJMSをキューに継続的に送信しますが、JMSコンシューマアプリケーションがJMSの受信を停止することがあります。これにより、JMSキューが非常に大きくなり、サーバーが折りたたまれます。 私のサーバーはJBossまたはWebsphereです。アプリケーションサーバーは「タイムアウト」JMSメッセージを削除する戦略を提供していますか？

大規模なJMSキューを処理する戦略は何ですか？ありがとう！

Answer 1

すべての非同期メッセージングでは、「高速プロデューサ/スローコンシューマ」問題に対処する必要があります。これに対処するにはいくつかの方法があります。

1. コンシューマを追加します。 WebSphere MQでは、深さに基づいてキューをトリガーできます。いくつかの店では、キューの深度が増えるにつれて、新しいコンシューマー・インスタンスを追加するためにこれを使用しますその後、キューの深さが減少し始めると、余分な消費者が死にます。このようにして、変化する負荷に対応するように消費者を自動的に調整することができます。他のブローカーは、一般的に同様の機能を備えています。
2. キューとその下にあるファイルシステムが本当に大きくなるようにします。この方法では、キュー内の作業負荷のピークを完全に吸収しようとします。結局のところ、これはキューイングが最初に行うように設計されたものです。問題は、規模が大きくなく、99％の時間がほとんど空になるようにディスクを割り当てる必要があるということです。
3. 古いメッセージを期限切れにします。メッセージの有効期限が設定されている場合は、それらをクリーンアップすることができます。一部のJMSブローカはこの処理を自動的に行いますが、期限切れのメッセージを削除するにはキューを参照する必要があるかもしれません。この問題は、すべてのメッセージがビジネス価値を失うことなく、期限切れの対象になるということではありません。ほとんどの火災と忘れのメッセージ（監査ログなど）はこのカテゴリに分類されます。
4. プロデューサーを絞り戻します。キューがいっぱいになると、新しいメッセージを入れることはできません。 WebSphere MQでは、生成アプリケーションはキューが満杯であることを示す戻りコードを受け取ります。アプリケーションが致命的なエラーと一時的なエラーを区別する場合、アプリケーションは停止して再試行できます。

これらのいずれかを正しく実装するための鍵は、システムがアプリケーションが応答する「ソフト」エラーを提供できることです。たとえば、多くのショップでは、QFULL条件を初めて取得したときに、キューのMAXDEPTHパラメーターを引き上げます。キューの深さが基礎となるファイルシステムのサイズを超えると、単一のキューに影響する「ソフト」エラーではなく、ファイルシステムが満たされ、ノード全体が影響を受けます。ファイルシステムがいっぱいになる前に待ち行列がMAXDEPTHに達するようにシステムをチューニングするほうがずっと良いですが、何らかの方法で完全な待ち行列に反応するようにアプリケーションや他のプロセスを装備しています。

他に何があっても、上記のオプション4は必須です。どのくらいのディスクを割り当てるか、またはデプロイするコンシューマインスタンスの数やメッセージの期限切れにかかわらず、コンシューマはメッセージ作成に常に追いつかない可能性があります。これが発生すると、プロデューサアプリはスロットルを戻すか、アラームを発して停止するか、ハングや死ぬ以外の何かをする必要があります。非同期メッセージングは​​、スペースを使い果たしてメッセージをキューに格納するまで非同期のみです。その後、あなたのアプリは同期しているので、たとえそれが正常に終了したとしても、その状況を正常に処理する必要があります。

Answer 2

確かに！

http://download.oracle.com/docs/cd/E17802_01/products/products/jms/javadoc-102a/index.html Message#setJMSExpiration(long)正確に何をしますか？