この章では、Application Server で使用するために Java Message Service (JMS) の負荷分散とフェイルオーバーを設定する方法について説明します。ここで説明する内容は次のとおりです。
Java Message Service (JMS) API は、Java EE アプリケーションおよびコンポーネントに対して、メッセージの作成、送信、受信、および読み取りを可能にするメッセージング標準です。この API によって、緩やかに結合され、信頼性が高く、非同期の分散通信が可能となります。Sun Java System Message Queue (MQ) は JMS を実装し、Application Server と密接に統合されているため、MQ を使用してメッセージ駆動型 Bean (MDB) などのコンポーネントを作成できます。
MQ はコネクタモジュールを使用して Application Server と統合されます。コネクタモジュールはリソースアダプタとしても知られており、Java EE Connector Architecture Specification 1.5 によって定義されています。Application Server に配備された Java EE コンポーネントは、コネクタモジュールを介して統合された JMS プロバイダを使用して、JMS メッセージをやり取りします。Application Server で JMS リソースを作成すると、バックグラウンドでコネクタリソースが作成されます。そのようにして、JMS 操作のたびにコネクタランタイムが呼び出され、バックグラウンドで MQ リソースアダプタが使用されます。
Java Message Service は、管理コンソールまたは asadmin コマンド行ユーティリティーから管理することができます。
JMS リソースの設定の詳細については、『Sun Java System Application Server 9.1 管理ガイド』の第 4 章「Java Message Service (JMS) リソースの設定」を参照してください。JMS の詳細については、『Sun Java System Application Server 9.1 Developer’s Guide』の第 18 章「Using the Java Message Service」を参照してください。コネクタ (リソースアダプタ) の詳細については、『Sun Java System Application Server 9.1 Developer’s Guide』の第 12 章「Developing Connectors」を参照してください。
Sun Java System Message Queue の詳細については、Message Queue マニュアルを参照してください。JMS API の概要については、JMS Web ページを参照してください。
「Java Message Service」設定は、Sun Java System Application Server クラスタまたはインスタンスへのすべてのインバウンドおよびアウトバウンド接続に使用できます。次にあげるものを使用して、Java Message Service を設定できます。
管理コンソール。関連する設定で「Java メッセージサービス」コンポーネントを開きます。詳細については、『Sun Java System Application Server 9.1 管理ガイド』の第 4 章「Java Message Service (JMS) リソースの設定」を参照してください。
server.jms-service.init-timeout-in-seconds = 60 server.jms-service.type = LOCAL server.jms-service.start-args = server.jms-service.default-jms-host = default_JMS_host server.jms-service.reconnect-interval-in-seconds = 60 server.jms-service.reconnect-attempts = 3 server.jms-service.reconnect-enabled = true server.jms-service.addresslist-behavior = random server.jms-service.addresslist-iterations = 3 server.jms-service.mq-scheme = mq server.jms-service.mq-service = jms
次のようなプロパティーも設定できます。
server.jms-service.property.instance-name = imqbroker server.jms-service.property.instance-name-suffix = server.jms-service.property.append-version = false
Java Message Service のすべての属性とプロパティーを一覧表示するには、asadmin get コマンドを使用します。asadmin get の詳細については、get(1)を参照してください。asadmin set の詳細については、set(1)を参照してください。
JMS 接続ファクトリの設定を使用して、Java Message Service の設定をオーバーライドできます。詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「JMS 接続ファクトリ」を参照してください。
Java Message Service の設定を変更したあとには、Application Server インスタンスを再起動する必要があります。
JMS 管理の詳細については、『Sun Java System Application Server 9.1 管理ガイド』の第 4 章「Java Message Service (JMS) リソースの設定」を参照してください。
MQ を Application Server に統合する方法には、LOCAL、REMOTE、および EMBEDDED の 3 通りがあります。管理コンソールでは、これらのモードは Java Message Service の「タイプ」属性で表されます。
「タイプ」属性が LOCAL (クラスタインスタンスのデフォルト) の場合、Application Server はデフォルト JMS ホストとして指定された MQ ブローカを起動および停止します。MQ プロセスはアウトプロセスで (別個の VM 内で) Application Server プロセスから起動されます。Application Server は、追加のポートをブローカに提供します。このポートはブローカによって、RMI レジストリを起動するために使用されます。このポート番号は、そのインスタンスに対して設定済みの JMS ポートの番号に 100 を加えたものです。たとえば、JMS ポート番号が 37676 の場合、この追加のポート番号は 37776 になります。
Application Server インスタンスと Message Queue ブローカの間に 1 対 1 の関係を作成するには、タイプを LOCAL に設定し、各 Application Server インスタンスに異なるデフォルト JMS ホストを指定します。この作業は、クラスタが Application Server と MQ のどちらに定義されているかに関係なく行えます。
LOCAL タイプでは、「起動引数」属性を使用して MQ ブローカの起動パラメータを指定します。
「タイプ」属性が REMOTE の場合、MQ ブローカは別個に起動する必要があります。ブローカの起動については、『 Sun Java System Message Queue 管理ガイド』を参照してください。
この場合、Application Server は外部的に設定されたブローカまたはブローカクラスタを使用します。また、MQ ブローカの起動と停止は Application Server とは別個に行い、MQ ツールを使用してブローカまたはブローカクラスタを設定および調整する必要があります。REMOTE タイプは Application Server クラスタに最適です。
REMOTE タイプでは、MQ ツールを使用して MQ ブローカ起動パラメータを指定する必要があります。「起動引数」属性は無視されます。
JMS の「タイプ」属性が EMBEDDED の場合、アプリケーションサーバーと JMS ブローカが同じ VM 内に共存し、JMS サービスはインプロセスで起動され、Application Server によって管理されます。このモードでは、JMS 操作はネットワークスタックを通して行われ、パフォーマンスの最適化につながります。
JMS ホストは MQ ブローカを表します。Java Message Service には JMS ホストリスト (AddressList とも呼ばれる) が含まれており、このリストには Application Server が使用するすべての JMS ホストが含まれます。
JMS ホストリストには指定された MQ ブローカのホストとポートが取り込まれ、JMS ホスト設定が変更になるたびに更新されます。JMS リソースを作成するかまたは MDB を配備すると、JMS リソースや MDB は JMS ホストリストを継承します。
Sun Java System Message Queue ソフトウェアでは、AddressList プロパティーは imqAddressList と呼ばれています。
JMS ホストリスト内のホストの 1 つが、Default_JMS_host という名前のデフォルト JMS ホストに指定されます。Application Server インスタンスは、Java Message Service のタイプが LOCAL に設定されている場合に、デフォルト JMS ホストを起動します。
Sun Java System Message Queue ソフトウェア内にマルチブローカクラスタを作成してある場合は、デフォルト JMS ホストを削除してから、その Message Queue クラスタのブローカを JMS ホストとして追加します。この場合、デフォルト JMS ホストがJMS ホストリスト内の最初のホストになります。
Application Server が Message Queue クラスタを使用する場合には、デフォルト JMS ホスト上で Message Queue 固有のコマンドが実行されます。たとえば、3 つのブローカを持つ Message Queue クラスタ用に物理送信先を作成する場合、物理送信先を作成するコマンドはデフォルトの JMS ホスト上で実行されますが、クラスタ内の 3 つのブローカすべてがその物理送信先を使用します。
管理コンソールを使用します。関係する設定の「Java メッセージサービス」コンポーネントを開き、「JMS ホスト」コンポーネントを選択してから、「新規」をクリックします。詳細については、管理コンソールのオンラインヘルプを参照してください。
asadmin create-jms-host コマンドを使用します。詳細については、create-jms-host(1)を参照してください。
JMS ホスト設定が変更されるたびに、JMS ホストリストは更新されます。
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 管理ガイド』の「使用法プロファイル」を参照してください。
MQ Enterprise Edition は、ブローカクラスタと呼ばれる、相互に接続した複数のブローカインスタンスをサポートします。ブローカクラスタによって、クライアント接続はクラスタ内のすべてのブローカに分散されます。クラスタ化することで、水平方向のスケーラビリティーが提供され、可用性が向上します。
この節では、高可用性を備えた Sun Java System Message Queue クラスタを使用するために Application Server を設定する方法を説明します。また、Message Queue クラスタを開始および設定する方法も解説します。
Application Server および MQ 配備のトポロジの詳細については、『Sun Java System Application Server 9.1 配備計画ガイド』の「Message Queue ブローカの配備の計画」を参照してください。
Sun Java System Message Queue 4.1 は、新しい「高可用性」クラスタタイプを通じて高可用性メッセージングサービスを提供します。このタイプの MQ クラスタでは、すべてのブローカインスタンスがピアツーピア関係を共有し、すべてのブローカインスタンスが共通の持続データストアを共有するため、データ可用性が提供されます。インスタンスでは、インスタンスで障害が発生したかどうかを自動的に検出し、障害が発生したブローカの持続メッセージのテイクオーバーを、テイクオーバー選出を通じて動的に実行できます。したがって、Application Server に配備されるアプリケーションコンポーネントはこれらの可能性機能を利用できます。
このクラスタタイプでは、キューまたは永続トピックサブスクリプションにトランザクション処理される持続メッセージの損失は一切ありません。永続的でないサブスクライバへの持続的でないメッセージまたは持続的メッセージは、クライアントランタイムが接続されているブローカが利用不能になったときに、失われる可能性があります。
HADB を起動します。
Application Server ドメインを作成し、そのドメインを起動します。ドメインの作成には asadmin コマンドの create-domain を、そのドメインの起動には start-domain をそれぞれ使用します。これらのコマンドの詳細については、create-domain(1) および start-domain(1) を参照してください。
ノードエージェントを作成して起動します。ノードエージェントの作成には asadmin コマンドの create-node-agent を、そのエージェントの起動には start-node-agent をそれぞれ使用します。これらのコマンドの詳細については、create-node-agent(1) および start-node-agent(1) を参照してください。
クラスタを作成します。クラスタの作成は、asadmin コマンドの create-cluster、または管理コンソールを使用して行うことができます。create-cluster コマンドの詳細については、create-cluster(1) を参照してください。管理コンソールを使用してクラスタを作成する方法については、管理コンソールのオンラインヘルプを参照してください。
クラスタ内にインスタンスを作成します。インスタンスの作成中に、リモートブローカによって使用されている JMS プロバイダのポート番号を指定します。このポート番号を指定しない場合、デフォルトの JMS プロバイダポート番号が使用されます。インスタンスの作成は、管理コンソール、または asadmin コマンドの create-instance を使用して行うことができます。管理コンソールを使用してインスタンスを作成する方法については、管理コンソールのオンラインヘルプを参照してください。create-instance コマンドの詳細については、create-instance(1) を参照してください。
クラスタを起動します。これは管理コンソール、または asadmin コマンドの start-cluster を使用して行うことができます。管理コンソールを使用してクラスタを起動する方法については、管理コンソールのオンラインヘルプを参照してください。start-cluster コマンドの詳細については、start-cluster(1) を参照してください。
asadmin コマンドの configure-ha-cluster を使用して HA クラスタを設定します。コマンドの詳細については、configure-ha-cluster(1) を参照してください。
HADB を起動します。
データベース表を作成します。
高可用性ブローカクラスタを作成している場合、HA ドライバをコピーします。
cp $AS_HOME/hadb/4.4.3-6/lib/hadbjdbc4.jar $S1AS_HOME/imq/lib/ext
ドメインを作成して起動します。これを行うには、コマンド asadmin create-domain および start-domain を使用します。これらのコマンドの詳細については、create-domain(1) および start-domain(1) を参照してください。
ノードエージェントを作成して起動します。これを行うには、asadmin コマンド create-domain および start-node-agent を使用します。これらのコマンドの詳細については、create-node-agent(1) および start-node-agent(1) を参照してください。
クラスタを作成します。クラスタの作成は、asadmin コマンドの create-cluster、または管理コンソールを使用して行うことができます。詳細については、create-cluster(1) を参照してください。管理コンソールを使用してクラスタを作成する方法については、管理コンソールのオンラインヘルプを参照してください。
クラスタ内にインスタンスを作成します。インスタンスの作成中に、リモートブローカによって使用されている JMS プロバイダのポート番号を指定します。このポート番号を指定しない場合、デフォルトの JMS プロバイダポート番号が使用されます。
デフォルトの JMS ホストを削除し、インスタンスが接続できる JMS ホストを作成します。必ず、各ブローカは独立した JMS ホストとして追加してください。JMS ホストの詳細については、「JMS ホストリスト」を参照してください。
JMS タイプを Remote に設定します。これは asadmin コマンドの set を使用して、または管理コンソールの「JMS サービス」ページから行うことができます。
高可用性ブローカを設定している場合、「JMS の可用性」を true に設定します。これは asadmin コマンドの set を使用して、または管理コンソールの「JMS の可用性」ページから行うことができます。
ブローカインスタンスを起動します。
クラスタを起動します。詳細については、start-cluster(1) を参照してください。
これまでは、この節のあとの手順で説明されているように、「非高可用性」MQ クラスタ (マスターブローカを持つ MQ クラスタ) を管理者が個別に設定する必要がありました。このリリースでは、(REMOTE タイプの) 手動でのプロセスによる MQ クラスタの設定に加えて、Application Server は「自動クラスタ化」を提供します。これは、ユーザーが Application Server クラスタを作成するときに、(LOCAL タイプの) 共存する非 HA クラスタが自動的に作成されることを意味します。これは MQ クラスタの作成のデフォルトモードになります。たとえば、3 つの Application Server インスタンスを持つ Application Server クラスタを管理者が作成すると、各 Application Server インスタンスは共存するブローカと連動するように設定され、結果的に MQ クラスタが透過的に 3 つの MQ ブローカインスタンスを形成します。最初の Application Server インスタンスの MQ ブローカがマスターブローカに設定されます。ただし、自動クラスタ化には短所もあります。管理者がクラスタにインスタンスを追加する場合、自動的に作成される MQ ブローカインスタンスはクラスタに参加できません。この動作は、インスタンスがクラスタから削除される場合にも適用されます。
クラスタが REMOTE タイプの場合、次の手順を実行します。クラスタが LOCAL タイプの場合、手順 1 〜 4 は該当しません。
Application Server クラスタを作成します (まだクラスタがない場合)。
クラスタの作成については、「クラスタを作成する」を参照してください。
MQ ブローカクラスタを作成します。
まず、ドメイン管理サーバーによって起動されるブローカを参照するデフォルト JMS ホストを削除してから、MQ ブローカクラスタに 3 つの外部ブローカ (JMS ホスト) を作成します。
JMS ホストの作成は、管理コンソールまたは asadmin コマンド行ユーティリティーのいずれかを使用して行います。
asadmin を使用する場合は、たとえば次のコマンドを実行します。
asadmin delete-jms-host --target cluster1 default_JMS_host asadmin create-jms-host --target cluster1 --mqhost myhost1 --mqport 6769 --mquser admin --mqpassword admin broker1 asadmin create-jms-host --target cluster1 --mqhost myhost2 --mqport 6770 --mquser admin --mqpassword admin broker2 asadmin create-jms-host --target cluster1 --mqhost myhost3 --mqport 6771 --mquser admin --mqpassword admin broker3 |
管理コンソールを使用してホストを作成するには、次のようにします。
マスター MQ ブローカとほかの MQ ブローカを起動します。
JMS ホストマシン上で起動する 3 つの外部ブローカに加えて、任意のマシン上で 1 つのマスターブローカを起動します。このマスターブローカは、ブローカクラスタの一部である必要はありません。次に例を示します。
/usr/bin/imqbrokerd -tty -name brokerm -port 6772 -cluster myhost1:6769,myhost2:6770,myhost2:6772,myhost3:6771 -D"imq.cluster.masterbroker=myhost2:6772" |
クラスタ内の Application Server インスタンスを起動します。
クラスタ上に JMS リソースを作成します。
JMS 物理送信先を作成します。
たとえば、次の asadmin を使用します。
asadmin create-jmsdest --desttype queue --target cluster1 MyQueue asadmin create-jmsdest --desttype queue --target cluster1 MyQueue1 |
管理コンソールを使用する場合は、次のようにします。
JMS 接続ファクトリを作成します。
たとえば、次の asadmin を使用します。
asadmin create-jms-resource --target cluster1 --restype javax.jms.QueueConnectionFactory jms/MyQcf asadmin create-jms-resource --target cluster1 --restype javax.jms.QueueConnectionFactory jms/MyQcf1 |
管理コンソールを使用する場合は、次のようにします。
JMS 送信先リソースを作成します。
たとえば、次の asadmin を使用します。
asadmin create-jms-resource --target cluster1 --restype javax.jms.Queue --property imqDestinationName=MyQueue jms/MyQueue asadmin create-jms-resource --target cluster1 --restype javax.jms.Queue --property imqDestinationName=MyQueue1 jms/MyQueue1 |
管理コンソールを使用する場合は、次のようにします。
– retrieve オプションを指定して、アプリケーションをアプリケーションクライアント用に配備します。次に例を示します。
asadmin deploy --target cluster1 --retrieve /opt/work/MQapp/mdb-simple3.ear |
アプリケーションにアクセスして、期待どおりの動作をするかテストします。
Application Server をデフォルトの JMS 設定に戻す場合は、作成した JMS ホストを削除して、デフォルトを作成し直します。次に例を示します。
asadmin delete-jms-host --target cluster1 broker1 asadmin delete-jms-host --target cluster1 broker2 asadmin delete-jms-host --target cluster1 broker3 asadmin create-jms-host --target cluster1 --mqhost myhost1 --mqport 7676 --mquser admin --mqpassword admin default_JMS_host |
管理コンソールを使用して、これに相当する操作を実行することもできます。
問題が起きた場合は、次の点を考慮してください。
Application Server ログファイルを表示します。このファイルの場所は、as-install-dir/nodeagents/node-agent-name/instance-name/logs/server.log です。MQ ブローカがメッセージに応答しないとログファイルに記録されている場合は、ブローカを停止してから再起動します。
ブローカログを表示します。このログの場所は、as-install-dir/nodeagents/node-agent-name/instance-name/imq/imq-instance-name/log/log.txt です。
リモートの JMS タイプについては、必ず、MQ ブローカを最初に起動してから Application Server インスタンスを起動するようにしてください。
すべての MQ ブローカが停止した場合、Java Message Service のデフォルト値では、Application Server の停止または起動までに 30 分かかります。Java Message Service の値を調整して、このタイムアウトを許容できる値にしてください。次に例を示します。
asadmin set --user admin --password administrator cluster1.jms-service.reconnect-interval-in-seconds=5