リスナー・ポート設定

リスナー・ポートは、接続ファクトリー、宛先、およびデプロイ済みのメッセージ駆動型 Bean の間の関連を定義します。 この関連付けにより、ポートに関連付けられているデプロイ済みのメッセージ駆動型 Bean は、 宛先からメッセージを検索できるようになります。

このパネルを使用して、選択したリスナー・ポートの構成プロパティーを表示または変更します。

この管理コンソール・ページを表示するには、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」->server_name > [通信]「メッセージング」 > 「メッセージング・リスナー・サービス」 > [追加プロパティー]「リスナー・ポート」 > 「listener_port」をクリックします。

名前

管理目的でリスナー・ポートを使用する際の名前。

通知
データ型 ストリング
デフォルト Null

初期状態

アプリケーション・サーバーを次に再始動したときのリスナー・ポートの状態。

通知
データ型 列挙型
単位 該当なし
デフォルト 始動済み
範囲
始動済み
アプリケーション・サーバーの次回始動時に、リスナー・ポートを自動的に始動します。
停止済み
アプリケーション・サーバーの次回始動時に、 リスナー・ポートを自動的に始動しません。 メッセージ駆動型 Bean がアプリケーション・サーバー上でこのリスナー・ポートを使用することになっている場合、 システム管理者はポートを手動で開始するか、 またはこのプロパティーの「開始済み」値を選択してからアプリケーション・サーバーを再始動する必要があります。

説明

IBM® WebSphere Application Server 内で、管理を目的とした、リスナー・ポートの説明。

通知
データ型 ストリング
デフォルト Null

接続ファクトリー JNDI 名

リスナー・ポートで使用される JMS 接続ファクトリーの JNDI 名。 例えば、jms/connFactory1

通知
データ型 ストリング
デフォルト Null

宛先 JNDI 名

リスナー・ポートで使用される宛先の JNDI 名。例えば、jms/destn1

遅延応答の一時的な宛先は使用できません。

通知
データ型 ストリング
デフォルト Null

最大セッション

リスナーが、メッセージ処理のために JMS サーバーとの間に確立できる並行セッション最大数。

それぞれのセッションには、分離したリスナー・スレッドが対応しています。このため、これらのセッションは、 並列処理メッセージの数を制御します。サーバーがマシンで使用可能な能力を完全に使用していない場合に、このパラメーターを調整します。

通知
データ型 整数
単位 セッション
デフォルト 1
範囲 1 から 2147483647
推奨
  • メッセージを並行処理する、つまり、同時に複数のメッセージを処理する場合には、このプロパティーを 1 より大の値に設定します。 クライアント・アプリケーションの過負荷を避けるために、この値は可能な限り小さくしてください。短時間トランザクションを使用した 100% JMS ワークロードにおける適切な開始点は、CPU 当り 2 から 4 セッションです。 長期実行トランザクションが存在する場合には、より多くのセッションが必要な場合があります。これはテストを行って決定します。

    構成されているすべてのリスナー・ポートの「最大セッション」プロパティーに指定されたセッションの総数が、メッセージ・リスナー・サービス・スレッド・プールの「最大サイズ」プロパティーに指定されたスレッド数以下である必要があります。

最大再試行数

リスナーが、停止するまでにメッセージ駆動型 Bean インスタンスにメッセージの配信を試みる最大回数 (範囲は 0 から 2147483647 まで)。

注: WebSphere MQ キューには、BackoutThreshold プロパティーと呼ばれる類似プロパティーがあります。 リスナー・ポートが WebSphere MQ キューから読み取りを行っている場合は、再試行制限およびその制限に達した場合の動作が、下限に設定されている以下の 2 つのプロパティーのいずれかによって決定されます。
  • WebSphere MQ キューの BackoutThreshold 制限値を超えた場合は、配信できないメッセージは WebSphere MQ によって別の場所 (例えば、WebSphere MQ バックアウト再キューイング・キューまたは WebSphere MQ デッド・レター・キュー) に移動され、リスナー・ポートでキュー内の次のメッセージが処理されます。この場合、WebSphere Application Server は、メッセージが正常に配信されなかったことを認識しない可能性があります。
  • リスナー・ポートの「最大再試行数」制限値を超えた場合は、リスナー・ポートが停止します。 その場合は、手動で操作を行って問題を調べます。場合によっては、メッセージを WebSphere MQ キューから除去して、リスナー・ポートを再始動します。
通知
データ型 整数
単位 再試行の回数
デフォルト 0 (再試行しない)
範囲 0 (再試行しない) から 2147483647

最大メッセージ数

リスナーが、1 つのトランザクションで処理できるメッセージの最大数。

キューが空の場合、リスナーは、メッセージを受け取ると、各メッセージを処理します。 各メッセージは、個別のトランザクション内で処理されます。

JMS プロバイダーとして WebSphere MQ を使用する場合、 キューにメッセージが累積し始めると、リスナーはメッセージのバッチ処理を開始することができます。サード・パーティーのメッセージング・プロバイダーの場合、このプロパティー値は JMS プロバイダーに渡されますが、その影響は JMS プロバイダーによって異なります。

通知
データ型 整数
単位 メッセージ数
デフォルト 1
範囲 1 から 2147483647
推奨
JMS プロバイダーとして WebSphere MQ を 使用する場合、複数のメッセージを単一トランザクションで処理するには、この値を 1 より大きく設定します。 メッセージがキューに累積し始めた場合、値が 1 より大きいと、複数のメッセージをバッチ処理して 単一トランザクションにでき、JMS メッセージのトランザクション処理のコストをかなり削減できます。
注意:
  • バッチ内の 1 つのメッセージが処理に失敗し、例外が発生した場合は、メッセージ・バッチ全体が処理のためのキューに戻されます。
  • 個々のメッセージごとの任意の対話によって保持されるすべてのリソース・ロックは、すべてのバッチ処理中は保持されます。
  • XA トランザクションが使用されている場合に、メッセージが必要とする処理の量に応じて 1 より大きな値を設定すると、トランザクションがタイムアウトすることがあります。 複数のメッセージの処理がトランザクション・タイムアウトを超えるために日常的に XA トランザクションがタイムアウトする場合は、このプロパティーを 1 に減らすか (トランザクションごとに 1 つのメッセージに処理を限定する)、またはトランザクション・タイムアウトを増やします。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=umb_prolp
ファイル名:umb_prolp.html