Application Server は JMS 接続プールとフェイルオーバーをサポートします。Sun Java System Application Server は JMS 接続を自動的にプールします。「アドレスリストの動作」属性が random (デフォルト) である場合、Application Server は主ブローカを JMS ホストリストからランダムに選択します。フェイルオーバーが発生すると、MQ は負荷を別のブローカに透過的に転送し、JMS セマンティクスを保持します。JMS タイプが LOCAL タイプの場合、「アドレスリストの動作」属性のデフォルト値は priority です。
接続が失われたときに Application Server が主ブローカへの再接続を試行するかどうかを指定するには、「再接続」チェックボックスを選択します。再接続を有効に設定した状態で、主ブローカが停止すると、Application Server は JMS ホストリストにある別のブローカへの再接続を試みます。
「再接続」を有効にする場合には、以下の属性も指定します。
アドレスリストの動作: 接続を、JMS ホストリスト内のアドレスの順序 (priority) とランダムな順序 (random) のどちらで行うかを指定します。Priority に設定すると、Java Message Serviceは JMS ホストリストの最初に指定された MQ ブローカに接続を試行し、そのブローカが利用できない場合にのみ別のブローカを使用します。Random に設定すると、Java Message Serviceは JMS ホストリストから MQ ブローカをランダムに選択します。多数のクライアントが同じ接続ファクトリを使用して接続を試行する場合は、すべてのクライアントが同じアドレスに接続しないようにこの設定を使用します。
アドレスリストの繰り返し: 接続の確立または再確立のために、JMS ホストリストを介して Java Message Service が試行を繰り返す回数です。値 -1 は試行回数が無制限であることを示します。
再接続試行: クライアントランタイムがリストの次のアドレスを試行する前に、JMS ホストリストに指定した各アドレスへの接続 (または再接続) を試行する回数を指定します。値 -1 は、再試行回数が無制限であることを示します。クライアントランタイムは、接続が成功するまで最初のアドレスへの接続を試みます。
再接続間隔: 再接続を試行する間隔を秒数で指定します。これは、JMS ホストリストで指定した各アドレスおよびリストのそれ以降のアドレスへの試行に適用されます。間隔が短すぎると、ブローカにリカバリする時間が与えられません。間隔が長すぎると、再接続が許容できない遅延を示す場合があります。
これらの設定は、JMS 接続ファクトリ設定を使用してオーバーライドできます。詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「JMS 接続ファクトリ」を参照してください。
メッセージ駆動型 Bean の sun-ejb-jar.xml ファイル内の activation-config-property 要素を使用して、jmsra リソースアダプタの ActivationSpec プロパティーを設定できます。メッセージ駆動型 Bean (EndPointFactory) が配備されるたびに、コネクタランタイムエンジンがこれらのプロパティーを検出し、それに従ってリソースアダプタ内でそれらのプロパティーを設定します。『Sun Java System Application Server 9.1 Application Deployment Guide』の「activation-config-property」を参照してください。
Application Server は、同じ ClientID を持つメッセージ駆動型 Bean へのランダムなメッセージ配信を透過的に実現します。ClientID は永続的なサブスクライバには必須です。
ClientID が設定されない非永続サブスクライバに対しては、同じトピックをサブスクライブする特定のメッセージ駆動型 Bean のすべてのインスタンスは同等であると見なされます。メッセージ駆動型 Bean がApplication Server の複数のインスタンスに配備される場合、メッセージ駆動型 Bean のうちの1 つだけがメッセージを受信します。複数の異なるメッセージ駆動型 Bean が同じトピックをサブスクライブすると、メッセージ駆動型 Bean ごとに1 つのインスタンスがメッセージのコピーを受信します。
同じキューを使用する複数のコンシューマをサポートするには、物理送信先の maxNumActiveConsumers プロパティーを大きい値に設定します。このプロパティーを設定すると、Sun Java System Message Queue ソフトウェアはプロパティーに設定した数までメッセージ駆動型 Bean は同じキューからメッセージを消費することを許可します。メッセージはそれらのメッセージ駆動型 Bean にランダムに配信されます。maxNumActiveConsumers を -1 に設定した場合は、コンシューマの数に制限はありません。
ローカル配信が優先されることを保証するには、addresslist-behavior を priority に設定します。この設定は、AddressList 内の最初のブローカが最初に選択されることを指定します。この最初のブローカは、ローカルで共存する Message Queue インスタンスです。このブローカが利用できない場合、AddressList 内で列挙されている順序でブローカへの接続試行が行われます。この設定は、クラスタに属する Application Server インスタンスに対するデフォルトです。
クラスタ化機能は開発者プロファイルでは利用できません。プロファイルの詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「使用法プロファイル」を参照してください。
JMS コンポーネントには、次の2 つのレベルの可用性があります。
サービス可用性 – このレベルでは JMS サービスの可用性が問題になりますが、メッセージがしばらくの間利用できないかどうかは重要ではありません。サービスを提供している新規の利用可能なインスタンスに接続がフェイルオーバーされる限り、JMS コンポーネントは、そのサービスは利用可能であり正常に機能していると認識します。このレベルの可用性については、『Sun Java System Application Server 9.1 Developer’s Guide』の「Connection Failover」で説明されています。
データ可用性 – このレベルでは、サービスの可用性と持続メッセージの両方が必須です。1回および1 回限りの配信とメッセージ順序付けの JMS セマンティクスもこのレベルで扱われます。
データ可用性は、Java Message Service (JMS) に準拠する Sun Java System Message Queue クラスタで有効にできます。メッセージは共通持続ストアに持続化され、クラスタ内のほかのすべてのブローカインスタンスから利用可能です。また、高可用性データベース (HADB) がインストールされていて、エンタープライズプロファイルが選択されている場合は、そのデータベースからも利用可能です。プロファイルの詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「使用法プロファイル」を参照してください。対応するブローカに対してデータ可用性を有効にする前に、Application Server インスタンスに対して可用性を有効にする必要があります。
個別のアプリケーションおよびモジュールは、JMS の可用性を制御またはオーバーライドできません。
データ可用性を有効にするには、管理コンソールの関連する設定下で「可用性サービス」コンポーネントを選択します。「可用性サービス」ボックスにチェックマークを付けます。JMS サービスの可用性を有効にするには、「JMS の可用性」タブを選択して「可用性サービス」ボックスにチェックマークを付けます。動作の一貫性を保証するために、Application Server クラスタ内のすべてのインスタンスで、インスタンス可用性および JMS 可用性の設定を統一してください。詳細については、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』を参照してください。
クラスタ化機能は開発者プロファイルでは利用できません。プロファイルの詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「使用法プロファイル」を参照してください。