2016-12-08 8 views
0

プロジェクトでは、バッチ処理とパーティション分割ジョブを幅広く使用しています。場合によっては、メッセージが失われてしまうためにパーティション化されたジョブの問題が「ハングアップ」することがあります。リモートパーティションはすべて完了しますが、親ステップはSTARTEDにとどまります。私たちの設定では、1つの接続ファクトリを使用してキュー(受信ゲートウェイ)からメッセージを読み込み、クラスタ化された別の接続からパーティションメッセージ(送信ゲートウェイ)を送信します。この理由は、JBossのメッセージングは​​クラスタ全体でメッセージを一様に配信しないため、クライアント接続ファクトリがその機能を提供するからです。JMSの問題JBoss 5.2でパーティション化されたジョブを使用したバッチ処理EAP

レッドハットが入ってきて、春と構成で率直に投げた。そのレポート


ザ・春JMSTemplateコードからされている以下の抜粋は、接続を閉じ、単にメッセージを送信するために、新しい接続、セッション、プロデューサーの作成など、いくつかのアンチパターンを採用しています。また、メッセージを受信すると毎回コンシューマを作成し、 メッセージを受信して​​からコンシューマを閉じることができます。これは、負荷がかかるとパフォーマンスが低下する可能性があります。アンチパターンを使用すると、パフォーマンスが低下するだけでなく、接続リソースの一部が非同期に解放されるため、オペレーティングシステムのリソース(たとえば、 スレッドおよびファイルハンドル)が枯渇する可能性があります。さらに、耐久性のないトピックのサブスクライバでは、 の閉鎖と次の消費者のオープンとの間に受信されたメッセージは失われるため、メッセージを失うことになります。 Spring JMSTemplateは、JCA管理接続ファクトリ(通常は "java:/ JmsXA")を使用してアプリケーションサーバ内にあり、メッセージを送信するときにのみ動作します。 JCA管理接続ファクトリは、毎回実際には作成されないように接続をキャッシュします。ただし、JCA管理接続ファクトリを使用しても、キャッシュされないため、コンシューマの問題は解決されません。 要約すると、Spring JMSTemplateは、JCA管理接続ファクトリ(java:/ JmsXA)を持つアプリケーションサーバ内でそれを使用し、その場合にのみメッセージを送信するという非常に特殊な使用例以外は、安全に使用することはできません メッセージを消費するために使用します)。 アプリケーション・サーバー外のJMSクライアント・アプリケーションからの使用は決して安全ではなく、標準接続ファクトリー(「ConnectionFactory」、「ClusteredConnectionFactory」、「jms/RemoteConnectionFactory」など)で使用すると、 は安全です。メッセージを受信するためにそれを使用することは決して安全ではありません。 Springを使ってメッセージを安全に受信するには、MessageListenerContainers [7]をMessageDriven Pojos [8]とともに使用することを検討してください。 最後に、発生した問題はJMSのアンチパターンに基づいているため、JBoss EAP固有の問題ではないことに注意してください。例えば、ActiveMQ [9]に関する同様の議論を見てください。 Red Hatは、JCA管理接続ファクトリ経由でメッセージを送信するための許容可能なユースケースとは別に、JBoss MessagingでSpring JMSTemplateを使用することをサポートしていません。

提言

●春のJMSについては、原則として、JCAは、JBoss EAPで構成された接続ファクトリを管理します。 Spring構成の接続ファクトリは使用しないでください。 JNDIテンプレートを使用して、接続ファクトリをJBossからSpringにプルします。これにより、ほとんどのSpring JMSの問題が解消されます。 ●バッチジョブでは、Spring JMSではなく標準JMSを使用します。 Springは標準ではない(おそらくJMSの準標準実装です)。標準JMSは、少数の送信者のプールを使用してメッセージを送信し、メッセージの送信後にセッションを閉じます。リスナー側では、標準JMSは分散キューまたはトピックをリスニングする一連の作業を使用します。各WebサーバーにはJMSリスナーがシングルトンとしてデプロイされており、標準javaオブザーバを使用して にコールバックを待っているすべての呼び出し元に通知します。


JMS接続ファクトリはJBossで設定され、JNDI経由でロードされます。

あなたの評価についてのご意見はありますか?

答えて

0

送信ごとに新しい接続/セッションを作成するオーバーヘッドを避けるには、プロバイダーの接続ファクトリをCachingConnectionFactoryにラップする必要があります。センドとキャッシュセッション、プロデューサ、コンシューマに対して同じ接続を再利用します。

関連する問題