第 4 章ブローカの設定

ブローカインスタンスが起動すると、その設定は一連の設定ファイルおよび imqbrokerd コマンドに渡されるオプションにより制御されます。この章では、設定ファイルとコマンド行オプションが対話し、ブローカインスタンスを設定する方法と、各ブローカコンポーネントの機能について説明します。また設定プロパティを一覧表示して、設定方法を説明します。

設定可能なブローカコンポーネントの概要

プロデューシングクライアントから送信先へ、さらに送信先から 1 つ以上のコンシューミングクライアントへ配信される Message Queue メッセージングシステムのメッセージ配信は、ブローカまたは、並行して動作するブローカインスタンスのクラスタによって行われます。

メッセージ配信を実行するには、ブローカはクライアントとの通信チャネルの設定、認証と承認、適切なメッセージルーティング、信頼性の高い配信の保証、およびシステムパフォーマンスを監視するためのデータの提供を行う必要があります。

その機能を実行するために、ブローカはさまざまな内部コンポーネントを使用します。各コンポーネントには、配信プロセスにおける特定のロールが割り当てられています。これらのブローカコンポーネントについて、図 4-1 に図示しています。

メッセージルーターコンポーネントが主要なメッセージルーティングと配信サービスを実行し、それ以外のコンポーネントは重要なサポートサービスを提供しています。表 4-1 で各コンポーネントを簡単に説明しています。

表 4-1 主要なブローカサービスコンポーネントと機能
コンポーネント	説明/機能	プロパティの説明
コネクションサービス	ブローカとクライアント間の物理的な接続を管理し、送受信メッセージの転送を行います。	「コネクションサービスのプロパティ」
メッセージルーター	メッセージのルーティングおよび配信を管理します。JMS メッセージと、JMS メッセージの配信をサポートするために Message Queue メッセージングシステムが使用するコントロールメッセージを含みます。	「メッセージルーターのプロパティ」
持続マネージャ	データの持続ストレージへの書き込みと、持続ストレージからのデータの取得を管理します。	「持続マネージャのプロパティ」
セキュリティマネージャ	ブローカへのコネクションを要求するユーザーに認証サービスを提供し、認証されたユーザーに承認サービス (アクセス制御) を提供します。	「セキュリティマネージャのプロパティ」
監視サービス	さまざまな出力チャネルに書き込み可能なメトリックスと診断情報を生成する。管理者はこれらをブローカの監視および管理に使用できます。	「監視とロギングのプロパティ」

負荷状態やアプリケーションの複雑さなどに応じて、これらのコンポーネントを設定してブローカのパフォーマンスを最適化することができます。次の節では、各コンポーネントが実行する機能と、コンポーネントの動作を変化させるために設定できるプロパティを説明します。

コネクションサービス

Message Queue ブローカは、Message Queue アプリケーションクライアントと Message Queue 管理クライアントの両方の通信をサポートしています。各コネクションサービスは、次のように、サービスタイプとプロトコルタイプで指定されます。

service type は、JMS メッセージ配信 (NORMAL) サービス、または Message Queue 管理 (ADMIN) サービスのどちらを提供するのかを指定します。

protocol type は、サービスをサポートする基礎となるトランスポートプロトコルレイヤーを指定します。

表 4-2 に、Message Queue ブローカから利用できるコネクションサービスを一覧にします。

表 4-2 ブローカがサポートするコネクションサービス
サービス名	サービスタイプ	プロトコルタイプ
jms	NORMAL	tcp
ssljms (Enterprise Edition)	NORMAL	tls (SSL ベースセキュリティ)
httpjms (Enterprise Edition)	NORMAL	http
httpsjms (Enterprise Edition)	NORMAL	https (SSL ベースセキュリティ)
admin	ADMIN	tcp
ssladmin	ADMIN	tls (SSL ベースセキュリティ)

ブローカを設定して、これらのコネクションサービスの一部、またはすべてを実行することができます。各コネクションサービスは、ブローカのホスト名とポート番号で指定した特定のポートで使用できます。jms サービスと admin サービスは、デフォルトで有効に設定されています。

Message Queue はコネクションサービスを動的にポート番号にマップします。あるいはユーザーがポートを明示的に割り当てられます。図 4-2 に示すように、各サービスはスレッドプールマネージャを保持し、共通のポートマッパーサービスにサービス自体を登録します。

次の節では、コネクションサービスとポートマッパー、およびスレッドプールマネージャとの関連性を説明します。

ポートマッパー

Message Queue には、ポートをコネクションサービスにマップするポートマッパーが用意されています。ポートマッパーは、標準のポート番号 7676 に常駐します。クライアントがブローカとの接続を設定すると、まずポートマッパーに接続し、指定されたコネクションサービスのポート番号を要求します。

jms、ssljms、admin、および ssladmin コネクションサービスのポート番号は、動的にも静的にもなります。デフォルトでは、コネクションサービスは起動時に動的にポートを設定します。また、サービスに静的なポートを指定できますが、静的なポート番号は一般には推奨されません。通常、静的なポート番号は、ファイアウォールを通過するコネクションなど、特別な状況に対してのみ使用されます。

スレッドプールマネージャ

各コネクションサービスは、複数のコネクションをサポートするマルチスレッドです。これらのコネクションに必要なスレッドは、スレッドプールマネージャのコンポーネントが管理するスレッドプールに保存されます。

スレッドプールマネージャを設定して、スレッドプールに保持されるスレッドの最小数と最大数を指定することができます。コネクションでスレッドが必要になると、スレッドプールにスレッドが追加されます。スレッドの最小数より少なくなると、システムは最小数のしきい値になるまで、スレッドをシャットダウンして、スレッドを解放します。これによってメモリーのリソースが節約されます。新しいスレッドを頻繁に作成する必要がないように、最小数に十分な数を指定します。コネクションの負荷が重い場合、スレッドの数をスレッドプールの最大数まで増やすことができます。それでも足らない場合、スレッドが利用できるようになるまで、コネクションは待機します。

スレッドプール内のスレッドは、1 つのコネクションだけに割り当てる (専用モデル) か、必要に応じて、複数のコネクションに割り当てる (共有モデル) ことができます。

専用モデルブローカへのコネクションごとに、コネクションの受信メッセージの処理用と、コネクションの送信メッセージの処理用の 2 つの専用スレッドが必要です。このため、コネクションの数は、スレッドプール内の最大スレッド数の半分に制限されますが、高いパフォーマンスを得られます。

共有モデル (Enterprise Edition) コネクションは、メッセージが送信されるか受信されると必ず、共有スレッドによって処理されます。このモデルでは、コネクションごとの専用スレッドは必要ないため、コネクションサービス、さらにブローカがサポートできるコネクション数が多くなります。ただし、スレッドの共有にはある程度のパフォーマンスオーバーヘッドが伴います。スレッドプールマネージャは、一連のディストリビュータスレッドを使用してコネクションのアクティビティを監視し、必要に応じてスレッドにコネクションを割り当てます。このアクティビティに伴うパフォーマンスオーバーヘッドは、各ディストリビュータスレッドが監視するコネクション数を制限することで最小限に抑えることができます。

セキュリティ

各コネクションサービスは、特定の認証および承認 (アクセス制御) 機能をサポートします (「セキュリティマネージャ」を参照)。

コネクションサービスのプロパティ

これはコネクションサービスに関連した設定可能なプロパティです。

imq.service.activelist。ブローカの起動時に起動するコネクションサービスのリスト。

imq.hostname。1 台のコンピュータに、複数のネットワークインタフェースカードがある場合など、複数のホストを使用できる場合には、すべてのコネクションサービスがバインドするホストを指定します。

imq.portmapper.port。ブローカのプライマリポートを指定します。ポートマッパーが常駐するポートです。

imq.portmapper.hostname。複数のホストが使用できる場合、ポートマッパーがバインドするホストを指定します。

imq.portmapper.backlog。ポートマッパーが、要求を拒否せずに、同時に処理可能な要求の最大数を指定します。オペレーティングシステムのバックログに格納可能な、ポートマッパーによる処理を待機中の要求の数を、プロパティで設定します。

imq.service_name.protocol_type.port。jms、ssljms、admin、および ssladmin のサービスの場合のみ、指定したコネクションサービスのポート番号を指定します。

imq.service_name.protocol_type.hostname。jms、ssljms、admin、および ssladmin のサービスの場合のみ、複数のホストが使用できる場合、指定したコネクションサービスがバインドするホストを指定します。

imq.service_name.min_threads。指定したコネクションサービスが使用するスレッドプールに初めに保持されるスレッドの数を指定します。

imq.service_name. max_threads。指定したコネクションサービスが使用するスレッドプールに保持されるスレッドの最大数を指定します。新しいスレッドは、それ以上追加されなくなります。

imq.service_name.threadpool_model。指定したコネクションサービスに対して、スレッドをコネクション専用にするのか、あるいは必要に応じてコネクションで共有するのかどちらかを指定します。

imq.shared.connectionMonitor_limit。共有スレッドプールモデルの場合のみ、ディストリビュータスレッドで監視できるコネクションの最大数を指定します。

メッセージルーター

サポートされているコネクションサービスを使用して、クライアントとブローカ間でコネクションが確立されると、メッセージのルーティングおよび配信が処理できます。

基本的な配信メカニズム

通常、ブローカで処理されるメッセージは、2 つのカテゴリに分類されます。

プロデューサクライアントからコンシューマクライアントに送信される JMS ペイロードメッセージ

クライアント間で送受信され、JMS メッセージの配信をサポートするコントロールメッセージ

受信メッセージが JMS メッセージの場合、送信先のタイプ (キュー、またはトピック) に基づいて、ブローカはメッセージをコンシューマクライアントにルートします。

送信先がトピックの場合、JMS メッセージは、すぐにトピックのすべてのアクティブサブスクライバにルートされます。永続サブスクライバが停止している場合、メッセージルーターは、サブスクライバがアクティブになるまでメッセージを保持し、アクティブになったらメッセージを配信します。

送信先がキューの場合、JMS メッセージは、対応するキューに配置され、メッセージがキューの先頭に来たときに、適切なコンシューマに配信されます。メッセージがキューの先頭に来る順番は、メッセージの到着順序と優先度によって変わります。

メッセージルーターは予定のコンシューマすべてにメッセージを配信した後、メモリーからメッセージをクリアします。メッセージが残っている場合、メッセージルーターはブローカの持続データストアからメッセージを削除します。

信頼性の高い配信: 通知とトランザクション

信頼性の高い配信の要件を追加すると、前述した配信メカニズムはさらに複雑になります。信頼性の高い配信には、2 つの側面が関連します。

ブローカ間のメッセージ配信の成功を保証する

ブローカがメッセージの実際の配信前に、メッセージまたは配信情報を損失しないことを保証する

ブローカとのメッセージの配信を正常に行うために、Message Queue は多数の応答コントロールメッセージを使用します。

たとえば、プロデューサが送信先に JMS メッセージ (ペイロードメッセージ) を送信する場合、ブローカは JMS メッセージを受信したという応答を返します (デフォルトでは、プロデューサが JMS メッセージを持続的として指定している場合に限り、Message Queue はこれを実行する)。プロデューシングクライアントは、送信先への配信を保証するために、ブローカの応答を使用します。

同様に、ブローカが JMS メッセージをコンシューマに配信した場合、コンシューミングクライアントは、メッセージを受信および処理したことを示す通知を送り返します。クライアントは、セッションオブジェクトの作成時に、これらの通知を自動的に、またはどのくらいの頻度で送信するのかを指定しますが、メッセージルーターは、メッセージを配信した各メッセージコンシューマ (トピックの複数のサブスクライバなど) から通知を受信するまで、メモリーから JMS メッセージを削除しません。

トピックのサブスクリプションが永続的な場合、メッセージルーターは、各 JMS メッセージをその送信先で保持し、各永続サブスクライバがアクティブなコンシューマになると、そのメッセージを配信します。

メッセージルーターは、クライアントの通知を受信するたびにそれを記録し、すべての通知を受信すると、初めて JMS メッセージを削除します (ただし、この時点で JMS メッセージの有効期限が切れている場合は除く)。

さらに、メッセージルーターは、ブローカの応答をクライアントに送り返して、クライアントの通知を受信したことを確認します。コンシューミングクライアントは、ブローカの応答を使用して、ブローカが JMS メッセージを何度も配信しないようにします。ブローカがクライアントの通知を受信し損なうと、JMS メッセージが繰り返し配信される可能性があります。

ブローカがクライアントの通知を受信しないで、JMS メッセージを再び配信する場合、メッセージに再配信フラグが付けられます。一般にブローカは、次の状況で JMS メッセージを再配信します。

ブローカがクライアントの通知を受信する前に、クライアントコネクションが終了し、その後、新しいコネクションが確立される。

クライアントアプリケーションがセッションを復元する。

クライアントアプリケーションがロールバックされたトランザクションを復元する。

たとえば、メッセージが通知される前に、キューのメッセージコンシューマがオフラインになって、別のコンシューマがキューに登録された場合、ブローカは通知されていないメッセージを新しいコンシューマに再配信します。

前述のクライアントの通知とブローカの応答は、トランザクションに分類される JMS メッセージの配信にも適用されます。この場合、各プロセスは個々の JMS メッセージの送信または受信レベルだけでなく、トランザクションレベルでも動作します。トランザクションがコミットされると、ブローカの応答が自動的に送信されます。

ブローカはトランザクションを追跡し、トランザクションがコミットされるか、あるいは障害が発生した場合にロールバックされるようにします。このトランザクション管理は、大規模な分散トランザクションの一部であるローカルトランザクションもサポートします。ブローカは、これらのトランザクションがコミットされるまで、トランザクションの状態を追跡します。デフォルトでは、ブローカは起動時に、コミットされていないすべてのトランザクションを調べて、PREPARED 状態以外のトランザクションをすべてロールバックします。imq.transaction.autorollback プロパティを設定する場合、ブローカは PREPARED 状態にあるトランザクションもロールバックします。

信頼性の高い配信: 持続

信頼性の高い配信のもう 1 つの局面は、メッセージが実際に配信されるまで、ブローカがメッセージ、または配信情報を保持することです。通常、メッセージは配信されたり、有効期限が切れたりするまで、メモリー内に保持されます。ただし、ブローカに障害が発生すると、これらのメッセージは損なわれます。

プロデューサクライアントが、メッセージの持続性を指定している場合、メッセージルーターはこのメッセージを持続マネージャに渡します。持続マネージャは、データベースまたはファイルシステムにメッセージを格納し (「持続マネージャ」を参照)、ブローカに障害が発生したときに、メッセージを復元できるようにします。

メモリーリソースとメッセージフローの管理

ブローカのパフォーマンスと安定性は、使用できるシステムリソースとメモリーなどのリソースの使用効率によって異なります。特に、メッセージルーターでは、メッセージの生成量が消費量をかなり上回る場合には、過負荷となりメモリーリソースを使い果たしてしまうことがあります。この問題の発生を避けるために、メッセージルーターは、リソースが不十分なときでもシステムの動作を維持できるように 3 レベルのメモリー保護を使用しています。

個々の送信先のメッセージ制限メッセージ数およびメッセージで消費される合計メモリーに制限を指定する、物理的送信先プロパティを設定できます (第 15 章「物理的送信先のプロパティのリファレンス」を参照)。また、制限に達したときのメッセージルーターの動作も指定できます。4 種類の制限の動作は次のとおりです。

メッセージプロデューサを遅くする (FLOW_CONTROL)

メモリー内のもっとも古いメッセージを廃棄する (REMOVE_OLDEST)

メッセージの有効期限に従い、メモリー内のもっとも優先度の低いメッセージを廃棄する (REMOVE_LOW_PRIORITY)

もっとも新しいメッセージを拒否する (REJECT_NEWEST)

システム全体のメッセージ制限システム全体のメッセージ制限は、二次的な保護を提供します。システム全体の制限を指定すると、システム上のすべての送信先に対して一括して適用され、メッセージの総数とすべてのメッセージによって使用される総メモリー量が制限されます (表 14-3 を参照)。どちらかのシステム全体のメッセージ制限に達した場合、メッセージルーターは新しいメッセージを拒否します。

システムメモリーのしきい値システムメモリーのしきい値は、三次的な保護を提供します。ブローカがさらに深刻な状況に陥ったときに、メモリーの過負荷を避けるためのアクションを実行できるように、使用可能なシステムメモリーのしきい値を指定できます。実行するアクションは、メモリーリソースの状態に応じて、次のように異なります。

green (使用可能なメモリーが十分にある)

yellow (ブローカのメモリーが減っている)

orange (ブローカのメモリーが不十分である)

red (ブローカのメモリーが不足している)

ブローカのメモリーの状態が green から yellow、orange、red へと進むにつれ、ブローカは次のタイプの本格的なアクションを段階的に実行します。

アクティブなメモリーのメッセージを持続ストレージにスワップする (「持続マネージャ」を参照)。

持続的でないメッセージのプロデューサの処理速度を低下させ、最終的にブローカへのメッセージフローを止める。持続メッセージのフローは、メッセージごとにブローカによって通知された要件によって自動的に制限されます。

これらのアクションはどちらもパフォーマンスを低下させます。

システムメモリーのしきい値に達する場合は、送信先メッセージの制限とシステム全体のメッセージ制限が低すぎます。場合によっては、潜在するメモリーの過負荷をしきい値がタイミングよく指摘できないことがあります。したがって、この機能に依存してメモリーリソースを制御するのではなく、メモリーリソースが最適化されるように個々の送信先とシステム全体を設定する必要があります。

メッセージルーターのプロパティ

メモリーリソースの管理には、システム全体の制限とシステムメモリーのしきい値があります。

imq.destination.DMQ.truncateBody。デッドメッセージキューに、メッセージのヘッダーとプロパティデータのみが残るように指定します。メッセージ本体の内容は破棄されます。

imq.message.expiration.interval。有効期限が切れたメッセージを再利用させる頻度を秒単位で指定します。

imq.system.max_count。ブローカが保持するメッセージの最大数を指定します。

imq.system.max_size。ブローカが保持するメッセージの最大合計サイズを指定します。

imq.message.max_size。メッセージ本体の最大サイズを指定します。

imq.resource_state.threshold。指定したメモリーリソースの状態で、そのメモリーリソースがトリガーされるメモリーの利用率を指定します。

imq.resource_state.count。メモリーリソースの各状態がトリガーされたときに、一度に入力可能なメッセージの最大数を指定します。

imq.transaction.autorollback。PREPARED 状態の分散トランザクションをブローカの起動時に自動的にロールバックするかどうかを指定します。

持続マネージャ

障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。この場合、ブローカは、すべての持続メッセージを重要な転送情報および配信情報とともにデータストアに保存する必要があります。持続マネージャのコンポーネントは、この情報の書き込みおよび検索を管理します。

障害が発生したブローカを復元する場合、配信されていないメッセージを復元するだけでは不十分です。ブローカは、次のタスクも実行する必要があります。

送信先の再作成

各トピックの永続サブスクリプションのリストの復元

各メッセージの通知リストの復元

コミットされたすべてのトランザクションの状態の復元

持続マネージャは、このすべての状態情報の格納および検索を管理します。

ブローカが再起動すると、送信先と永続サブスクリプションの再作成、持続メッセージの復元、すべてのトランザクションの状態の復元、および配信されていないメッセージのルーティングテーブルの再作成が行われます。この後に、メッセージの配信を再開します。

Message Queue は、組み込み持続モジュールとプラグイン持続モジュールの両方をサポートしています (図 4-3 を参照)。組み込み持続は、ファイルベースのデータストアです。プラグイン持続は、JDBC^TM (Java Database Connectivity) インタフェースを使用し、JDBC データストアを必要とします。通常、組み込み持続の方が、プラグイン持続より処理速度が速くなりますが、JDBC 互換のデータベースシステムを使用する冗長性および管理機能を好むユーザーもいます。

組み込み持続

デフォルトの Message Queue 持続ストレージソリューションは、ファイルベースのデータストアです。この方法では、メッセージ、送信先、永続サブスクリプション、トランザクションなどの持続データを保存するために、個別のファイルを使用します。

ファイルベースのデータストアは、常駐先の送信先に応じてメッセージがディレクトリに格納されるように構成されています。大半のメッセージは、可変長レコードから構成されるシングルファイルに格納されます。

メッセージが追加および削除されたときの断片化を減らすために、可変長レコードファイルを圧縮できます (「物理的送信先の圧縮」を参照)。さらに、設定可能なしきい値 (imq.persist.file.message.max_record_size) より大きいメッセージは、可変長レコードファイルではなく、メッセージに該当するファイルへ組み込み持続マネージャが格納します。これらの個々のファイルでは、ファイルが再利用できるようにファイルプールが維持されます。メッセージファイルが不要になっても削除されません。その代わり、メッセージファイルは送信先ディレクトリの空きファイルのプールに追加され、新しいメッセージの保存に使用されます。

送信先ファイルプールの最大ファイル数を設定できます (imq.persist.file.destination.message.filepool.limit)。また、単に再利用のタグを設定するのではなく、ゼロまで切り捨てて削除されるファイルプール内の空きファイルの率も指定できます (imq.persist.file.message.filepool.cleanratio)。消去されるファイルの率が増加すると、ディスクスペースは減り、ファイルプールの維持に必要なオーバーヘッドが増加します。

シャットダウン時に、タグの付いたファイルを削除するかどうか (imq.persist.file.message.cleanup) を指定することもできます。ファイルが削除されると、ファイルが使用するディスクスペースが小さくなりますが、ブローカはシャットダウンに時間がかかるようになります。

そのほかの持続データはすべて (送信先、永続サブスクリプション、トランザクション) は、それぞれ個別のファイルに格納されます。つまり、送信先はすべて 1 つのファイルに、永続サブスクリプションはすべて別の 1 つのファイルに、といった具合になります。

信頼性を最大にするため、imq.persist.file.sync.enabled 属性を使用して、持続操作によりメモリー内の状態と物理的なストレージ装置とを同期するように指定できます。この同期化は、システム破壊によるデータの損失をなくす上で役立ちますが、パフォーマンスが犠牲になります。Sun Cluster 環境で Message Queue を実行している場合、クラスタのすべてのノードに対してこの属性を true に設定する必要があります。

データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが含まれることがあるため、instances/instanceName/fs350/ ディレクトリは承認されていないアクセスから保護するようにしてください。保護する方法については、「持続データの保護」を参照してください。

プラグイン持続

JDBC ドライバを介してアクセスが可能な任意のデータストアにアクセスするように、ブローカを設定することができます。この作業には、さまざまな JDBC 関連のブローカ設定プロパティの設定、適切なスキーマでデータストアを作成するデータベースマネージャユーティリティ (imqdbmgr) の使用が含まれます。手順および関連する設定プロパティについては、「持続ストアの設定」で説明します。

持続マネージャのプロパティ

imq.persist.store。組み込みのファイルベース (file) の持続、またはプラグインの JDBC 互換 (jdbc) の持続のどちらをブローカが使用するのかを指定します。

imq.persist.file.sync.enabled。持続操作でメモリー内の状態を物理的なストレージと同期させるかどうかを指定します。

imq.persist.file.message.max_record_size。メッセージストレージファイルに追加されるメッセージの最大サイズを指定します。

imq.persist.file.destination.message.filepool.limit。送信先ファイルプール内の再利用できる空きファイルの最大数を指定します。

imq.persist.file.message. filepool.cleanratio。クリーン状態 (サイズを 0 にする) で保持される送信先のファイルプールの空きファイルの割合を指定します。

imq.persist.file.message.cleanup。ブローカがシャットダウンされたとき、送信先のファイルプールの空きファイルを消去するかどうかを指定します。

次のプロパティは、JDBC ベースの持続に関連したものです。

imq.persist.jdbc.brokerid。複数のブローカインスタンスで使用される、データベース内のテーブル名に追加するブローカインスタンス識別子を指定します。

imq.persist.jdbc.driver。データベースに接続する JDBC ドライバの Java クラス名を指定します。

imq.persist.jdbc.opendburl。既存データベースへのコネクションを開くためのデータベース URL を指定します。

imq.persist.jdbc.createdburl。データベースを作成するコネクションを開くためのデータベース URL を指定します。

imq.persist.jdbc.closedburl。ブローカをシャットダウンする場合に、現在のデータベースコネクションをシャットダウンするためのデータベース URL を指定します。

imq.persist.jdbc.user。必要に応じて、データベースコネクションを開くときに使用するユーザー名を指定します。

imq.persist.jdbc.needpassword。データベースでブローカのアクセスにパスワードを必要とするかどうかを指定します。

imq.persist.jdbc.password。データベースコネクションを開くときに使用するパスワードを、必要に応じて指定します。

imq.persist.jdbc.table.IMQSV35。バージョンテーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQCCREC35。設定変更レコードテーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQDEST35。送信先テーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQINT35。配信対象テーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQMSG35。メッセージテーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQPROPS35。プロパティテーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQILIST35。配信対象の状態テーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQTXN35。トランザクションテーブルを作成するための SQL コマンドです。

imq.persist.jdbc.table.IMQTACK35。トランザクション通知テーブルを作成するための SQL コマンドです。

セキュリティマネージャ

Message Queue では、認証および承認 (アクセス制御) 機能が用意されており、暗号化機能もサポートされています。

認証機能と承認機能はユーザーリポジトリによって異なります (図 4-4 を参照)。ユーザーリポジトリには、ファイル、ディレクトリ、または名前、パスワード、グループメンバーシップなどのメッセージングシステムのユーザーに関する情報を含むデータベースがあります。ユーザー名とパスワードはブローカへのコネクションが要求されたときに、ユーザーを認証するために使用されます。ユーザー名とグループのメンバーシップは、送信先のプロデューシングメッセージ、またはコンシューミングメッセージなどの操作を承認するために、アクセス制御ファイルと一緒に使用されます。

認証

Message Queue のセキュリティは、パスワードベースの認証がサポートしています。クライアントがブローカへのコネクションを要求する場合、ユーザー名とパスワードを提示する必要があります。

セキュリティマネージャは、クライアントから提示されたユーザー名とパスワードをユーザーリポジトリ内に格納されているものと比較します。クライアントからブローカにパスワードが送信される場合、パスワードは、Base-64 か、メッセージダイジェスト (MD) のどちらかを使用して暗号化されます。セキュリティ保護された送信については、「暗号化」を参照してください。各コネクションサービスで使用する暗号化のタイプを 1 つずつ設定するか、あるいはブローカ単位で暗号化を設定することができます。

承認

クライアントアプリケーションのユーザーが認証されると、ユーザーはさまざまな Message Queue 関連のアクティビティを実行することを承認されます。セキュリティマネージャは、ユーザーベースとグループベースの両方のアクセス制御をサポートしています。ユーザー名、またはユーザーリポジトリでユーザーに割り当てられているグループに応じて、ユーザーは特定の Message Queue 操作を実行するためのアクセス権を付与されます。これらのアクセス制御は、アクセス制御プロパティファイルで指定します (図 4-4 を参照)。

ユーザーがある操作を実行しようとすると、セキュリティマネージャが、ユーザーリポジトリ内のユーザー名とグループのメンバーシップを、アクセス制御プロパティファイル内のその操作へのアクセスに指定されたユーザー名とグループのメンバーシップと照らし合わせます。アクセス制御プロパティファイルでは、次の操作に対するアクセス権を指定します。

ブローカとのコネクションの確立

送信先へのアクセス: 特定の送信先、またはすべての送信先に対してのコンシューマ、プロデューサ、またはキューブラウザの作成

送信先の自動作成

図 4-4 セキュリティマネージャのサポート
図は、セキュリティマネージャがユーザーリポジトリとアクセス制御プロパティファイルの両方を使用することを示します。

デフォルトのアクセス制御プロパティファイルは、admin という 1 つのグループだけを明示的に参照します (「グループ」を参照)。admin グループのユーザーには、admin サービスコネクションのアクセス権が付与されます。admin サービスは、送信先の作成、ブローカの監視と制御などの管理機能を実行できます。その他のグループに定義されたユーザーは、デフォルトでは admin サービスコネクションにアクセスできません。

Message Queue の管理者は、グループを定義し、ユーザーリポジトリ内のそれらのグループとユーザーを関連付けることができます。ただし、グループは単層型ファイルのユーザーリポジトリで完全にはサポートされません。

アクセス制御プロパティファイルを編集してユーザー別およびグループ別に目的 (メッセージの生成と消費、またはキューの送信先のメッセージの参照) に応じて、送信先へのアクセスを指定できます。特定のユーザー、またはグループだけがアクセスできる個別の送信先、またはすべての送信先を作成できます。ブローカに送信先の自動作成が設定される場合、アクセス制御プロパティファイルを編集して、ブローカが送信先を自動作成するユーザーとグループを制御することができます。

暗号化

クライアントとブローカ間で送信されるメッセージを暗号化するには、SSL (Secure Socket Layer) 標準に基づいたコネクションサービスを使用する必要があります。SSL は、SSL 対応のブローカとクライアント間で暗号化されたコネクションを確立して、コネクションレベルのセキュリティを提供します。

Message Queue の SSL ベースのコネクションサービスを使用するには、キーツールユーティリティ (imqkeytool) を使用して、非公開キーと公開キーのペアを生成します。このユーティリティは、自己署名型証明書に公開キーを組み込んで、それを Message Queue のキーストアに配置します。Message Queue のキーストア自体は、パスワードによって保護されているため、起動時にキーストアのパスワードを入力して、ロックを解除する必要があります。「SSL ベースのサービスの操作」を参照してください。

キーストアのロックが解除されると、ブローカは、コネクションを要求しているクライアントに証明書を渡すことができます。証明書を受け取ると、クライアントはその証明書を使用して暗号化されたブローカへのコネクションを設定します。

セキュリティマネージャのプロパティ

認証、承認、暗号化、およびその他のセキュリティ保護された通信に関する設定可能なプロパティを以下に示します。

imq.authentication.type。パスワードを Base-64 コーディング (basic)、または MD5 ダイジェスト (digest) のどちらで送信するのかを指定します。

imq.service_name. authentication.type。パスワードを Base-64 コーディング (basic)、または MD5 ダイジェスト (digest) のどちらで送信するのかを指定します。

imq.authentication.basic.user_repository。Base-64 コーディングの場合、認証に使用するユーザーリポジトリの種類 (ファイルベースか LDAP か) を指定します。

imq.authentication.client.response.timeout。ブローカからの認証要求に対するクライアントの応答をシステムが待機する時間を秒単位で指定します。

imq.accesscontrol.enabled。アクセス制御プロパティファイルに指定されているように、認証されたユーザーが、コネクションサービスを使用するためのアクセス権、あるいは特定の送信先に対して特定の Message Queue 操作を実行するためのアクセス権を保持していることをシステムでチェックするかどうかを指定します。

imq.service_name.accesscontrol.enabled。指定したコネクションサービスに対して、アクセス制御を設定し (true/false)、ブローカ全体の設定をオーバーライドします。

imq.accesscontrol.file.filename。ブローカインスタンスでサポートされるすべてのコネクションサービスに対して、アクセス制御プロパティファイルの名前を指定します。

imq.service_name.accesscontrol.file.filename。ブローカインスタンスの指定したコネクションサービスに対して、アクセス制御プロパティファイルの名前を指定します。

imq.passfile.enabled。セキュリティ保護される通信用の (SSL、LDAP、JDBC^TM の) ユーザーパスワードをファイルで指定するどうかを指定します。

imq.passfile.dirpath。パスファイルを含むディレクトリのパスを指定します。

imq.passfile.name。パスファイル名を指定します。

imq.keystore.property_name。SSL ベースのサービスの場合は、SSL キーストアに関係するセキュリティプロパティを指定します。表 14-9 を参照してください。

監視サービス

ブローカには、ブローカの動作を監視および診断するためのさまざまなコンポーネントが用意されています。たとえば、次のようなコンポーネントが含まれています。

データを生成するコンポーネント (イベントを記録するブローカコードとメトリックスジェネレータ)

多数の出力チャネルを使用して情報を書き込むロガーコンポーネント (「ロガー」を参照)

メトリックス情報を含む JMS メッセージを、JMS 監視クライアントによって消費させるためにトピック送信先へ送るメッセージプロデューサ。

メトリックスジェネレータ

メトリックスジェネレータは、ブローカとの間で入出力されるメッセージフロー、ブローカメモリー内のメッセージ数とそれらが消費するメモリー量、開かれているコネクションの数、使用中のスレッドの数など、ブローカの動作に関する情報を提供します。

メトリックスデータの生成をオン、またはオフにすることも、メトリックスレポートを生成する頻度を指定することもできます。

ロガー

Message Queue のロガーは、ブローカコードとメトリックスジェネレータによって生成された情報を取得し、標準出力 (コンソール)、ログファイル、Solaris^TM オペレーティングシステム、syslog デーモンプロセスなどの多数の出力チャネルに書き込みます。

ロガーが収集する情報のタイプと、各出力チャネルに書き込む情報のタイプを指定できます。

たとえば、ロガーレベルを指定するとロガーが収集する情報の種類、エラー (ERROR)、エラーと警告 (WARNING)、またはエラー、警告、および情報 (INFO) を指定できます。

各出力チャネルに対して、そのチャネルに書き込まれるロガーのカテゴリを設定できます。たとえば、ロガーのレベルが INFO の場合、エラーと警告だけをコンソールに出力し、情報 (メトリックスデータ) だけをログファイルに書き込むように指定することができます。

ログファイルを使用する場合、ログファイルを閉じて新しいファイルに出力が新しいファイルにロールオーバーされる時点を指定できます。新しいロールオーバーログファイルが作成されると、もっとも新しい 9 個のログファイルのアーカイブが保持されます。

ロガーの設定方法については、「ブローカロギングの設定と使用」を参照してください。Solaris syslog の設定および使用方法については、syslog(1M)、syslog.conf(4)、および syslog(3C) のマニュアルページを参照してください。

メトリックスメッセージプロデューサ (Enterprise Edition)

メッセージプロデューサのコンポーネントは、メトリックスジェネレータのコンポーネントから定期的に情報を受け取ります。このコンポーネントはメッセージに情報を書き込み、その後メトリックストピック送信先に送信します。メトリックスメッセージを送信する送信先は、メッセージに含まれる情報の種類により異なります。

5 つのメトリックストピック送信先があります。それらの名前と、各送信先へ配信されるメトリックスメッセージのタイプを表 4-3 に示します。

表 4-3 メトリックスのトピック送信先
トピック送信先名	メトリックスメッセージのタイプ
mq.metrics.broker	ブローカのメトリックス
mq.metrics.jvm	Java 仮想マシンのメトリックス
mq.metrics.destination_list	送信先とそれらのタイプのリスト
mq.metrics.destination.queue. monitoredDestinationName	指定した名前のキューの送信先メトリックス
mq.metrics.destination.topic. monitoredDestinationName	指定した名前のトピックの送信先メトリックス

これらのメトリックストピック送信先にサブスクライブした Message Queue クライアントは、送信先内でメッセージを消費し、メトリックス情報を処理します。たとえば、クライアントは、mq.metrics.broker 送信先にサブスクライブし、ブローカ内のメッセージの合計数といった情報を受け取り処理することができます。

メトリックスメッセージプロデューサは、メトリックスデータに相当する、名前と値のペアを含むメッセージを作成する内部 Message Queue クライアントです。メッセージのタイプは MapMessage です。これらのメッセージは、該当するメトリックストピック送信先へのサブスクライバが複数存在する場合にだけ生成されます。

メトリックスメッセージプロデューサにより生成されるメッセージのタイプは、MapMessage です。メッセージは、メッセージに含まれるメトリックスのタイプに応じて、複数の名前/値のペアから構成されます。各名前と値のペアは、メトリックスの数とその値に相当します。

例として、ブローカメトリックスメッセージは、ブローカとの間で送受信されたメッセージの数、これらのメッセージのサイズ、現在メモリー内にあるメッセージの数とサイズなどに関する値を含んでいます。各タイプのメトリックスメッセージで報告されるメトリックス数の詳細は、『Message Queue Developer's Guide for Java Clients』を参照してください。このマニュアルでは、メトリックスメッセージの消費に関して Message Queue クライアントを書き込む方法を説明しています。

メトリックスメッセージの本体に含まれるメトリックス情報以外に、各メッセージのヘッダーには次の情報を提供するプロパティがあります。

メッセージタイプ

メッセージを送信したブローカのホスト、ポート、アドレス

メトリックスサンプルを採取した時間

これらのプロパティは、異なる種類または異なるブローカからのメトリックメッセージを処理する Message Queue クライアントアプリケーションに有用です。

監視サービスのプロパティ

次に示すのは、ブローカによる情報の生成、ロギング、およびメトリックスメッセージの生成を設定する設定可能なプロパティです。

imq.metrics.enabled。メトリックス情報をロガーへ書き込むかどうかを指定します。

imq.metrics.interval。メトリックスのロギングが有効な場合は、メトリックス情報がロガーへ書き込まれる時間間隔を秒単位で指定します。

imq.log.level。ロガーレベル、つまり、出力チャネルへ書き込み可能な出力のカテゴリを指定します。

imq.log.file.output。ログファイルに書き込むロギング情報のカテゴリを指定します。

imq.log.file.dirpath。ログファイルを含むディレクトリのパスを指定します。

imq.log.file.filename。ログファイル名を指定します。

imq.log.file.rolloverbytes。新しいログファイルに出力がロールオーバーされるログファイルのサイズをバイト単位で指定します。

imq.log.file.rolloversecs。新しいログファイルに出力がロールオーバーされるログファイルの有効期間を秒単位で指定します。

imq.log.console.output。コンソールへ書き込むロギング情報のカテゴリを指定します。

imq.log.console.stream。コンソールの出力を標準出力 (OUT)、または標準エラー出力 (ERR) のどちらに書き込むかを指定します。

imq.log.syslog.facility。(Solaris のみ) Message Queue ブローカが記録する syslog 機能を指定します。

imq.log.syslog.logpid。(Solaris のみ) メッセージとともにブローカのプロセス ID を記録するかどうかを指定します。

imq.log.syslog.logconsole。(Solaris のみ) メッセージを syslog に送信できない場合に、システムコンソールにメッセージを書き込むかどうかを指定します。

imq.log.syslog.identity。(Solaris のみ) syslog に記録される各メッセージの先頭に付加する識別情報文字列を指定します。

imq.log.syslog.output。(Solaris のみ) syslogd(1M) に書き込むロギング情報のカテゴリを指定します。

imq.log.timezone。ログのタイムスタンプのタイムゾーンを指定します。

imq.metrics.topic.enabled。メトリックスメッセージの生成を有効にするかどうかを指定します。

imq.metrics.topic.interval。メトリックスメッセージを生成する間隔を秒で指定します。

imq.metrics.topic.persist。メトリックスメッセージが持続メッセージかどうかを指定します。

imq.metrics.topic.timetolive。メトリックストピック送信先へ送信されるメトリックスメッセージの有効期間を秒単位で指定します。

imq.destination.logDeadMsgs。ブローカがデッドメッセージを破棄するたびに、またはデッドメッセージキューにデッドメッセージを配置するたびに、ログにメッセージを書き込むかどうかを指定します。

これらのプロパティの詳細は、表 14-10 を参照してください。

設定ファイルの概要

このディレクトリには、次のファイルが格納されています。

起動時に読み込まれるデフォルトの設定ファイル。このファイルは、default.properties と呼ばれ、編集はできません。デフォルトの設定を決定したり、変更するプロパティの正確な名前を検索したりする場合、このファイルに目を通すといいでしょう。

Message Queue のインストール時に指定されたプロパティを格納するインストール設定ファイル。このファイルは、install.properties と呼ばれ、インストール後は編集できません。

インスタンス設定ファイル

最初にブローカを実行したときに、インスタンス設定ファイルが作成されます。インスタンス設定ファイルは、ブローカのそのインスタンスに設定プロパティを指定する場合に使用します。

インスタンス設定ファイルは、その設定ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに格納されます。


注	.../instances/instanceName ディレクトリとインスタンス設定ファイルは、対応するブローカインスタンスを作成したユーザーが所有します。ブローカインスタンスは、常に同じユーザーにより再起動されます。

インスタンス設定ファイルは、ブローカインスタンスによって管理されます。このファイルは、管理ツールを使用して設定に変更が加えられた場合に変更されます。インスタンス設定ファイルを手作業で編集して、設定を変更できます (「インスタンス設定ファイルの編集」を参照)。手作業で変更するには、.../instances/instanceName ディレクトリの所有権が必要です。所有権がなければ、root としてログインしてディレクトリの権限を変更する必要があります。

クラスタでブローカインスタンスを接続する場合、クラスタ設定ファイルを使用して、クラスタ設定情報を指定する必要があります。詳細は、「クラスタ設定プロパティ」を参照してください。

プロパティ値のマージ

起動時に、ブローカは異なる設定ファイルのプロパティ値をマージします。インストール時の値、およびインスタンス設定ファイルに設定された値が使用され、デフォルトの設定ファイルで指定された値はオーバーライドされます。

imqbrokerd コマンドオプションを使用すると、生成された値をオーバーライドできます。この方式を図 4-6 で図解します。

プロパティ命名構文

設定ファイルにある Message Queue プロパティの定義では、次の命名構文を使用します。

たとえば、次のエントリは、ブローカが追加メッセージを拒否するまでに、メモリーと持続ストレージに最大 50,000 メッセージを保持するように指定します。

次のエントリは、毎日、つまり 86400 秒ごとに新しいログファイルを作成するように指定します。

インスタンス設定ファイルの編集

初めてブローカインスタンスが実行されると、config.properties ファイルが自動的に作成されます。このインスタンス設定ファイルを編集して、対応するブローカインスタンスの動作やリソースの使用をカスタマイズできます。

ブローカインスタンスが config.properties ファイルを読み込むのは起動時だけです。config.properties ファイルへの変更を確定するには、次の操作のどちらかを行います。

管理ツールを使用する。imqcmd を使用して設定できるプロパティについての詳細は、表 14-1 を参照してください。

ブローカインスタンスをシャットダウンしてから config.properties ファイルを編集し、その後インスタンスを再起動します (Solaris および Linux オペレーティングシステムでは、最初にブローカインスタンスを起動したユーザーだけが config.properties ファイルを編集するためのアクセス権を持つ)。

表 14-1 に、ブローカインスタンス設定プロパティとそのデフォルト値をアルファベット順に一覧表示します。各プロパティの意味と使用に関する詳細は、指定された相互参照の節で確認してください。

コマンド行への設定オプションの入力

ブローカの起動時、または起動後に、コマンド行にブローカ設定オプションを入力できます。

起動時に imqbrokerd コマンドを使用してブローカインスタンスを起動します。コマンドの -D オプションを使用すると、ブローカの設定プロパティとその値を指定できます。imqsvcadmin コマンドを使用して、Windows サービスとしてブローカを起動している場合、-args オプションを使用して起動時設定プロパティを指定します。

また、ブローカインスタンスの実行中に、特定のブローカプロパティを設定できます。実行中のブローカの設定を変更する場合は、imqcmd update bkr コマンドを使用します。

持続ストアの設定

Message Queue のブローカには、一貫した情報の書き込みおよび取得を管理する持続マネージャのコンポーネントが含まれています。デフォルトでは、持続マネージャは、組み込みのファイルベースのデータストアにアクセスするように設定されていますが、持続マネージャを再設定して、JDBC 互換ドライバを介したアクセスが可能な任意のデータストアに接続できます。

Message Queue データストアには、トランザクション、メッセージ、永続サブスクリプション、物理的送信先に関する情報が収められています。また、メッセージの通知に関する状態の詳細も収められています。

この章では、持続ストアを使用するブローカの設定方法を説明します。次のトピックが含まれます。

「ファイルシステムストアの設定」

「JDBC ストアの設定」

「持続データの保護」

ファイルシステムストアの設定

ファイルシステムデータストアは、ブローカインスタンスの作成時に自動的に作成されます。このストアは、ブローカのインスタンスディレクトリ内に置かれます。オペレーティングシステムにより場所が異なります。持続ストアの正確な場所は、付録 A 「オペレーティングシステムごとの Message Queue データの場所」を参照してください。

デフォルトでは、Message Queue はディスクへの書き込み操作を非同期的に実行します。オペレーティングシステムは、このような操作をバッファリングし、パフォーマンスを高めます。ただし、不測のシステム障害が書き込み操作の間に発生した場合、メッセージは損なわれる可能性があります。信頼性を高めるために、Message Queue がディスクへの書き込みを同時に実行するように設定できますが、このオプションによりパフォーマンスが低下することに注意してください。ディスクへの同時書き込みを指定する場合、ブローカプロパティ imq.persist.file.sync. を設定します。このプロパティの詳細は、表 14-6 を参照してください。

ブローカインスタンスを起動すると、imqbrokerd -reset オプションを使用してファイルシステムストアを消去できます。このオプションおよびサブオプションの詳細は、表 13-2 を参照してください。

JDBC ストアの設定

JDBC ベースの持続を使用するブローカを設定するには、ブローカインスタンス設定ファイルで JDBC 関連のプロパティを設定し、適切なデータベーススキーマを作成します。Message Queue のデータベースマネージャユーティリティ (imqdbmgr) は、JDBC ドライバとブローカ設定プロパティを使用してデータベースを作成し、管理します。

この章に示す手順は、例として Java 2 プラットフォーム Enterprise Edition (J2EE) SDK にバンドルされる PointBase DBMS を使用して説明しています。バージョン 1.4 は、java.sun.com からダウンロードして入手できます。例では、クライアント/サーバーバージョンの代わりに、PointBase の組み込みバージョンを使用します。手順の指示は、PointBase の例のパス名とプロパティ名を使用しています。これらは、「例: 」という言葉で識別されます。

また、PointBase の組み込みバージョン、PointBase サーバーバージョン、および Oracle の例は、インスタンス設定ファイル config.properties 内でコメントアウトされた値として提供されています。

JDBC アクセスが可能なデータストアへの接続

JDBC アクセスが可能なデータストアに接続するには、次の手順を実行するだけです。

JDBC アクセスが可能なデータストアに接続する

ブローカの設定ファイルに、JDBC 関連のプロパティを設定します。

「JDBC ベースの持続」に示すプロパティを参照してください。

次のパスに、JDBC ドライバの jar ファイルのコピーまたはシンボリックリンクを配置します。

/usr/share/lib/imq/ext/ (Solaris)

/opt/sun/mq/share/lib/ (Linux)

IMQ_VARHOME¥lib¥ext (Windows)

コピーの例 (Solaris):

% cp j2eeSDK_install_directory/pointbase/lib/pointbase.jar /usr/share/lib/imq/ext

シンボリックリンクの例 (Solaris):

% ln -s j2eeSDK_install_directory/lib/pointbase/pointbase.jar /usr/share/lib/imq/ext

Message Queue の持続に必要なデータベーススキーマを作成します。

組み込みデータベース用の imqdbmgr create all コマンドまたは外部データベース用の imqdbmgr create tbl コマンドを使用します。「データベース管理ユーティリティ (imqdbmgr)」を参照してください。

例:

imqdbmgr がある場所にディレクトリを移動します。

cd /usr/bin (Solaris)

cd /opt/sun/mq/bin (Linux)

cd IMQ_HOME/bin (Windows)

imqdbmgr コマンドを入力します。

imqdbmgr create all



注	組み込みデータベースを使用している場合、次のディレクトリ内に作成するのが最適です。 .../instances/instanceName/dbstore/dabatabseName。組み込みデータベースは、ユーザー名とパスワードで保護されていない場合、ファイルシステムのアクセス権によって保護される可能性があります。ブローカが確実にデータベースに対して読み取りと書き込みを実行できるように、ブローカを実行するユーザーは、imqdbmgr コマンドを使用して組み込みデータベースを作成したユーザーと同一でなければなりません (「データベース管理ユーティリティ (imqdbmgr)」を参照)。

JDBC 関連のブローカのプロパティ

ファイルが存在しない場合、Message Queue がファイルを作成できるように、-name instanceName オプションを使用して、ブローカを起動する必要があります。

「JDBC ベースの持続」に、JDBC アクセスが可能なデータストアに接続する場合に、設定が必要な設定プロパティを示します。この節の最後に、これらのプロパティをまとめています。プラグイン持続を使用する各ブローカインスタンスのインスタンス設定ファイル (config.properties) に、これらのプロパティを設定します。

インスタンス設定プロパティを使用すると、Message Queue データベーススキーマを作成する SQL コードをカスタマイズできます。各データベーステーブルを作成するための SQL コードを指定する設定可能なプロパティがあります。これらのプロパティは、接続されたデータベースが使用するデータタイプを適切に指定するために必要となります。

正確な SQL 構文に関してはデータベースベンダー間で互換性がないため、必ず使用中のデータベースのベンダーが提供している相応するマニュアルを確認し、それに従って表 14-7 のプロパティを調整してください。たとえば、PointBase データベースの場合は、IMQMSG35 テーブルの MSG 列で許容される最大の長さを調整する必要が生じる場合があります (imq.persist.jdbc.table.IMQMSG35 プロパティを参照)。

すべてのブローカ設定プロパティと同様に、値は -D コマンド行オプションを使用して設定できます。データベースで特定のデータベース固有プロパティを設定する必要がある場合、ブローカ (imqbrokerd) の起動時に、-D コマンド行オプションを使用するか、あるいは Database Manager ユーティリティ (imqdbmgr) を使用して設定することができます。

PointBase の組み込みデータベース例の場合、データベースコネクション URL に、データベースの絶対パスを指定する代わりに、-D コマンド行オプションを使用して、PointBase システムディレクトリを定義することができます。

その場合、次のように URL を指定してデータベースを作成できます。

imq.persist.store。ファイルベースまたは JDBC ベースのデータストアを指定します。

imq.persist.jdbc.brokerid。固有の名前にするために、データベーステーブル名に追加されるブローカインスタンス識別子を指定します。

imq.persist.jdbc.driver。データベースに接続する JDBC ドライバの Java クラス名を指定します。

imq.persist.jdbc.opendburl。既存データベースへのコネクションを開くためのデータベース URL を指定します。

imq.persist.jdbc.createdburl。データベースを作成するコネクションを開くためのデータベース URL を指定します。

imq.persist.jdbc.user。必要に応じて、データベースコネクションを開くときに使用するユーザー名を指定します。

imq.persist.jdbc.needpassword。データベースでブローカのアクセスにパスワードを必要とするかどうかを指定します。

imq.persist.jdbc.password。データベースコネクションを開く際に使用するパスワードを、必要に応じて指定します。