クライアントが接続を確立できない

症状:

• クライアントが新しい接続を確立できない。

• クライアントが障害の生じた接続を自動的に再接続できない。

考えられる原因:

• クライアントアプリケーションが接続を閉じていないため、接続数がリソース制限を超えてしまった。

• ブローカが実行されていないか、ネットワーク接続の問題が存在している。

• 接続サービスが非アクティブであるか停止している。

• 必要な接続数に対して使用可能なスレッドが少なすぎる。

• Solaris または Linux プラットフォーム上で必要な接続数に対してファイル記述子が少なすぎる。

• TCP バックログにより、確立可能な新しい同時接続要求の数が制限される。

• オペレーティングシステムによって同時接続の数が制限される。

• ユーザーの認証に失敗するか権限が与えられない。

考えられる原因: クライアントアプリケーションが接続を閉じていないため、接続数がリソース制限を超えてしまった。

この問題の原因を確認するには:ブローカへの接続をすべて一覧表示します。

imqcmd list cxn

出力にはすべての接続と各接続の確立元のホストが一覧表示されます。異常な数の接続が開かれている特定のクライアントがわかります。

問題を解決するには: 原因となっているクライアントが未使用の接続を閉じるようにプログラムし直します。

考えられる原因: ブローカが実行されていないか、ネットワーク接続の問題が存在している。

この問題の原因を確認するには:

• ブローカのプライマリポートへ telnet で接続し、ブローカがポートマッパー出力を返すか確認します。プライマリポートのデフォルトは 7676 です。

• ブローカプロセスがホスト上で実行されていることを確認します。

問題を解決するには:

• ブローカを起動します。

• ネットワーク接続の問題を修復します。

考えられる原因: 接続サービスが非アクティブであるか停止している。

この問題の原因を確認するには: すべての接続サービスのステータスを確認します。

imqcmd list svc

接続サービスのステータスが unknown または paused と表示された場合、クライアントはそのサービスを使用する接続を確立できません。

問題を解決するには:

• 接続サービスのステータスが unknown と表示された場合、そのサービスはアクティブサービスリスト (imq.service.active ) に含まれていません。SSL ベースのサービスの場合は、サービスが不適切に設定されているため、ブローカがブローカログに次のエントリを作成する可能性があります。

  ERROR [B3009]: Unable to start service ssljms: [B4001]: Unable to open protocol tls for ssljms service...

  例外の根本的な原因の説明が続きます。

  SSL サービスを適切に設定する方法については、「メッセージの暗号化」を参照してください。

• 接続サービスのステータスが paused と表示された場合は、サービスを再開します (「接続サービスの停止および再開」を参照)。

考えられる原因: 必要な接続数に対して使用可能なスレッドが少なすぎる。

この問題の原因を確認するには: ブローカログの次のエントリを確認します。

WARNING [B3004]: No threads are available to process a new connection on service ... Closing the new connection.

また、次の形式のうちいずれかを使用し、接続サービスの接続数と現在使用中のスレッド数を確認します。

imqcmd query svc -n serviceName imqcmd metrics svc -n serviceName -m cxn

接続ごとに 2 つのスレッドが必要です。1 つは受信メッセージ用、もう 1 つは出力メッセージ用です (「スレッドプール管理」を参照)。

問題を解決するには:

• 専用スレッドプールモデル (imq. serviceName.threadpool_model= dedicated) を使用している場合、接続の最大数は、スレッドプールにあるスレッドの最大数の半分です。そのため、接続数を増やすには、スレッドプール (imq. serviceName.max_threads) のサイズを拡大するか、共有スレッドプールモデルに切り換えます。

• 共有スレッドプールモデル (imq. serviceName.threadpool_model=shared) を使用している場合、接続の最大数は、接続監視制限 (imq.serviceName.connectionMonitor_limit ) とスレッドの最大数 (imq. serviceName.max_threads) の 2 つのプロパティーの結果の半分です。そのため、接続数を増やすには、スレッドプールのサイズを拡大するか、接続監視制限の値を大きくします。

• 最終的に、サポート可能な接続の数または接続のスループットが入力/出力制限に達してしまいます。このような場合は、マルチブローカクラスタを使用して、クラスタ内のブローカインスタンス間で接続を分散します。

考えられる原因: Solaris または Linux プラットフォーム上で必要な接続数に対してファイル記述子が少なすぎる。

この問題については、「ファイル記述子制限の設定」を参照してください。

この問題の原因を確認するには:次のようなブローカログのエントリを確認します。

Too many open files

問題を解決するには: ulimit のマニュアルで説明しているとおり、ファイル記述子の制限を増やします。

考えられる原因: TCP バックログにより、確立可能な新しい同時接続要求の数が制限される。

TCP バックログにより、ポートマッパーが追加の要求を拒否するまでにシステムバックログ (imq.portmapper.backlog)) に格納可能な同時接続要求の数が制限されます。Windows プラットフォームでは、Windows デスクトップで 5、Windows サーバーで 200 というバックログ制限がハードコードされています。

通常、バックログ制限が原因の要求拒否は過渡的な現象であり、非常に多数の同時接続要求があると発生します。

この問題の原因を確認するには: ブローカログを調べます。最初に、ブローカが、その他の接続を拒否している期間に接続を受け入れているかどうかを確認します。次に、拒否された接続について説明するメッセージを確認します。このようなメッセージがある場合、TCP バックログが問題ではないと思われます。ブローカは、TCP バックログによる接続拒否をログしないからです。正常接続がログされ、接続拒否がログされない場合は、TCP バックログが問題と思われます。

問題を解決するには:

• クライアントが確立しようとする接続の再試行を短い間隔で行うようにプログラミングします。この問題の過渡的な性質上、このようにプログラミングしても正常に動作します。

• imq.portmapper.backlog の値を大きくします。

• クライアントが接続を閉じずに、多くの接続を開いていないか確認します。

考えられる原因: オペレーティングシステムによって同時接続の数が制限される。

Windows オペレーティングシステムのライセンスは、サポートされる同時リモート接続の数を制限します。

この問題の原因を確認するには: imqcmd query svc を使用して、接続用のスレッドが十分にあることを調べ、さらに Windows ライセンス契約書の条項を確認します。ローカルクライアントからは接続を確立できるが、リモートクライアントからは確立できない場合は、オペレーティングシステムの制限が問題の原因と考えられます。

問題を解決するには:

• より多くの接続が許可されるように Windows ライセンスをアップグレードします。

• マルチブローカクラスタを設定して、多数のブローカインスタンスに接続を分散します。

考えられる原因: ユーザーの認証に失敗するか権限が与えられない。

認証は、次のいずれかの理由で失敗する場合があります。

• 不正なパスワード

• ユーザーリポジトリにユーザーのエントリがない

• ユーザーが接続サービスへのアクセス許可を持っていない

この問題の原因を確認するには: ブローカログのエントリで Forbidden エラーメッセージを確認します。このメッセージは、認証エラーを示しているだけで、その理由は示していません。

• ファイルベースのユーザーリポジトリを使用している場合は、次のコマンドを入力します。

  imqusermgr list -i instanceName -u userName

  出力にユーザーが表示された場合は、不正なパスワードの入力が原因と考えられます。出力に次のエラーが表示された場合は、ユーザーリポジトリにユーザーのエントリがありません。

  Error [B3048]: User does not exist in the password file

• LDAP サーバーのユーザーリポジトリを使用している場合は、適切なツールを使用して、ユーザーのエントリがあるかどうかを確認します。

• アクセス制御プロパティーファイルで、接続サービスへのアクセスが制限されていないかどうかを確認します。

問題を解決するには:

• 不正なパスワードが使用された場合は、正しいパスワードを入力し直します。

• ユーザーリポジトリにユーザーのエントリがない場合は追加します (「ユーザーリポジトリの設定と管理」を参照)。

• ユーザーが接続サービスへのアクセス許可を持っていない場合は、アクセス制御プロパティーファイルを編集し、アクセス許可を与えます (「接続サービスのアクセス制御」を参照)。