接続の処理

接続処理の属性では、接続先のブローカのアドレス、および必要に応じて、接続障害の検出方法と再接続の試行方法を指定します。これらの要約については、表 16–1を参照してください。

ブローカのアドレスリスト

もっとも重要な接続処理の属性は、接続の確立先となる 1 つ以上のブローカを指定する imqAddressList です。この属性の値は、ブローカのアドレスを 1 つ含む文字列、またはブローカクラスタの場合はコンマ区切りで複数含む文字列です。ブローカのアドレスには、使用する接続サービス (「接続サービス」を参照) と接続の確立方法に応じて、さまざまなアドレススキーマを使用できます。

• mq。jms または ssljms 接続サービスで、ブローカのポートマッパーを使用してポートを動的に割り当てます。

• mqtcp。jms 接続サービスを使用し、ポートマッパーをバイパスして、指定されたポートに直接接続します。

• mqssl。ssljms 接続サービスを使用し、指定されたポートへの SSL (Secure Socket Layer) 接続を作成します。

• http。httpjms 接続サービスを使用し、指定された URL の Message Queue トンネルサーブレットへの HTTP (Hypertext Transport Protocol) 接続を作成します。

• https。httpsjms 接続サービスを使用し、指定された URL の Message Queue トンネルサーブレットへの HTTPS (Secure Hypertext Transport Protocol) 接続を作成します。

これらのアドレススキーマの要約については、表 16–2を参照してください。

各ブローカアドレスの一般的な形式は、次のようになります。

scheme://address

scheme は、前述のアドレススキーマのいずれかで、address は、ブローカのアドレス自体を示します。アドレスを指定するための正確な構文は、表 16–2の最後の列に示すように、アドレススキーマによって異なります。表 16–3 に、さまざまなアドレス形式の例を示します。

複数のブローカによるクラスタ環境では、アドレスリストに複数のブローカアドレスを含めることができます。最初の接続試行に失敗すると、Message Queue クライアントランタイムは、リスト内の別のアドレスに接続を試行し、成功するまでリスト内のすべてのアドレスに順に接続を試みます。2 つの追加の接続ファクトリ属性によって、この方法を制御します。

• imqAddressListBehavior。指定したアドレスへの試行順序を指定します。この属性を文字列 PRIORITY に設定すると、アドレスリストに表示されている順序でアドレスが試行されます。属性値を RANDOM にすると、ランダムな順序でアドレスが試行されます。これは、たとえば、多数の Message Queue クライアントが同じ接続ファクトリオブジェクトを共有しているときに、すべてのクライアントが同じブローカアドレスに接続を試行するのを避けるためなどに便利です。

• imqAddressListIterations。試行を中止して失敗を報告するまでの、リストの繰り返し回数を指定します。値 -1 は、繰り返し回数が無制限であることを示します。つまり、クライアントランタイムは、接続の確立に成功するか時間切れになるまで試行を続けます。

自動再接続

接続ファクトリの imqReconnectEnabled 属性を true に設定すると、接続に障害が発生した場合にクライアントがブローカに自動的に再接続するように設定できます。imqReconnectAttempts 属性では、特定のブローカアドレスに再接続を試行する回数を制御します。imqReconnectInterval 属性では、試行の間隔をミリ秒単位で指定します。

ブローカのアドレスリスト (imqAddressList) で複数のアドレスを指定するブローカクラスタでは、障害の発生した接続を、元のブローカだけでなく、クラスタ内の別のブローカでも復元できます。元のブローカへの再接続に失敗すると、クライアントランタイムは、リスト内のほかのアドレスを試行します。前述のとおり、imqAddressListBehavior および imqAddressListIterations 属性で、アドレスの試行順序とリストの繰り返し回数を制御します。各アドレスは、imqReconnectInterval ミリ秒の間隔で、imqReconnectAttempts を最大回数として、繰り返し試行されます。

自動再接続では、メッセージの消費に関するすべてのクライアント通知モードがサポートされます。接続が再確立されると、ブローカは、以前に配信した未通知メッセージをすべて再配信し、それらに Redeliver フラグを付けます。アプリケーションコードでは、このフラグを使用して、特定のメッセージが消費されたが未通知であるかどうかを判断できます。ただし、永続的でないサブスクライバの場合、ブローカは、接続が閉じられたあとはメッセージを保持しません。そのため、接続がダウンしている間にそれらのサブスクライバに対して生成されたメッセージは、再接続後に配信できず、失われることになります。自動再接続中は、メッセージ生成がブロックされます。メッセージプロデューサは、接続の再確立が完了するまで、ブローカにメッセージを送信できません。

自動再接続は、接続のフェイルオーバーを提供しますが、データのフェイルオーバーは実行しません。障害の発生したブローカまたは切断されたブローカが保持する持続メッセージ、その他の状態情報は、クライアントが別のブローカインスタンスに再接続すると失われることがあります。接続の再確立の試行中、Message Queue によって、クライアントランタイムが提供したオブジェクト (セッション、メッセージコンシューマ、メッセージプロデューサなど) は維持されます。一時的送信先も、接続に障害が発生したときは、クライアントがそれらの送信先に再接続して再度アクセスする可能性があるため、当面は維持されます。再接続してそれらの送信先を使用するための時間をクライアントに与えたあとで、ブローカはそれらを削除します。再接続時にブローカでクライアント側の状態を完全に復元できない場合 (たとえば、接続の間のみ存在する処理済セッションを使用している場合など) は、自動再接続は行われず、代わりに接続の例外ハンドラが呼び出されます。その後の例外のキャッチ、再接続、および状態の復元は、アプリケーションコードに任されます。

接続の定期的なテスト (ping)

Message Queue クライアントランタイムは、接続を定期的にテストする、つまり「ping」を実行するように設定できます。これにより、メッセージ転送に失敗する前に、予防的に接続の障害を検出できます。メッセージを消費するだけで生成しないクライアントアプリケーションでは、接続の障害を検出する手段がほかにないため、このようなテストが特に重要です。メッセージをたまに生成するだけのクライアントでも、この機能が役立ちます。

接続ファクトリ属性 imqPingInterval では、接続で ping を実行する頻度を秒単位で指定します。デフォルトでは、この間隔は 30 秒に設定されます。値 -1 を指定すると、ping の実行が無効になります。

失敗した ping への対応は、オペレーションシステムのプラットフォームによって異なります。一部のオペレーティングシステムでは、ただちに、クライアントアプリケーションの例外リスナーに例外がスローされます。クライアントに例外リスナーがない場合は、その接続を使用するための次回の試行に失敗します。また、オペレーティングシステムによっては、ブローカへの接続の確立を試行し続け、ping が成功するかバッファーがオーバーフローするまで、一連の ping をバッファリングするものもあります。