4.0 リリースでの新機能

Message Queue 4.0 に含まれる新機能は次のとおりです。

• 「C API および C クライアントランタイムのインタフェースの変更」

• 「Java API および Java クライアントランタイムのインタフェースの変更」

• 「持続ストアに関する情報の表示」

• 「持続ストアの形式の変更」

• 「ブローカ管理」

• 「JDBC 持続サポート」

• 「SSL サポート」

• 「JMX サポート」

• 「クライアントランタイムログ」

• 「接続イベント通知」

以降の節で、これらの機能について説明しています。

version 4.0 には、軽度とはいえ、状況によって十分な対応が必要になる変更が導入されています。その 1 つとして、パスワードを指定するコマンド行オプションが使用されなくなったことが挙げられます。今後は、「使用されなくなったパスワードオプション」で説明するように、すべてのパスワードをファイルに保存する必要があります。

C API および C クライアントランタイムのインタフェースの変更

Message Queue の Version 4.0 では、デッドメッセージキューに配置されたすべてのメッセージで設定される 2 つの新しいプロパティーが追加されています。

• JMS_SUN_DMQ_PRODUCING_BROKER は、メッセージが生成されたブローカを指定します。

• JMS_SUN_DMQ_DEAD_BROKER は、メッセージをデッドとして指定したブローカを指定します。

Java API および Java クライアントランタイムのインタフェースの変更

Message Queue の Version 4.0 では、デッドメッセージキューに配置されたすべてのメッセージに設定される 2 つの新しいプロパティーが追加されています。

• JMS_SUN_DMQ_PRODUCING_BROKER は、メッセージが生成されたブローカを指定します。

• JMS_SUN_DMQ_DEAD_BROKER は、メッセージをデッドとして指定したブローカを指定します。

持続ストアに関する情報の表示

imqdbmgr コマンドに query サブコマンドが追加されました。このサブコマンドは、持続ストアの情報 (ストアバージョン、データベースユーザー、データベーステーブルが作成されたかどうかなど) を表示するために使用します。

次に、このコマンドによって表示される情報の例を示します。

imqdbmgr query

[04/Oct/2005:15:30:20 PDT] Using plugged-in persistent store:
        version=400
        brokerid=Mozart1756
        database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb
        database user=scott
Running in standalone mode.
Database tables have already been created.

持続ストアの形式の変更

Message Queue の Version 3.7 UR1 では、パフォーマンスを向上するために持続ストアの形式に 2 つの変更が加えられました。1 つはファイルストアに対する変更で、もう 1 つは JDBC ストアに対する変更です。

• ファイルストア内で持続されるトランザクションデータの形式

  ディスク I/O を軽減し、JMS トランザクションのパフォーマンスを向上させるために、Message Queue ファイルベースの持続ストア内に格納されているトランザクション状態情報の形式が変更されました。

• Oracle JDBC ストア

  以前のバージョンの Message Queue では、Oracle のストアスキーマでは、メッセージデータを格納するために LONG RAW データ型が使用されていました。Oracle 8 では、Oracle によって BLOB データ型が導入され、LONG RAW 型は使用されなくなりました。Message Queue 3.7 UR1 では、パフォーマンスとサポート性を向上するために、データ型が BLOB に変更されました。

これらの変更がストアの互換性にも影響し、Message Queue version 3.7 UR1 では、ファイルストアと JDBC ストアの両方のストアバージョンが 350 から 370 に変更されました。

Message Queue version 4.0 では、最適化と将来の機能拡張をサポートするために、JDBC ストアが変更されました。このため、JDBC ストアのバージョンが 400 になりました。ただし Version 4.0 では、ファイルベースの持続ストアには変更が行われていないため、このファイルストアのバージョンは 370 のままです。

Message Queue 4.0 は、ファイルベースの持続ストアと JDBC の持続ストアの最新バージョンへの持続ストアの自動変換をサポートしています。imqbrokerd を最初に起動したときに、ユーティリティーが古いバージョンのストアを検出した場合、古いストアはそのままで、ストアを新しい形式に移行します。

• ファイルベースのストアのバージョン 200 および 350 は、バージョン 370 の形式に移行されます。

• JDBC ストアのバージョン 350 および 370 は、バージョン 400 の形式に移行されます。バージョン 200 ストアをアップグレードする必要がある場合は、いったん中間的な release 3.5 または 3. 6 にアップグレードする必要があります。

このアップグレードをロールバックする必要のある場合は、Message Queue 4.0 をいったんアンインストールして、以前実行していたバージョンを再インストールします。ストアの古いコピーはそのまま残っているので、ブローカはストアの古いコピーを実行できます。

ブローカ管理

コマンドユーティリティー (imqcmd) に、サブコマンドといくつかのオプションが追加されました。管理者はこれらを使用して、ブローカを休止したり、指定した間隔の後でブローカをシャットダウンしたり、接続を破棄したり、Java システムのプロパティー (たとえば、コネクション関連のプロパティー) を設定したりできます。

• ブローカを休止すると休止状態になり、ブローカをシャットダウンまたは再起動する前に、メッセージを排出してしまうことができます。休止状態にあるブローカに新しく接続が作成されることはありません。ブローカを休止するには、次のようなコマンドを入力します。

  imqcmd quiesce bkr -b Wolfgang:1756

• 指定した間隔の後でブローカをシャットダウンするには、次のようなコマンドを入力します。(時間間隔は、ブローカをシャットダウンするまでの待機を秒数で指定します。)

  imqcmd shutdown bkr -b Hastings:1066 -time 90

  時間間隔を指定した場合、ブローカはシャットダウンが発生するタイミングを示すメッセージを記録します。以下にその例を示します。

  Shutting down the broker in 29 seconds (29996 milliseconds)

  ブローカがシャットダウンを待っている間、ブローカの動作は次のような影響を受けます。

  • 管理 JMS 接続は引き続き受け付けられます。

  • 新しい JMS 接続は受け付けられません。

  • 既存の JMS 接続は引き続き機能します。

  • ブローカが高可用性クラスタ内のほかのブローカを継承することはできません。

  • imqcmd ユーティリティーはブロックはせず、シャットダウンの要求をブローカに送信してすぐに返します。

• 接続を破棄するには、次のようなコマンドを入力します。

  imqcmd destroy cxn -n 2691475382197166336

  コマンド imqcmd list cxn または imqcmd query cxn を使用してコネクション ID を取得します。

• imqcmd を使用してシステムプロパティーを設定するには、新しい –D オプションを使用します。これは、JMS コネクションファクトリのプロパティー、またはコネクション関連の Java システムのプロパティーの設定または上書きに便利です。次に例を示します。

  imqcmd list svc -secure -DimqSSLIsHostTrusted=true
  imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore 
              -Djavax.net.ssl.trustStorePassword=mytrustword

imqcmd コマンドの構文の詳細は、『Sun Java System Message Queue 4.1 Administration Guide』の第 13 章「Command Line Reference」を参照してください。

JDBC 持続サポート

Apache Derby Version 10.1.1 が、JDBC 準拠の持続ストアプロバイダとしてサポートされるようになりました。

SSL サポート

release 4.0 から、クライアントコネクションファクトリのプロパティー imqSSLIsHostTrusted のデフォルト値が false になりました。使用しているアプリケーションが以前のデフォルト値の true に依存している場合は、再設定を行い、プロパティーを明示的に true に設定する必要があります。

ブローカが自己署名付き証明書を使用するように設定されているときは、ホストを信頼することもできます。この場合、接続で SSL ベースの接続サービスを使用するように指定する (imqConnectionType プロパティーを使用する) ことに加えて、imqSSLIsHostTrusted プロパティーを true に設定することをお勧めします。

たとえば、ブローカが自己署名付き証明書を使用するときに安全にクライアントアプリケーションを実行するには、次のようなコマンドを使用します。

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true <ClientAppName>

ブローカが自己署名付き証明書を使用するときに安全に管理ツール imqcmd を実行するには、次のようなコマンドを使用します。

imqcmd list svc -secure -DimqSSLIsHostTrusted=true

JMX サポート

Java Management Extensions (JMX) 仕様に準拠して、Message Queue ブローカを設定および監視するための新しい API が追加されました。この API を使用すると、Message Queue クライアントアプリケーション内部からプログラムによってブローカ関数を設定および監視することができます。以前のバージョンの Message Queue では、これらの関数にはコマンド行または管理コンソールからしかアクセスできませんでした。

この API は、一連の JMX Managed Bean (MBean) によって設定されており、次の Message Queue 関連のリソースを管理します。

• メッセージブローカ

• 接続サービス

• 接続

• 宛先

• メッセージプロデューサ

• メッセージコンシューマ

• トランザクション

• ブローカクラスタ

• ロギング

• Java Virtual Machine (JVM)

これらの MBean によって、基礎となるリソースの状態を、同期をとりながらポーリングおよび操作するための属性と操作が設定されます。また、状態が変更されたときに、クライアントアプリケーションが非同期で待機して応答できるようにする通知も設定されます。JMX API を使用して、クライアントアプリケーションは次のようなタスクを設定および監視することができます。

• ブローカのポート番号を設定する

• ブローカのメッセージの最大サイズを設定する

• 接続サービスを一時停止する

• 接続サービスの最大スレッド数を設定する

• サービス上の現在の接続数を取得する

• 接続を破棄する

• 送信先を作成する

• 送信先を破棄する

• 送信先の自動作成を有効または無効にする

• 送信先からすべてのメッセージを削除する

• ブローカの起動後に送信先の受信したメッセージの累積数を取得する

• キューの現在の状態 (実行中または一時停止) を取得する

• トピックのメッセージプロデューサの現在数を取得する

• 永続サブスクライバからすべてのメッセージを削除する

• 現在の JVM ヒープサイズを取得する

JMX API の紹介と詳細情報については、『Sun Java System Message Queue 4.1 Developer’s Guide for JMX Clients』を参照してください。

ブローカサポート: JMX 関連のプロパティー

JMX API をサポートするために、いくつかの新しいブローカプロパティーが追加されました (表 1–3 を参照)。これらのプロパティーはいずれも Message Queue コマンドユーティリティー (imqcmd) によるコマンド行からは設定できません。その代わりに、ブローカユーティリティー (imqbrokerd) の -D オプションを使用するか、ブローカのインスタンス設定ファイル ( config.properties) を手作業で編集することで設定できます。さらに、これらのプロパティーのいくつか (imq.jmx.rmiregistry.start、 imq.jmx.rmiregistry.use、 imq.jmx.rmiregistry.port) は、表 1–4 に示されている新しいブローカユーティリティーオプションを使用して設定できます。次の表は、各オプションとその型、それぞれの使用方法について示しています。

   /jndi/rmi://brokerHost:rmiPort
      /brokerHost/brokerPort/connectorName

   /stub/rmiStub

imq.jmx.connector.list プロパティーは、ブローカの起動時に作成される一連の名前付き JMX コネクタを定義します。imq.jmx.connector.activelist では、これらの中でアクティブにするものを指定します。名前付きのコネクタには、それぞれ独自のプロパティーセットがあります。

デフォルトでは、 jmxrmi および ssljmxrmi という名前の 2 つの JMX コネクタが作成されます。前者は SSL 暗号化を使用しないように設定 (imq.jmx.connector.jmxrmi.useSSL = false) され、後者は使用するように設定 (imq.jmx.connector.ssljmxrmi.useSSL = true) されています。デフォルトでは、ブローカの起動時には jmxrmi コネクタのみがアクティブになります。通信のセキュリティー保護のために ssljmxrmi コネクタをアクティブにする方法については、「JMX クライアント用の SSL サポート」を参照してください。

使いやすくするために、コマンド行のブローカユーティリティー (imqbrokerd) にも、RMI レジストリの使用方法、起動、ポートを制御するための新しいオプション (表 1–4) が追加されています。これらのオプションの使用方法と効果は、表 1–3 に示されているブローカプロパティーの中の対応するものと同じです。次の表では、各オプションとともに対応するブローカプロパティーを示し、その使用方法についても説明します。

ブローカの起動時に作成および起動される JMX コネクタの JMX サービス URL を表示するために、コマンド行のコマンドユーティリティー (imqcmd) に新しいサブコマンド (表 1–5) が追加されました。この情報は、JMX コネクタを取得するために Message Queue の簡易クラス AdminConnectionFactory を使用しない JMX クライアントにとって必要になります。また、Java Monitoring and Management Console ( jconsole) などの汎用の JMX ブラウザを介して Message Queue を管理または監視するために使用することもできます。

JMX クライアント用の SSL サポート

これまでに説明したように、Message Queue のメッセージブローカは、デフォルトでは、事前に設定済みの JMX コネクタ jmxrmi を使用して、セキュリティー保護されていない通信用に設定されています。通信のセキュリティー保護のために SSL (Secure Socket Layer) を使用する必要のあるアプリケーションでは、代わりにセキュリティー保護された JMX コネクタである ssljmxrmi をアクティブにする必要があります。このためには次の手順を実行する必要があります。

1. 『Message Queue 管理ガイド』に示されている ssljms、ssladmin、または cluster 接続サービスと同じ方法で、署名済みの証明書を取得およびインストールします。

2. 必要に応じて、ルート CA 証明書をトラストストア内にインストールします。

3. ブローカの起動時にアクティブになるように、JMX コネクタのリストに ssljmxrmi コネクタを追加します。

   imq.jmx.connector.activelist=jmxrmi,ssljmxrmi

4. Message Queue ブローカユーティリティー (imqbrokerd) をパスワードファイル内のキーストアパスワードに渡すか、プロンプト表示されるコマンド行から入力して、ブローカを起動します。

5. デフォルトでは、ssljmxrmi コネクタ、またはその他の SSL ベースのコネクタ は、提示されるすべてのブローカ SSL 証明書を検証するように設定されています。この検証を回避する場合、ソフトウェアのテスト中で自己署名の証明書を使用している場合などは、ブローカプロパティー imq.jmx.connector.ssljmxrmi.brokerHostTrusted を true に設定します。

クライアント側では、ssljmxrmi を優先コネクタとして指定した URL を使用して管理者のコネクションファクトリ (AdminConnectionFactory ) を設定する必要があります。

AdminConnectionFactory  acf = new AdminConnectionFactory();
acf.setProperty(AdminConnectionConfiguration.imqAddress, "mq://myhost:7676/ssljmxrmi");

必要に応じて、システムプロパティー javax.net.ssl.trustStore および javax.net.ssl.trustStorePassword を使用して、JMX クライアントをトラストストアにポイントします。

クライアントランタイムログ

この節では、Message Queue 4.0 による接続のクライアントランタイムログのサポートと、セッション関連のイベントについて説明します。

JDK 1.4 以上には、java.util.logging ライブラリが含まれています。このライブラリは、アプリケーション固有のログに使用される標準のロガーインタフェースを実装しています。

Message Queue のクライアントランタイムは Java Logging API を使用してログ機能を実装します。ログ活動を設定するために、すべての J2SE 1.4 ロギング機能を使用できます。たとえば、Message Queue クライアントランタイムがログ情報を出力する方法を設定するために、アプリケーションは次の Java ロギング機能を使用することができます。

• ログハンドラ

• ログフィルタ

• ログフォーマッタ

• ログレベル

Java Logging API の詳細は、http://java.sun.com/javase/ja/6/docs/ja/technotes/guides/logging/overview.html にある Java ロギングの概要を参照してください。

ログの名前空間、レベル、活動

Message Queue プロバイダは、ログレベルやログ活動に関連付けて一連のログの名前空間を定義します。Message Queue クライアントは、ログ設定が適切であれば、この名前空間を使用して接続やセッションイベントをログに記録することができます。

Message Queue クライアントランタイムのルートのログ名前空間は、javax.jms と定義されます。Message Queue クライアントランタイム内のすべてのロガーが、この名前を親の名前空間として使用します。

Message Queue クライアントランタイムに使用されるログレベルは、java.util.logging.Level クラス内で定義されるものと同じです。このクラスでは、7 つの標準ログレベルと、ログのオン/オフに使用できる 2 つの追加設定が定義されます。

OFF

ログをオフにします。

SEVERE

優先順位が最高である最高値。アプリケーションで定義します。

WARNING

アプリケーションで定義します。

INFO

アプリケーションで定義します。

CONFIG

アプリケーションで定義します。

FINE

アプリケーションで定義します。

FINER

アプリケーションで定義します。

FINEST

優先順位が最低である最低値。アプリケーションで定義します。

ALL

すべてのメッセージのログを有効にします。

一般に、Message Queue クライアントランタイム内で発生した例外やエラーは、名前空間 javax.jms を使用するロガーによってログ記録されます。

• JVM からスローされクライアントランタイムによってキャッチされる例外 (IOException など) は、ログ名前空間 javax.jms を使用するロガーによって WARNING レベルでログ記録されます。

• クライアントランタイムからスローされる JMS 例外 (IllegalStateException など) は、ログ名前空間 javax.jms を使用するロガーによって FINER レベルでログ記録されます。

• JVM からスローされクライアントランタイムによってキャッチされるエラー (OutOfMemoryError など) は、ログ名前空間 javax.jms を使用するロガーによって SEVERE レベルでログ記録されます。

以下の表は、JMS コネクションとセッションについて、ログ記録できるイベントとログイベントに対して設定する必要のあるログレベルを示しています。

次の表は、コネクションのログレベルとイベントについて示したものです。

セッションの場合、次の情報がログレコードに記録されます。

• コンシューマに配信されるメッセージの各ログレコードには、ConnectionID、SessionID、ConsumerID が含まれています。

• プロデューサによって送信されるメッセージの各ログレコードには、ConnectionID、SessionID、ProducerID、送信先名が含まれています。

次の表は、セッションのログレベルとイベントについて示したものです。

デフォルトでは、出力ログレベルはアプリケーションの実行されている JRE から継承されます。JRE_DIRECTORY/lib/logging.properties ファイルを参照してレベルを確認してください。

ログはプログラムや設定ファイルを使用して設定できます。また、ログの発生する範囲を制御することもできます。次の節では、これらの機能について説明します。

JRE ロギング設定ファイルの使用

次の例は、JRE_DIRECTORY/lib/logging.properties ファイル内でログの名前空間とログレベルを設定する方法を示しています。この方法は Java ランタイム環境のログレベルの設定に使用されます。JRE を使用するすべてのアプリケーションが同じログ設定になります。次に示すサンプル設定では、名前空間 javax.jms.connection のログレベルをINFO に設定し、その出力が java.util.logging.ConsoleHandler に書き込まれるように指定しています。

#logging.properties file.
# "handlers" specifies a comma separated list of log Handler 
# classes. These handlers will be installed during VM startup.
# Note that these classes must be on the system classpath.
# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.

	handlers= java.util.logging.ConsoleHandler

# Default global logging level.
# This specifies which kinds of events are logged across
# all loggers. For any given facility this global level
# can be overriden by a facility-specific level.
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.

    .level= INFO

# Limit the messages that are printed on the console to INFO and above.

    java.util.logging.ConsoleHandler.level = INFO
    java.util.logging.ConsoleHandler.formatter = 
                                    java.util.logging.SimpleFormatter

# The logger with javax.jms.connection name space will write
# Level.INFO messages to its output handler(s). In this configuration 
# the ouput handler is set to java.util.logging.ConsoleHandler.

    javax.jms.connection.level = INFO

特定のアプリケーションに対するログ設定ファイルの使用

アプリケーションの実行に使用する Java コマンド行からログ設定ファイルを定義することもできます。このアプリケーションは、指定のログファイル内で定義された設定を使用します。次の例では、configFile は JRE_DIRECTORY/lib/logging.properties ファイル内で定義されているものと同じ形式を使用します。

java -Djava.util.logging.config.file=configFile MQApplication

プログラムによるログ設定

次のコードでは、java.util.logging API を使用して、javax.jms.connection 名前空間のログレベルを FINE に変更することで、接続イベントをログ記録しています。このようなコードをアプリケーションに追加して、プログラムによるログ設定を行うことができます。

import java.util.logging.*;
//construct a file handler and output to the mq.log file 
//in the system's temp directory.

    Handler fh = new FileHandler("%t/mq.log");
    fh.setLevel (Level.FINE);

//Get Logger for "javax.jms.connection" domain.

    Logger logger = Logger.getLogger("javax.jms.connection");
    logger.addHandler (fh);

//javax.jms.connection logger would log activities   
//with level FINE and above.

    logger.setLevel (Level.FINE);

接続イベント通知

接続イベント通知を使用すると、Message Queue クライアントは接続のクローズおよび再接続イベントを待機して、通知タイプと接続状態に基づいて適切なアクションを起こすことができます。たとえば、フェイルオーバーが発生してクライアントが別のブローカに再接続された場合、アプリケーションはそのトランザクションの状態をクリーンアップしてから新しいトランザクションに進む必要があるかもしれません。

Message Queue プロバイダは、接続について深刻な問題を検出した場合、接続オブジェクトの登録済みの例外リスナーを呼び出します。このプロバイダは、リスナーの onException メソッドを呼び出し、問題を記述する JMSException 引数にこれを渡します。Message Queue プロバイダはイベント通知 API も提供し、これを使用してクライアントランタイムは、接続状態の変更をアプリケーションに通知できます。通知 API は次の要素によって定義されます。

• com.sun.messaging.jms.notification パッケージ。イベントリスナーと通知イベントオブジェクトを定義します。

• com.sun.messaging.jms.Connection インタフェース。javax.jms.Connection インタフェースへのエクステンションを定義します。

次の節では、通知をトリガーできるイベントと、イベントリスナーの作成方法について説明します。

接続イベント

次の表は、イベントリスナーによって返されるイベントについて説明したものです。

接続イベントの発生時に JMS 例外リスナーは呼び出されません。例外リスナーが呼び出されるのは、クライアントランタイムの再接続の試行回数が上限に達してしまった場合のみです。クライアントランタイムは、常に例外リスナーの前にイベントリスナーを呼び出します。

イベントリスナーの作成

次のコード例は、接続イベントリスナーの設定方法を示したものです。接続イベントが発生するたびに、イベントリスナーの onEvent メソッドがクライアントランタイムによって呼び出されます。

//create an MQ connection factory.

com.sun.messaging.ConnectionFactory factory =
        new com.sun.messaging.ConnectionFactory();

//create an MQ connection.

com.sun.messaging.jms.Connection connection = 
       (com.sun.messaging.jms.Connection )factory.createConnection();

//construct an MQ event listener.  The listener implements 
//com.sun.messaging.jms.notification.EventListener interface.

com.sun.messaging.jms.notification.EventListener eListener = 
       new ApplicationEventListener();

//set event listener to the MQ connection.

connection.setEventListener ( eListener );

イベントリスナーの例

この例では、アプリケーションが、そのイベントリスナーが接続イベントをアプリケーションのロギングシステムに記録するように選択します。

public class ApplicationEventListener implements
				com.sun.messaging.jms.notification.EventListener {

public void onEvent ( com.sun.messaging.jms.notification.Event connEvent ) {
      	log (connEvent);
}
private void log ( com.sun.messaging.jms.notification.Event connEvent ) {
	      String eventCode = connEvent.getEventCode(); 
      	String eventMessage = connEvent.getEventMessage();
    	  //write event information to the output stream.
     	}
}