HornetQ ユーザーガイド

JBoss Enterprise Application Platform 5

JBoss Enterprise Application Platform 5 向け

エディッション 5.1.2

Andy Taylor

同じ場所に設置する対称的な専用クラスターに関する章 
Red Hat, Inc.

編集者

Jared Morgan

Red Hat, Inc. エンジニアリングコンテンツサービス

編集者

Laura Bailey

Red Hat, Inc. エンジニアリングコンテンツサービス

編集者

Rebecca Newton

Red Hat, Inc. エンジニアリングコンテンツサービス

概要

JBoss Enterprise Application Platform 5 およびそのパッチリリース向けの Hornet のガイド。

第1章 はじめに

JBoss Enterprise Application Platform メッセージングは HornetQ に基づき、 JBoss コミュニティーで開発された Open Source Message Oriented Middleware (MoM) プロジェクトです。
Red Hat 認定 HornetQ 製品は、複数のハードウェアプラットフォームで信頼性を確保するためにテストされ、製品アップデートと技術サポートを提供する専用サポートネットワークにより支援されているため、コミュニティーで提供されるものと異なります。
HornetQ は Java ベースのマルチプロトコルの、クラスタリングされた非同期メッセージングシステムです。HornetQ には、永続化メッセージング実装に適切な高パフォーマンスジャーナリングシステムが含まれます。
HornetQ により提供される高可用性 (HA) 機能は、サーバーノードでの障害発生時にクライアントのフェイルオーバーをサポートします。

第2章 HornetQ への移行

既存の JBoss Messaging アプリケーションを HornetQ に移行する場合は、本章をお読みください。カ『『Installation Guide (インストールガイド)』』には、HornetQ とともに JBoss Enterprise Application Platform のインスタンスをインストールする手順が記載されており、この項とともにその手順をお読みください。

2.1. 移行する前に

重要

JBoss Messaging から HornetQ に移行する前に、クライアントとサーバーをシャットダウンする必要があります。

注記

JBoss Messaging は、null 永続化が指定されない限り、永続データを格納するデータベースを使用します。HornetQ は、データベースの代わりに独自の高パフォーマンスジャーナルシステムを使用するため、移行のためにデータベースをシャットダウンする必要はありません。

2.1.1. 重要なデータのバックアップ

移行する前に、アプリケーションと JBoss Messaging サーバーで使用されるすべてのデータをバックアップすることが重要です。この項では、移行前にバックアップすることが推奨されるデータの概要を示します。

2.1.1.1. JBoss Messaging データベーステーブル

JBoss Messaging は、永続化データを格納するために複数のデータベーステーブルを使用します。これらのテーブルには、JBoss Messaging の内部ステータス情報、永続化メッセージ、およびセキュリティー設定が含まれます。この項では、重要なデータを保持するテーブルをリストします。
JBM_MSG_REF、JBM_MSG
これらのテーブルは、永続メッセージとそのステータスを格納します。
JBM_TX、JBM_TX_EX
これらのテーブルは、トランザクションステータスを格納します。
JBM_USER、JBM_ROLE
これらのテーブルは、ユーザーおよびロール情報を格納します。
JBM_POSTOFFICE
このテーブルはバインディング情報を保持します。

2.1.1.2. JBoss Messaging 設定ファイル

ほとんどの設定ファイルは $JBOSS_HOME/server/$PROFILE/deploy/messaging に格納されます (JBoss Messaging サーバープロファイルが messaging であることを前提とします)。アプリケーションはいくつかの設定ファイルをデプロイする他の場所を選択できます。
以下の設定ファイルをバックアップし、HornetQ に移行する必要があります。
接続ファクトリーサービス設定ファイル
JBoss Messaging サーバーでデプロイされた JMS 接続ファクトリーが含まれます。
宛先サービス設定ファイル
JBoss Messaging サーバーでデプロイされた JMS キューおよびトピックが含まれます。
ブリッジサービス設定ファイル
JBoss Messaging サーバーでデプロイされたブリッジサービスが含まれます。
messaging-service.xml やデータベース永続化設定ファイルなどの他の設定ファイルは、 JBoss Messaging MBean 設定です。HornetQ 実装は、Plain Old Java Object (POJO) のみから構成されるため、これらの設定ファイルは移行の対象となりません。
JBoss Messaging は、動作するために JBoss Remoting および JGroups サービスに依存します。これらのサービスの設定ファイルには、アプリケーションに固有の設定が含まれます。HornetQ のトランスポートレイヤーとクラスター設計は、JBoss Messaging のものと異なります。サービス設定ファイルのパラメーターを HornetQ の同等のもの (存在する場合) とマッピングする必要があります。

2.2. アプリケーションコア

アプリケーションで標準的な JMS を使用している場合は、高可用性 (HA) とクラスタリングに関するソースコードに変更を加える必要があります。特に、アプリケーションによる障害とロールバックの処理方法を調整する必要があります。詳細については、「クライアントサイドの障害処理」 を参照してください。
整列グループなどの JBoss Messaging に固有の機能を使用する場合は、これらの機能を HornetQ の同等の機能に変更する必要があります。表2.1「JBoss Messaging と HornetQ 間の実装クラスマッピング」 は、JBoss Messaging JMS 実装クラスと、対応する HornetQ の同等のものをリストしています。

表2.1 JBoss Messaging と HornetQ 間の実装クラスマッピング

org.jboss.jms.client. Classname HornetQ Equivalent Classname
JBossConnectionFactory org.hornetq.jms.client.HornetQConnectionFactory
JBossConnection org.hornetq.jms.client.HornetQConnection
JBossSession org.hornetq.jms.client.HornetQSession
JBossMessageProducer org.hornetq.jms.client.HornetQMessageProducer
JBossMessageConsumer org.hornetq.jms.client.HornetQMessageConsumer

注記

JBoss Messaging 固有の API を使用していない限り、JMS オブジェクトを固有の実装に明示的に変更する必要はありません。可能な限り、標準的な JMS API を使用できます。

2.3. クライアントサイドの障害処理

JMS の仕様では、高可用性フェイルオーバーまたはクラスタリングでサーバーがどのように動作するかが定義されません。ただし、この仕様では、アプリケーションが障害およびロールバックシナリオをどのように処理するかが推奨されています。
JBoss Messaging は、フェイルオーバー中にクライアントに例外をスローしません。JBoss Messaging のアプリケーションは、クラスター内の別のノードに自動的に接続されます。
HornetQ では、フェイルオーバーまたはロールバックによって例外がトリガーされます。JBoss Messaging アプリケーションはこの例外を補足し、HornetQ と互換性を持つようメッセージの送信を再試行する必要があります。
JBoss Messaging では、障害を処理するために以下の表現で十分でした。
producer.send(createMessage(session, i));
System.out.println("Message: " + i);
HornetQ では、以下の try ブロックが必要になります。
try {
  producer.send(createMessage(session, i));
  System.out.println("Message: " + i);
} catch (Exception e) {
  Thread.sleep(1000); 
  producer.send(createMessage(session, i));
}

2.4. HornetQ のインストール

JBoss Enterprise Application Platform のこのディストリビューションで HornetQ をインストールする場合の最新の詳細情報については、『『Installation Guide (インストールガイド)』』を参照してください。

2.5. サーバー設定の移行

HornetQ の設定は、JBoss Messaging と大幅に異なるため、これら 2 つの間で 1 対 1 のマッピングを提供することはできません。表2.2「JBoss Messaging と HornetQ 間のサーバー属性マッピング」 は、HornetQ での JBoss Messaging サーバー属性とその同等のもの (存在する場合) をリストしています。
明示的に示されていない限り、HornetQ サーバー属性カラムの属性は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されます。このファイルでサポートされるディレクティブの完全セットは、付録A 設定リファレンス で記載されています。

表2.2 JBoss Messaging と HornetQ 間のサーバー属性マッピング

JBoss Messaging サーバー属性 (サーバーピア MBean) 同等の HornetQ サーバー属性
ServerPeerID N/A - HornetQ は指定されたサーバー ID を必要としない
DefaultQueueJNDIContextDefaultTopicJNDIContext N/A
PostOffice N/A
DefaultDLQ N/A - HornetQ は、コアレベルでデッドレターアドレスを定義します。指定しない限り、アドレスに対するデフォルトのデッドレターアドレスは存在しません。
DefaultMaxDeliveryAttempts N/A - HornetQ では、デフォルト値は常に 10 です。
DefaultExpiryQueue N/A - HornetQ は、コアレベルで期限切れアドレスを定義します。指定しない限り、アドレスに対するデフォルトの期限切れアドレスは存在しません。
DefaultRedeliveryDelay N/A - HornetQ のデフォルトの再配信遅延は常に 0 です (遅延なし)。
MessageCounterSamplePeriod message-counter-sample-period
FailoverStartTimeout N/A
FailoverCompleteTimeout N/A
DefaultMessageCounterHistoryDayLimit N/A
ClusterPullConnectionFactory N/A
DefaultPreserveOrdering N/A
RecoverDeliveriesTimeout N/A
EnableMessageCounters Message-counter-enabled
SuckerPassword Cluster-password
SuckerConnectionRetryTimes bridges.reconnect-attempts
SuckerConnectionRetryInterval bridges.reconnect-interval
StrictTCK N/A
DestinationsMessageCountersMessageStatistics N/A - これらは、HornetQ の管理機能の一部です。詳細については、適切な章を参照してください。
SupportsFailover N/A
PersistenceManager N/A - HornetQ は、永続化ユーティリティーとして組み込みの高パフォーマンスジャーナルを使用します。
JMSUserManager N/A
SecurityStore N/A - セキュリティーマネージャーは、hornetq-beans.xml または hornetq-jboss-beans.xml で設定されます。

2.6. JMS 管理オブジェクトおよびブリッジの移行

HornetQ は、JMS 接続ファクトリー、宛先、およびブリッジを作成し、JBoss Messaging に別々にデプロイします。
JBoss Messaging では、JMS オブジェクトおよびブリッジはアプリケーションサーバー内で MBean サービスとして設定されます。HornetQ では、これらは POJO として実装されます。
これらのオブジェクトとブリッジの設定を JBoss Messaging から HornetQ に移行するには、JBoss Messaging から HornetQ へのパラメーターのマッピング方法を理解する必要があります。
表2.3「JMS 接続ファクトリー設定マッピング」 は、これらのパラメーターをマッピングします。特に説明されていない限り、すべての HornetQ オブジェクトおよびブリッジ属性は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で指定されます。付録A 設定リファレンス には、hornetq-jms.xml に対するサポートされたすべてのディレクティブが含まれます。

表2.3 JMS 接続ファクトリー設定マッピング

JBoss Messaging ConnectionFactory 属性 HornetQ JMS ConnectionFactory 属性
ClientID connection-factory.client-id
JNDIBindings connection-factory.entries
PrefetchSize connection-factory.consumer-window-size
SlowConsumers N/A - consumer-window-size=0 と同等
StrictTck N/A
SendAcksAsync connection-factory.block-on-acknowledge
DefaultTempQueueFullSizeDefaultTempQueuePageSizeDefaultTempQueueDownCacheSize N/A
DupsOKBatchSize connection-factory.dups-ok-batch-size
SupportsLoadBalancing N/A
SupportsFailover N/A
DisableRemotingChecks N/A
LoadBalancingFactory connection-factory.connection-load-balancing-policy-class-name
Connector connection-factory.connectors
EnableOrderingGroupDefaultOrderingGroup N/A
表2.4「JMS キュー設定マッピング」 は、JBoss Messaging Queue 属性を HornetQ JMS Queue 属性に対してどのようにマッピングするかについて説明しています。特に指定されない限り、これらの属性はJBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されます。hornetq-configuration.xml で指定されない場合は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で指定されます。

表2.4 JMS キュー設定マッピング

JBoss Messaging キュー属性 HornetQ JMS キュー属性
Name queue.name - hornetq-jms.xml で定義される
JNDIName queue.entry - hornetq-jms.xml で定義される
DLQ address-settings.dead-letter-address
ExpiryQueue address-settings.expiry-address
RedeliveryDelay address-settings.redelivery-delay
MaxDeliveryAttempts address-settings.max-delivery-attempts
SecurityConfig security-settings
FullSize address-settings.max-size-bytes - HornetQ ページング属性は、JBoss Messaging ページング属性と完全に一致しません。詳細については、適切な章を参照してください。
PageSize address-settings.page-size-bytes - HornetQ ページング属性は、JBoss Messaging ページング属性と完全に一致しません。詳細については、適切な章を参照してください。
DownCacheSize サポートされない
CreatedProgrammatically この属性を取得するために、org.hornetq.api.jms.management.JMSQueueControl を参照します。
MessageCount この属性を取得するために、org.hornetq.api.jms.management.JMSQueueControl を参照します。
ScheduledMessageCount この属性を取得するために、org.hornetq.api.jms.management.JMSQueueControl を参照します。
MessageCounter この属性を取得するために、org.hornetq.api.jms.management.JMSQueueControl を参照します。
MessageCounterStatistics この属性を取得するために、org.hornetq.api.jms.management.JMSQueueControl を参照します。
ConsumerCount この属性を取得するために、org.hornetq.api.jms.management.JMSQueueControl を参照します。
DropOldMessageOnRedeploy サポートされない
MaxSize サポートされない
Clustered サポートされない
表2.5「JMS トピック設定マッピング」JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml は、JBoss Messaging トピック属性を HornetQ JMS トピック属性に対してどのようにマッピングするかについて説明しています。特に指定されない限り、これらの属性は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で定義されます。

表2.5 JMS トピック設定マッピング

JBoss Messaging トピック属性 HornetQ JMS トピック属性
Name topic.name - hornetq-jms.xml で定義される
JNDIName topic.entry - hornetq-jms.xml で定義される
DLQ address-settings.dead-letter-address
ExpiryQueue address-settings.expiry-address
RedeliveryDelay address-settings.redelivery-delay
MaxDeliveryAttempts address-settings.max-delivery-attempts
SecurityConfig security-settings
FullSize address-settings.max-size-bytes - HornetQ ページング属性は、JBoss Messaging ページング属性と完全に一致しません。詳細については、適切な章を参照してください。
PageSize address-settings.page-size-bytes - HornetQ ページング属性は、JBoss Messaging ページング属性と完全に一致しません。詳細については、適切な章を参照してください。
DownCacheSize N/A
CreatedProgrammatically この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
MessageCounterHistoryDayLimit この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
MessageCounters この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
AllMessageCount この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
DurableMessageCount この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
NonDurableMessageCount この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
AllSubscriptionsCount この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
DurableSubscriptionsCount この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
NonDurableSubscriptionsCount この属性を取得するために、org.hornetq.api.jms.management.TopicControl を参照します。
MaxSize N/A
Clustered N/A
DropOldMessageOnRedeploy N/A
以下の表は、JBoss Messaging ブリッジ属性が HornetQ JMS ブリッジ属性に対してどのようにマッピングされるかを示しています。HornetQ の JMS ブリッジ属性は、その Bean 設定ファイルで定義されます。詳細については、31章JMS ブリッジ を参照してください。

表2.6 JMS ブリッジ設定マッピング

JBoss Messaging トピック属性 HornetQ JMS トピック属性
SourceProviderLoader SourceCFF
TargetProviderLoader TargetCFF
SourceDestinationLookup SourceDestinationFactory
TargetDestinationLookup TargetDestinationFactory
SourceUsername ソースユーザー名パラメーター
SourcePassword ソースユーザーパスワードパラメーター
TargetUsername ターゲットユーザー名パラメーター
TargetPassword ターゲットパラメーターパラメーター
QualityOfServiceMode サービス品質パラメーター
Selector セレクターパラメーター
MaxBatchSize Max batch size parameter
MaxBatchTime Max batch time parameter
SubName Subscription name parameter
ClientID Client ID parameter
FailureRetryInterval Failure retry interval parameter
MaxRetries Max retry times parameter
AddMessageIDInHeader Add Message ID in Header parameter

2.7. JBoss Messaging の他の設定

JBoss Messaging 依存サービスには、JBoss Remoting 用のものと JGroups 用のものの 2 つの種類の設定があります。この設定の詳細は、本書の範囲外です。詳細については、JBoss Remoting および JGroups の文書を参照してください。
HornetQ は、接続可能な独自のトランスポートアーキテクチャーとクラスタリング実装を持ち、トランスポートとして現在 Netty を使用しています。

2.8. 既存のメッセージの移行

すべての JMS 宛先を HornetQ に移行したら、既存のメッセージを移行できます。JMS Bridge は、既存のメッセージを JBoss Messaging から HornetQ に移動するために使用できます。準備されたすべてのトランザクションは、JBoss Messaging で完了する必要があります。

2.9. 管理 API を使用するアプリケーション

JBoss Messaging は、MBean インターフェースを使用して管理 API を公開します。HornetQ には、複数の異なる管理 API が含まれます (詳細については、28章管理 を参照してください)。
JBoss Messaging 管理 API には JMX でアクセスされる一方で、HornetQ は以下の手段で管理 API へのアクセスを提供します。
JMX
JMX は、Java アプリケーションを移行する標準的な方法です。
コア API
管理操作はコアメッセージを使用して HornetQ サーバーに送信されます。
JMS API
管理操作は JMS メッセージを使用して HornetQ サーバーに送信されます。
同じ機能は、3 つのすべての管理方法で実現できます。
以下の表は、JBoss Messaging 管理オブジェクトと HornetQ JMX の同等のものをリストしています。HornetQ で利用可能な他の管理 API については、28章管理 を参照してください。

表2.7 JBoss Messaging および HornetQ 管理オブジェクト API マッピング

org.jboss.jms.server. Class org.hornetq.api.jms.management. Class
ServerPeer JMSServerControl
connectionfactory.ConnectionFactory ConnectionFactoryControl
destination.QueueService JMSQueueControl
destination.TopicService TopicControl

注記

一部の JBoss Messaging MBean は、HornetQ で同等のものを持ちません。たとえば、JDBCPersistenceManagerService に対する HornetQ の同等なものはありません。これは、HornetQ が JBoss Messaging とは異なりデータソースを必要としないためです。

第3章 メッセージングコンセプト

HornetQ は、非同期のメッセージシステムです (メッセージングシステムと呼ばれる Message Oriented Middleware)。

3.1. メッセージングコンセプト

メッセージングシステムは、信頼性、トランザクション、および他の多くの機能を保持したまま、異種システムをお互いに疎結合するよう設計されています。
Remote Procedure Call (RPC) パターンに基づくシステムとは異なり、メッセージングシステムは主に、要求と応答間に密接な関係がない状態で非同期のメッセージング受け渡しパターンを使用します。ほとんどのメッセージングシステムは要求応答モードをサポートしますが、これはメッセージングシステムの主な機能ではありません。
システムがエンドツーエンドで非同期になるよう設計すると、ハードウェアリソースの使用率が改善され、IO 操作をブロックするスレッドの数が最小になり、ネットワーク帯域幅が能力いっぱい使用されます。
RPC の方法では、各要求ごとに応答を待つ必要があり、ネットワークラウンドトリップ時間、またはネットワークのレイテンシーにより制限されます。非同期システムでは、さまざまな方向のメッセージのフローをパイプラインできるため、レイテンシーではなくネットワークの帯域幅により制限されます。これにより、通常はパフォーマンスが大幅に優れたアプリケーションを作成できます。
メッセージングシステムはメッセージの送信者をメッセージのコンシューマーから切り離します。メッセージ送信者とコンシューマーは完全に独立しており、柔軟性があり、疎結合のシステムを作成できます。
大規模は企業では、メッセージングシステムを使用して、異種システムをお互いに疎結合するメッセージバスを実装することがよくあります。多くの場合、メッセージバスは Enterprise Service Bus (ESB) のコアを形成します。異種システムを切り離すためにメッセージバスを使用すると、システムを簡単に拡張または適合させたり、古いシステムを廃止したりできます。

3.2. メッセージングスタイル

通常、メッセージングシステムは、メッセージキューメッセージング (ポイントツーポイントメッセージングとも呼ばれます) とパブリッシュサブスクライブメッセージングの 2 つの非同期メッセージングの主要なスタイルをサポートします。これらについてはここで簡単に概説されます。

3.2.1. ポイントツーポイントパターン

このタイプのメッセージングでは、メッセージをキューに送信します。メッセージは通常、配信を保証するために保持されます。しばらくすると、メッセージングシステムはメッセージをコンシューマーに配信します。コンシューマーはメッセージを処理し、処理が終了するとメッセージを承認します。メッセージが承認されると、メッセージングはキューから消失し、再び配信できなくなります。メッセージングサーバーがコンシューマーから承認を受け取る前にシステムがクラッシュした場合は、回復時にメッセージをコンシューマーに再び送信できるようになります。
ポイントツーポイントメッセージングでは、キューに多くのコンシューマーが存在することがありますが、特定のメッセージはいずれか 1 つのコンシューマーによってのみ消費されます。キューに対する送信者( プロデューサーとも呼ばれます) は、キューの受信者 (コンシューマーとも呼ばれます) から完全に切り離されます。つまり、送信者と受信者はお互いの存在を認識しません。
ポイントツーポイントメッセージングの典型的な例は、企業の書籍発注システムの注文キューです。各注文は、注文キューに送信されるメッセージとして表されます。注文を注文キューに送信する多くのフロントエンド発注システムを考えてみましょう。メッセージはキューに到着すると、保持されます。これにより、サーバーがクラッシュしたときに、注文が失われなくなります。また、注文キューに多くのコンシューマーが存在することを考えてみましょう (各コンシューマーは注文処理コンポーネントのインスタンスを表します)。これらはさまざまな物理マシンに存在できますが、同じキューから消費します。メッセージングシステムは各メッセージをただ 1 つの注文処理コンポーネントに配信します。さまざまなメッセージをさまざまな注文プロセッサーで処理できまますが、単一の注文は、1 つの注文プロセッサーでのみ処理されます。これにより、注文が 2 度処理されなくなります。
注文プロセッサーがメッセージを受け取ると、注文が実現し、注文情報が倉庫システムに送信され、注文データベースが注文詳細で更新されます。注文プロセッサーが注文データベースを更新すると、注文が処理され、注文について忘れることができることをサーバーに伝えるメッセージが承認されます。多くの場合、倉庫システムへの送信、データベースの更新、および承認は、ACID ( Atomicity、Consistency、Isolation、Durability) プロパティーに準拠して単一のトランザクションで完了します。

3.2.2. パブリッシュサブスクライブパターン

パブリッシュサブスクライブメッセージングでは、多くの送信者がサーバーのエンティティ (トピック と呼ばれることがよくある) にメッセージを送信できます (たとえば、JMS ではこのように使用されます)。
トピックには多くのサブスクリプションが存在できます。サブスクリプションはトピックのコンシューマーの別名にすぎません。各サブスクリプションは、トピックに送信されるメッセージのコピーを受け取ります。これは、各メッセージが単一のコンシューマーによってのみ消費されるメッセージキューパターンとは異なります。
サブスクリプションは、オプションで 耐久 にすることができます。これは、サブスクライバーがメッセージを消費するまでトピックに送信された各メッセージのコピーを保持することを意味します (サーバーがクラッシュしたり、その間に再起動した場合であっても)。非耐久サブスクリプションは、サブスクリプションを作成した接続の最大存続期間の間のみ存在します。
パブリッシュサブスクライブメッセージングの例はニュースフィードです。ニュース記事が世界中のさまざまなエディターによって作成されると、ニュース記事はニュースフィードトピックに送信されます。ニュース記事を受け取ることに興味があるサブスクライバーは世界中にたくさんいます。各サブスクライバーはサブスクリプションを作成し、メッセージングシステムにより、各ニュースメッセージのコピーが各サブスクリプションに配信されます。

3.3. 配信の保証

ほとんどのメッセージングシステムの主要な機能は信頼できるメッセージングです。信頼できるメッセージングでは、サーバーは、システム障害の発生時であっても、メッセージがキューの各コンシューマーまたはトピックの各耐久サブスクリプションに対して 1 度だけしか配信されないことを保証します。これは、多くのビジネスで重要です。たとえば、注文を複数回承認したり、いずれかの注文が失われたりすることを望みません。
他のケースでは、1 度だけの配信保証について気にせず、配信の重複やメッセージの損失に満足である場合があります。この例は、一時的な株価更新です。株価は同じ株の次の更新によりすぐに変わります。メッセージングシステムでは、必要な配信保証を設定できます。

3.4. トランザクション

HornetQ は、XA: JTA の Java マッピングを使用して大規模なグローバルトランザクションの一部としてメッセージを送信および承認することをサポートします。

3.5. 耐久性

メッセージは耐久または非耐久のいずれかです。耐久メッセージは永続ストレージに保持され、サーバーの障害が発生したり、再起動したりしても保持されます。非耐久メッセージはサーバの障害が発生したり、再起動したりした場合に保持されません。耐久メッセージの例は、メッセージが失われてはならない注文または取引です。非耐久メッセージの例は、一時的であり、再起動後に保持する必要がない株価更新です。

3.6. メッセージング API とプロトコル

多くのメッセージングシステムは、メッセージングシステムと通信するためにクライアントが使用できる独自の API を提供します。
また、メッセージングシステムで使用する標準的な方法が存在し、一部の標準な方法が優勢になっています。これらの一部については、次の項で説明します。

3.6.1. Java Message Service (JMS)

JMS は Sun の Java EE specification の一部です。これはメッセージキューとパブリッシュサブスクライブメッセージングパターンをカプセル化する Java API です。JMS は最低限必要な仕様です。つまり、これは、すでに存在し、作成時に利用可能なメッセージングシステムの共通の機能をカプセル化するために作成されました。
JMS 非常に人気がある API であり、ほとんどのメッセージングシステムで実装されます。JMS は Java が実行されているクライアントでのみ利用可能です。
JMS は標準的なワイヤー形式を定義せず、プログラミング可能なAPI のみを定義するため、異なるベンダーの JMS クライアントおよびサーバーは、ベンダー独自の内部ワイヤープロトコルを使用するため、直接相互運用できません。
HornetQ は完全に互換性がある JMS 1.1 API を提供します。

3.6.2. システム固有の API

多くのシステムは、メッセージングシステムと対話するために独自のプログラミング可能な API を提供します。この利点は、システム機能の完全なセットをクライアントアプリケーションに公開できることです。JMS などの API は、通常はほとんどのメッセージングシステムが提供する追加のすべての機能を公開するのに十分ではありません。
HornetQ は、JMS API によりアクセス可能でないクライアントにアクセスする場合に、使用する独自のコアクライアント API を提供します。

3.7. 高可用性

高可用性 (HA) は、1 つまたは複数のサーバーで障害が発生した後でもシステムが稼働し続けることを意味します。HA のサポートのレベルはメッセージングシステムによって異なります。
HornetQ は、ライブサーバーの障害時にセッションがバックアップサーバーに最接続される自動フェイルオーバーを提供します。アプリケーションは、JMS の要件に従って高可用性を適切にサポートする必要があります。
HA の詳細と、アプリケーションがどのようにこのモードをサポートするかについては、「クライアントサイドの障害処理」 を参照してください。

3.8. クラスター

多くのメッセージングシステムでは、クラスターと呼ばれるメッセージングサーバーのグループを作成できます。クラスターを使用すると、送信および消費メッセージを多くのサーバーで分散できます。この場合、クラスターに新しいサーバーを追加することによりシステムは水平的にスケーリングできます。
クラスターサポートは、メッセージングシステムによって異なることがあり、一部のシステムはクラスターメンバーがお互いをほとんど認識しない非常に基本的なクラスターを持ちます。
HornetQ は、各ノードのコンシューマーの数や、コンシューマーがメッセージの準備をできているかどうかに応じて、メッセージをクラスター内のサーバー間でインテリジェントに負荷分散できる設定可能なクラスタリングモデルを提供します。
HornetQ は、特定のノードでメッセージを失わないように、クラスターのノード間でメッセージを自動的に再分散できます。
クラスタリングの詳細については、36章クラスター を参照してください。

3.9. ブリッジおよびルーティング

一部のメッセージングシステムでは、隔離されたクラスターまたは単一のノードを、Wide Area Network (WAN) やインターネットなどの信頼できない接続を介してブリッジで接続できます。
ブリッジは通常は 1 つのサーバーのキューからメッセージを消費し、メッセージを異なるサーバーの別のキューにルーティングします。ブリッジは、信頼できない接続に対応し、接続が再び利用可能になると自動的に再接続を行います。
HornetQ ブリッジは、特定のメッセージのみを転送するためにフィルター式で設定でき、トランスフォーメーションもフックインすることができます。
また、HornetQ では、サーバーサイドで設定するキュー間でルーティングを行えます。これにより、複雑なルーティングネットワークを設定し、ある宛先から別の宛先にメッセージを転送またはコピーし、相互接続されたブローカーのグローバルネットワークを形成できます。
詳細については、34章コアブリッジ33章メッセージフローの迂回と分割 を参照してください。

第4章 コアアーキテクチャー

HornetQ コアは、Plain Old Java Object (POJO) のセットとして設計され、できるだけ外部の jar に依存しないよう設計されています。結果として、HornetQ コアは標準的な JDK クラスよりも 1 つだけ多くの jar 依存関係 (netty.jar) を持ちます。これは、 いくつかの netty バッファクラスが内部で使用されているためです。
Each HornetQ サーバーは、メッセージと他の永続化に使用する独自の非常に高いパフォーマンスの永続ジャーナルを持ちます。
高パフォーマンスのジャーナルを使用すると、永続メッセージのパフォーマンスが向上します。これは、永続化のためにリレーショナルデータベースを使用する場合は、実現できません。
HornetQ クライアント (異なる物理マシンにある場合がある) は、HornetQ サーバーと対話します。HornetQ は現在クライアント側でのメッセージに対して 2 つの API を提供します。
コアクライアント API
これは、JMS の複雑な点を除いてメッセージ機能の完全なセットを実現する単純で直感的な Java API です。
JMS クライアント API
標準的な JMS API はクライアント側で利用できます。
JMS セマンティクスは、クライアント側のシン JMS ファサードレイヤーによって実装されます。
HornetQ サーバーは JMS と関連付けられず、JMS に関して何も知りません。HornetQ サーバーは、さまざま複数のプロトコルで使用するよう設計されたプロトコルアグノスティックメッセージサーバーです。
ユーザーがクライアント側で JMS API を使用する場合、すべての JMS の対話は、HornetQ ワイヤーフォーマットを使用してワイヤー上で転送する前に HornetQ コアクライアント API で操作に変換されます。
サーバーは常にコア API の対話だけを処理します。
この関係を示す概略図は、図4.1「HornetQ アプリケーションの対話の概略図」 で示されています。
HornetQ アプリケーションの対話の概略図

図4.1 HornetQ アプリケーションの対話の概略図

図 3.1 は、HornetQ サーバーと対話している 2 つのユーザーアプリケーションを示しています。ユーザーアプリケーション 1 は JMS API を使用し、ユーザーアプリケーション 2 はコアクライアント API を直接使用しています。
図では、JMS API がクライアント側のシンファサードレイヤーによって実装されていることを確認できます。

第5章 サーバーの使用

この章では、HornetQ サーバーの使用方法について説明します。

5.1. ライブラリーパス

Linux で Asynchronous IO Journal を使用している場合は、Java オプションのプロパティーとして java.library.path を指定する必要があります。これは、run.sh スクリプトで自動的に実行されます。
Java オプションで java.library.path を指定しない場合、JVM は環境変数 LD_LIBRARY_PATH を使用します。

5.2. システムプロパティー

HornetQ では、コマンドラインでロギングを設定するためのシステムプロパティーを指定できます。
ロギングの設定の詳細については、41章ロギング を参照してください。

5.3. 設定ファイル

設定ファイルは、JBoss Enterprise Application Server ディレクトリー構造の複数の場所に格納されます。どのような場合でも、このファイルは、プロファイル間で共有されないため、実行する各サーバープロファイルで変更する必要があります。

/deploy/hornetq/ に格納されたファイル

hornetq-configuration.xml
これは、主要な HornetQ 設定ファイルです。このファイル内のすべてのパラメーターは、付録A 設定リファレンス で説明されています。このファイルの詳細については、「主要な設定ファイル」 を参照してください。

注記

hornetq-configuration.xml 設定のプロパティー file-deployment-enabled (false に設定された場合) は、他の設定ファイルがロードされないことを意味します。デフォルトでは、この値は true に設定されます。
hornetq-jboss-beans.xml
これは、Microcontainer が作成する Bean と Bean 間で適用する依存関係を定義する JBoss Microcontainer Bean ファイルです。
hornetq-jms.xml
デフォルトでは、ディストリビューション設定に、JMS キュー、トピック、および接続ファクトリーをこのファイルから JNDI にデプロイするサーバーサイド JMS サービスが含まれます。JMS を使用してない場合、またはサーバーサイドで JMS オブジェクトをデプロイする必要がない場合は、このファイルは必要ありません。JMS の使用の詳細については、6章JMS の使用 を参照してください。

/conf/props/ に格納されたファイル

hornetq-users.properties
HornetQ には、hornetq-users.properties ファイルからユーザークレデンシャルを取得するセキュリティーマネージャー実装とともに出荷されます。このファイルには、ユーザーおよびパスワード情報が含まれます。セキュリティーの詳細については、29章セキュリティ を参照してください。
hornetq-roles.properties
このファイルには、ユーザーが使用するパーミッションを持つロールとともに hornetq-users.properties で定義されたユーザー名が含まれます。セキュリティーに関する詳細については、29章セキュリティ を参照してください。
値をシステムプロパティーの名前で置き換えることにより、サーバープロファイルのすべての設定ファイルでシステムプロパティー置換を使用することもできます。コネクター設定とともにこの例を以下に示します。
<connector name="netty">
   <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
</factory-class>
   <param key="host" value="${hornetq.remoting.netty.host:localhost}" type="String"/>
   <param key="port"  value="${hornetq.remoting.netty.port:5445}" type="Integer"/>
</connector>
ここでは、2 つの値がシステムプロパティー hornetq.remoting.netty.host および hornetq.remoting.netty.port と置き換えられたことを確認できます。これらの値は、システムプロパティーにある値によって置き換えられます (値が存在する場合)。値が存在しない場合は、デフォルトでそれぞれ localhost または 5445 に設定されます。デフォルト値を提供しないこともできます (つまり、${hornetq.remoting.netty.host})。ただし、この場合は、システムプロパティーを提供する必要があります。

5.4. 主要な設定ファイル

HornetQ コアサーバーの設定は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml に含まれます。これは、メッセージングサーバーを設定するために FileConfiguration Bean によって使用されます。
HornetQ では設定できる属性がたくさんありますが、ほとんどの場合は、基本的な操作を行うのにデフォルト値で十分です。
各属性はデフォルト設定を持ち、単一の空白の <configuration> 要素を持つファイルは有効な設定ファイルになります。デフォルトではない設定については、本マニュアルをとおして説明されます。また、参照スタイル形式のすべての要素にアクセスする場合は、付録A 設定リファレンス を参照してください。

第6章 JMS の使用

HornetQ は JMS 不明メッセージング API を提供しますが、多くのユーザーは JMS をより快適に使用できます。
JMS は非常に人気があるメッセージング用の API 標準であり、ほとんどのメッセージングシステムは JMS API を提供します。
この項では、JMS に対してサーバーを設定し、単純な JMS プログラムを作成する主な手順について説明します。また、JNDI を設定および使用する方法と JNDI を使用せずに HornetQ で JMS を使用する方法についても説明します。

6.1. 単純な注文システム - 設定例

この設定例では、OrderQueue という名前の JMS キューが、そのキューに注文メッセージを送信する単一の MessageProducer とともに使用されます。単一の MessageConsumer は、キューからの注文メッセージを消費します。
このキューは durable に設定されます (サーバーの再起動後やクラッシュ後も保持されます)。
また、この例では、クライアントからキューを明示的に作成せずにキューが自動的に作成されるよう、サーバー JMS 設定でキューを指定する方法についても説明します。

6.1.1. JMS サーバー設定

サーバークラスパスのファイル hornetq-jms.xml (標準設定 JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml 内) には、作成し、JNDI を介してルックアップできる JMS キュー、トピック、および ConnectionFactory インスタンスが含まれます。
JMS ConnectionFactory オブジェクトは、サーバーに対する接続を確立するためにクライアントによって使用されます。このオブジェクトは、接続するサーバーの場所と他の多くの設定パラメーターを認識します。ほとんどの場合は、デフォルト値を使用できます。
この例では、サーバーに単一の JMS キューと単一の JMS 接続ファクトリーインスタンスがデプロイされますが、ファイルからデプロイできるキュー、トピック、および ConnectionFactory インスタンスの数に制限はありません。
<configuration xmlns="urn:hornetq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hornetq ../schemas/hornetq-jms.xsd ">
   <connection-factory name="NettyConnectionFactory">
      <connectors>
         <connector-ref connector-name="netty"/>
      </connectors>
      <entries>
         <entry name="/ConnectionFactory"/>           
      </entries>
   </connection-factory>
   <queue name="OrderQueue">
      <entry name="queues/OrderQueue"/>
   </queue>
</configuration>
ConnectionFactory という名前の接続ファクトリーがデプロイされ、entry 要素で提供されたように JNDI の 1 つの場所でバインドされます。ConnectionFactory インスタンスは JNDI の多くの場所でバインドできます (必要な場合)。

注記

JMS 接続ファクトリーは、netty という名前の connector を参照します。これは、サーバーに実際に接続するために使用されるトランスポートとパラメーターを定義する主要なコア設定ファイル JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml でデプロイされた connector オブジェクトの参照です。

6.1.2. 接続ファクトリータイプ

JMS API doc は、アプリケーション用の複数の接続ファクトリーを提供します。HornetQ JMS ユーザーは、これらの接続ファクトリーに対してタイプを設定するよう選択できます。各接続ファクトリーは signature 属性と xa パラメーターを持ち、これらの組み合わせによってファクトリーのタイプが決定されます。
属性 signature は 3 つの文字列値 (genericqueue、および topic) を持ちます。
xa はブール値タイプのパラメーターです。以下の表は、さまざまな接続ファクトリーインターフェースに対する設定値を示しています。

表6.1 接続ファクトリータイプの設定

signature xa 接続ファクトリータイプ
generic (デフォルト値) false (デフォルト値) javax.jms.ConnectionFactory
generic true javax.jms.XAConnectionFactory
queue false javax.jms.QueueConnectionFactory
queue true javax.jms.XAQueueConnectionFactory
topic false javax.jms.TopicConnectionFactory
topic true javax.jms.XATopicConnectionFactory
以下の例では、XAQueueConnectionFactory が設定されます。
<configuration xmlns="urn:hornetq" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:hornetq ../schemas/hornetq-jms.xsd ">
    
    <connection-factory name="ConnectionFactory" signature="queue">
        <xa>true</xa>
        <connectors>
           <connector-ref connector-name="netty"/>
        </connectors>
        <entries>
            <entry name="/ConnectionFactory"/>           
        </entries>
    </connection-factory>
</configuration>

6.1.3. コード

この例のコードは以下で利用可能です。
最初の手順では JMS オブジェクトをルックアップする JNDI 初期コンテキストを作成します。
InitialContect ic = new InitialContext();
次の手順では、接続ファクトリーをルックアップします。
ConnectionFactory cf = (ConnectionFactory)ic.lookup("/ConnectionFactory");
次に、キューをルックアップします。
Queue orderQueue = (Queue)ic.lookup("/queues/OrderQueue");
次に、接続ファクトリーを使用して JMS 接続を作成します。
Connection connection = cf.createConnection();
AUTO_ACKNOWLEDGE 承認モードで非トランザクション JMS セッションを作成します。
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
キューに注文を送信する MessageProducer を作成します。
MessageProducer producer = session.createProducer(orderQueue);
キューから注文を消費する MessageConsumer を作成します。
MessageConsumer consumer = session.createConsumer(orderQueue);
接続を開始するようにしてください。開始しないと、配信が実行されません。
connection.start();
単純な TextMessage を作成し、送信します。
TextMessage message = session.createTextMessage("This is an order");
producer.send(message);
メッセージを消費します。
TextMessage receivedMessage = (TextMessage)consumer.receive();
System.out.println("Got order: " + receivedMessage.getText());

警告

JMS 接続、セッション、プロデューサー、およびコンシューマーが再使用されるよう設計されます
生成または消費する各メッセージに対して新しい接続、セッション、プロデューサー、およびコンシューマーを作成することは不適切です。これを行うと、アプリケーションのパフォーマンスが大幅に低下します。この詳細については、43章パフォーマンスチューニング を参照してください。

6.2. JNDI を使用せずに直接 JMS リソースをインスタンス化

JNDI から JMS 管理対象オブジェクト (JMS キュー、トピック、および ConnectionFactory インスタンス) をルックアップすることは非常に一般的です。ただし、場合によっては、JNDI サーバーが利用できず、JMS の使用が必要なことがあります。または、オブジェクトを直接インスタンス化することが推奨されます。これは、JMS キュー、トピック、および ConnectionFactory インスタンスの直接インスタンス化をサポートする HornetQ で可能です。
以下に、JNDI をまったく使用しない単純な例を示します。
HornetQJMSClient ユーティリティークラスを使用して JMS ConnectionFactory オブジェクトを作成します。接続パラメーターを提供し、使用するトランスポートを指定する必要があることに注意してください。コネクターの詳細については、14章トランスポートの設定 を参照してください。
TransportConfiguration transportConfiguration =
   new TransportConfiguration(NettyConnectorFactory.class.getName());                
ConnectionFactory cf =
   HornetQJMSClient.createConnectionFactory(transportConfiguration);
また、HornetQJMSClient ユーティリティークラスを使用して JMS キューオブジェクトを作成します。
Queue orderQueue = HornetQJMSClient.createQueue("OrderQueue");
次に、接続ファクトリーを使用して JMS 接続を作成します。
Connection connection = cf.createConnection();
AUTO_ACKNOWLEDGE 承認モードで非トランザクション JMS セッションを作成します。
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
キューに注文を送信する MessageProducer を作成します。
MessageProducer producer = session.createProducer(orderQueue);
キューから注文を消費する MessageConsumer を作成します。
MessageConsumer consumer = session.createConsumer(orderQueue);
接続を開始するようにしてください。開始しないと、配信が実行されません。
connection.start();
単純な TextMessage を作成し、送信します。
TextMessage message = session.createTextMessage("This is an order");
producer.send(message);
メッセージを消費します。
TextMessage receivedMessage = (TextMessage)consumer.receive();
System.out.println("Got order: " + receivedMessage.getText());

6.3. クライアント ID の設定

durable サブスクリプションを作成するには、JMS クライアントのクライアント ID が必要です。これはJBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml の接続ファクトリーで設定し、<client-id> ディレクティブを使用して設定できます。この接続ファクトリーにより作成された接続では、これがクライアント ID として設定されます。

6.4. DUPS_OK に対してバッチサイズを設定

JMS 承認モードが DUPS_OK に設定された場合は、承認を一度に 1 つずつではなくバッチで送信するようコンシューマーを設定し、貴重な帯域幅を節約できます。これは、dups-ok-batch-size 要素を介した接続ファクトリーを使用して設定でき、バイト単位で設定されます。デフォルト値は 1024 * 1024 bytes = 1 MiB (メビバイト) です。

6.5. トランザクションバッチサイズの設定

トランザクションでメッセージを受信する場合は、承認を個別ではなくバッチで送信して貴重な帯域幅を節約できます。これは、 transaction-batch-size 要素を介した接続ファクトリーで設定できます。デフォルト値は 1024 * 1024 (バイト) です。

第7章 コアの使用

HornetQ コアは、独自の非 JMS API を持つ完全な JMS 不明メッセージングシステムです。これは、コア API と呼ばれます。
JMS を使用しない場合は、コア API を直接使用できます。コア API は、JMS のすべての機能を提供します (ただし、複雑さが大幅になくなります)。また、JMS を使用して利用できない機能を提供します。

7.1. コアメッセージングコンセプト

一部のコアメッセージングコンセプトは JMS のコンセプトに似ていますが、異なります。一般的に、コアメッセージング API は JMS API よりも単純です。これは、キュー、トピック、およびサブスクリプションの区別がないためです。これら主要なコアメッセージングコンセプトのそれぞれについて順番に説明します。

7.1.1. メッセージ

  • メッセージは、クライアントとサーバー間で送信されるデータ単位です。
  • メッセージは、データを読み書きする便利なメソッドを含むバッファであるボディを持ちます。
  • メッセージは、キーと値のペアであるプロパティーセットを持ちます。各プロパティーキーは、文字列であり、プロパティー値のデータ型は整数、Long、Short、バイト、バイト[]、文字列、倍精度浮動小数点、浮動小数点、またはブールのいずれかになります。
  • メッセージは送信先のアドレスを持ちます。メッセージはサーバーに到着すると、アドレスにバインドされたキューにルーティングされます。キューがフィルターにバインドされた場合は、フィルターが一致したときにのみ、メッセージがキューにルーティングされます。アドレスには多くのキューをバインドできます (または、アドレスにまったくキューをバインドしないことも可能です)。アドレスにバインドされた迂回のように、キュー以外のエンティティも存在することがあります。
  • メッセージは durable または非 durable のいずれかになります。durable キューの durable メッセージは、サーバーがクラッシュしたり再起動したりした場合は保持されません。
  • メッセージは、0 〜 9 の間の優先度値で指定できます。0 は最低の優先度を表し、9 は最大の優先度を表します。HornetQ は優先度が低いメッセージよりも優先度が高いメッセージを配信しようとします。
  • メッセージは、オプションの失効期限で指定できます。HornetQ は、失効期限後にメッセージを配信しません。
  • メッセージは、メッセージの送信時間を表すオプションのタイムスタンプを持ちます。
  • また、HornetQ は非常に大きいメッセージ (ある時点で利用可能な RAM よりも大幅に大きいメッセージ) の送信または消費をサポートします。

7.1.2. アドレス

サーバーは、アドレスとキューセット間のマッピングを保持します。単一のアドレスには、ゼロ以上のキューをバインドできます。各キューはオプションのメッセージフィルターでバインドできます。メッセージがルーティングされる場合、メッセージはメッセージのアドレスにバインドされたキューのセットにルーティングされます。いずれかのキューがフィルター式でバインドされた場合、メッセージはそのフィルター式に一致するバインドされたキューのサブセットにのみルーティングされます。
迂回などの他のエンティティは、アドレスにもバインドでき、メッセージもルーティングされます。

注記

コアでは、トピックのコンセプトがありません。トピックは JMS 専用の用語です。代わりに、コアでは、アドレスキューを取り扱います。
たとえば、JMS トピックは、多くのキューがバインドされる単一のアドレスによって実装されます。各キューはトピックのサブスクリプションを表します。JMS キューは 1 つのキューがバインドされる単一のアドレスとして実装されます。このキューは JMS キューを表します。

7.1.3. キュー

キューは durable にすることができます。この場合、含まれるメッセージは、durable である限りサーバーのクラッシュや再起動後も保持されます。非 durable キューは、含まれるメッセージが durable の場合であってもサーバーの再起動後やクラッシュ後に保持されません。
また、キューは、一時的である場合もあります。この場合、クライアント接続が閉じられたときに、キューが自動的に削除されます (この前にキューが明示的に削除されていない場合)。
キューは、オプションのフィルター式でバインドできます。フィルター式が提供された場合、サーバーはフィルター式に一致するメッセージのみをアドレスにバインドされたキューにルーティングします。
多くのキューは単一のアドレスにバインドできます。特定のキューは 1 つのアドレスの最大値にのみバインドされます。

7.1.4. ClientSessionFactory

クライアントは ClientSessionFactory インスタンスを使用して ClientSession インスタンスを作成します。ClientSessionFactory インスタンスは、サーバーに接続してセッションを作成する方法を認識し、多くの設定が可能です。
ClientSessionFactory インスタンスは、HornetQClient ファクトリークラスを使用して作成されます。

7.1.5. ClientSession

クライアントは、メッセージを消費および生成し、トランザクションでこれらをグループ化するために ClientSession を使用します。ClientSession インスタンスは、トランザクションセマンティクスと非トランザクションセマンティクスの両方をサポートし、JTA トランザクションの一部としてメッセージング操作を実行できるよう XAResource インターフェースを提供できます。
ClientSession インスタンスは、ClientConsumers と ClientProducers をグループ化します。
ClientSession インスタンスは、オプションんの SendAcknowledgementHandler で登録できます。これにより、送信されたメッセージがサーバーに正常に到着したときにクライアントコードに非動的に通知できます。この機能により、応答を受け取るまで送信された各メッセージに対してブロックせずに、送信されたメッセージがサーバーに到着するようになります。
送信された各メッセージに対するブロックは、送信された各メッセージに対してネットワークラウンドトリップを必要とするため、コストが高くなります。送信承認をブロックしたり、受け取ったりしないことにより、標準的な JMS API を使用できない実際のエンドツーエンド非同期システムを作成できます。この機能の詳細については、18章送信およびコミットの保証 を参照してください。

7.1.6. ClientConsumer

クライアントは、ClientConsumer インスタンスを使用してキューからメッセージを消費します。コアメッセージングは同期および非同期メッセージ消費セマンティクスをサポートします。ClientConsumer インスタンスは、オプションのフィルター式で設定でき、その式に一致するメッセージのみを消費します。

7.1.7. ClientProducer

クライアントは、メッセージを送信できるよう ClientSession インスタンス上で ClientProducer インスタンスを作成します。ClientProducer インスタンスは、送信されたすべてのメッセージがルーティングされるアドレスを使用できます。また、このインスタンスが指定されたアドレスを持たないようにすることもできます。この場合、アドレスはメッセージの送信時に指定されます。

警告

ClientSession、ClientProducer、および ClientConsumer インスタンスは再利用するよう設計されています
生成または消費する各メッセージに対して ClientSession、ClientProducer、および ClientConsumer インスタンスを作成することは適切ではありません。これを行うと、アプリケーションのパフォーマンスが低下します。この詳細については、43章パフォーマンスチューニング で説明されています。

7.2. 単純なコアの例

以下に、メッセージを送受信するためにコアメッセージング API を使用する非常に単純なプログラムを示します。
ClientSessionFactory factory =  HornetQClient.createClientSessionFactory(
                                        new TransportConfiguration(
                                           InVMConnectorFactory.class.getName()));

ClientSession session = factory.createSession();

session.createQueue("example", "example", true);

ClientProducer producer = session.createProducer("example");

ClientMessage message = session.createMessage(true);

message.getBodyBuffer().writeString("Hello");

producer.send(message);

session.start();

ClientConsumer consumer = session.createConsumer("example");

ClientMessage msgReceived = consumer.receive();

System.out.println("message = " + msgReceived.getBodyBuffer().readString());

session.close();

第8章 JMS コンセプトとコア API のマッピング

本章では、JMS 宛先と HornetQ アドレスのマッピング方法について説明します。
HornetQ コアは JMS が不明です。これは、JMS トピックのコンセプトを持ちません。JMS トピックは、コアでゼロ以上のキューがバインドされたアドレス (トピック名) として実装されます。このアドレスにバインドされた各キューはトピックサブスクリプションを表します。同様に、JMS キューは、JMS キューを表す、単一のキューがバインドされたアドレス (JMS キュー名) として実装されます。
通常、すべての JMS キューは、コアキュー名の前に文字列 jms.queue. が付加されたコアキューに対してマッピングされます。たとえば、名前が "orders.europe" の JMS キューは、名前が "jms.queue.orders.europe" のコアキューに対してマッピングされます。また、コアキューがバインドされたアドレスがコアキュー名で提供されます。
JMS トピックの場合、サブスクリプションを表すキューがバインドされたアドレスは、文字列 "jms.topic." を JMS トピックの名前の前に付加することにより提供されます。たとえば、名前が "news.europe" の JMS トピックは、コアアドレス "jms.topic.news.europe" に対してマッピングされます。
たとえば、JMS メッセージを名前が "orders.europe" の JMS キューに送信する場合、メッセージはサーバーで、アドレス "jms.queue.orders.europe" にバインドされたコアキューにルーティングされます。JMS メッセージを名前が "news.europe" の JMS トピックに送信する場合、メッセージはサーバーで、アドレス "jms.topic.news.europe" にバインドされたコアキューにルーティングされます。
名前が "orders.europe" の JMS キューの設定を行う場合は、対応するコアキュー "jms.queue.orders.europe" を設定する必要があります。
<!-- expired messages in JMS Queue "orders.europe"
    will be sent to the JMS Queue "expiry.europe" -->
<address-setting match="jms.queue.orders.europe">
   <expiry-address>jms.queue.expiry.europe</expiry-address>
   ...
</address-setting>

第9章 クライアントクラスパス

HornetQ では、複数の jar をクライアントクラスパスで指定する必要があります (クライアントが HornetQ コア API、JMS、または JNDI を使用するかによって異なります)。

警告

ここで示されたすべての jar は、HornetQ ディストリビューションの $JBOSS_HOME/client ディレクトリ内に存在します。jar は正しいリリースのバージョンからのみ使用してください。異なる HornetQ バージョンの jar バージョンを混在させないでください。異なる jar バージョンを混在させると、エラーが発生することがあります。

9.1. HornetQ コアクライアント

純粋な HornetQ コアクライアント (たとえば、JMS 以外) を使用している場合は、クライアントクラスパスで hornetq-core-client.jarnetty.jar を指定する必要があります。

9.2. JMS クライアント

クライアント側で JMS を使用している場合は、hornetq-jms-client.jarjboss-javaee.jar も含める必要があります。

注記

jboss-javaee.jar には、javax.jms.* クラスに必要な Java EE API インターフェースクラスのみが含まれます。クラスパスにこれらのインターフェースクラスを持つ jar がすでに指定されている場合は、必要ありません。

9.3. JNDI を使用した JMS クライアント

JMS リソースを JNDI サーバーからルックアップする場合は、クライアントクラスパス上の jar jnp-client.jar と以前に示された他の jar も必要です。

第10章 ワイルドカードを使用してメッセージをルーティング

HornetQ では、ワイルドカードアドレスを使用してメッセージをルーティングできます。
キューが queue.news.# などのアドレスで作成された場合、キューはこれに一致するアドレスに送信されたすべてのメッセージを受け取ります。この例としては、queue.news.europequeue.news.usaqueue.news.usa.sport などがあります。このキューでコンシューマーを作成した場合、コンシューマーはアドレスの階層に送信されたメッセージを消費できます。

注記

JMS の用語では、「トピック階層」を作成できます。
この機能を有効にするには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルのプロパティー wild-card-routing-enabledtrue に設定します。この場合、デフォルト値は true です。
ワイルドカード構文の詳細については、章 11章HornetQ ワイルドカード構文について を参照してください。

第11章 HornetQ ワイルドカード構文について

HornetQ は、セキュリティー設定とアドレス設定で、およびコンシューマーの作成時にワイルドカードを表す固有の構文を使用します。
HornetQ ワイルドカード表現には、文字 '.' (ピリオド) で区切られた単語が含まれます。
また、特殊文字 '#' と '*' は特別な意味を持ち、単語の代わりになることがあります。
文字 '#' は、「任意の順序のゼロ以上の単語に一致する」ことを意味します。
文字 '*' は、「単一の単語に一致する」ことを意味します。
したがって、ワイルドカード 'news.europe.#' は、'news.europe'、'news.europe.sport'、'news.europe.politics'、および 'news.europe.politics.regional' に一致しますが、'news.usa'、'news.usa.sport'、または 'entertainment' に一致しません。
ワイルドカード 'news.*' は 'news.europe' に一致しますが、'news.europe.sport' に一致しません。
ワイルドカード 'news.*.sport' は 'news.europe.sport' と 'news.usa.sport' に一致しますが、'news.europe.politics' に一致しません。

第12章 フィルター表現

HornetQ では、SQL 92 表現構文のサブセットに基づいた強力なフィルター言語が提供されます。
これは、JMS セレクターで使用される構文と同じですが、事前定義 ID が異なります。
フィルター表現は、HornetQ の複数の場所で使用されます。
  • 事前定義されたキュー。キューを JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml または JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で事前定義する場合、キューに対してフィルター表現を定義できます。フィルター表現に一致するメッセージのみがキューに格納されます。
  • コアブリッジは、オプションのフィルター表現で定義でき、一致するメッセージのみがブリッジで送信されます (34章コアブリッジ を参照)。
  • 迂回は、オプションのフィルター表現で定義でき、一致するメッセージのみが迂回されます (33章メッセージフローの迂回と分割 を参照)。
  • また、28章管理 で説明されたように、フィルターは、複数の場所でコンシューマー、キューを作成するときにプログラムで使用されます。
JMS セレクター表現と HornetQ コアフィルター表現間にはいくつかの違いがあります。JMS セレクター表現が JMS メッセージで動作する一方で、HornetQ コアフィルター表現はコアメッセージで動作します。
コアフィルター表現で以下の ID を使用して、表現のコアメッセージの属性を参照できます。
HQPriority
メッセージの優先度を参照します。メッセージの優先度は0 〜 9 の有効な整数値です。0 は最小の優先度であり、9 は最大の優先度です。たとえば、HQPriority = 3 and department = 'payroll' のようになります。これは、優先度が 3 であり、部門が 'payroll' のメッセージを参照します。
HQExpiration
メッセージの期限切れ時間を参照します。値は Long 型の整数値です。
HQDurable
メッセージが耐性であるかどうかを参照します。値は有効な値 DURABLE または NON_DURABLE を持つ文字列です。
HQTimestamp
メッセージが作成されたタイムスタンプ。値は Long 型の整数値です。
HQSize
メッセージのサイズ (バイト単位)。値は整数です。
コアフィルター表現で使用された他の IDは、メッセージのプロパティーと見なされます。

第13章 永続化

本章では、HornetQ での永続化と設定について説明します。
HornetQ は独自の永続化を処理します。これは、高パフォーマンスのジャーナルとともに出荷され、メッセージング固有の使用ケースに対して最適化されます。
HornetQ journal はファイルサイズを設定できる append only であり、単一の書き込み操作を有効にすることによりパフォーマンスが向上します。これは、ディスク上のファイルセットから構成され、最初に固定サイズで事前に作成され、パディングで満たされます。サーバー操作 (メッセージの追加、メッセージの削除、メッセージの更新など) が実行されると、ジャーナルファイルがいっぱいになるまで (この時点で次のジャーナルファイルが使用されます) 操作のレコードがジャーナルに追加されます。
高度なガーベッジコレクションアルゴリズムにより、すべてのデーが削除されたときにジャーナルファイルを再構築および再利用できるかどうかが決定されます。圧縮アルゴリズムにより、デッドスペースがジャーナルファイルから削除され、データが圧縮されます。
また、このジャーナルはローカルトランザクションおよび XA トランザクションの両方を完全にサポートします。
ジャーナルの大部分は Java で記述されていますが、さまざまな接続可能な実装を許可するためにファイルシステムとの統合は抽象化されています。HornetQ に同梱される 2 つの実装は以下のとおりです。
Java 非ブロック IO (NIO)
ファイルシステムと接続するために標準的な Java NIO を使用します。これにより、パフォーマンスが大幅に向上し、Java 6 以降のランタイムがあるプラットフォームで実行が可能になります。
Linux 非同期 IO (AIO)
Linux 非同期 IO ライブラリー (AIO) と対話するには、ネイティブコードラッパーを使用します。AIO では、データが永続化されたときに HornetQ がメッセージを受け取ります。これにより、明示的な同期の必要がなくなります。一般的に、AIO は Java NIO よりも高いパフォーマンスを提供しますが、Linux カーネル 2.6 以降と libaio が必要になります。
また、AIO は ext2ext3ext4jfs、または xfs タイプファイルシステムを必要とします。NFS では、AIO は低速で同期の動作になります。

注記

Red Hat Enterprise Linux の場合は、libaio を以下のコマンドでインストールします。
yum install libaio
標準的な HornetQ コアサーバーは、以下のジャーナルインスタンスを使用します。
バインディングジャーナル
サーバーにデプロイされたキューと属性のセットを含むバインディング関連のデータを格納します。また、ID シーケンスカウンターなどのデータも格納します。バインディングジャーナルは常に NIO ジャーナルであり、通常は、メッセージジャーナルと比較して低いスループットを持ちます。
このジャーナル上のファイルは、接頭辞 hornetq-bindings で設定されます。各ファイルは bindings 拡張を持ちます。ファイルサイズは 1048576 バイトであり、ファイルはバインディングフォルダーにあります。
JMS ジャーナル
JMS キュー、トピック、接続ファクトリーなどのすべての JMS 関連のデータと、これらのリソースに対する JNDI バインディングを格納します。管理 API で作成されたすべての JMS リソースはこのジャーナルに永続化されます。設定ファイルで設定されたすべてのリソースはこのジャーナルに永続化されません。このジャーナルは、JMS が使用中の場合のみ作成されます。
メッセージジャーナル
メッセージ自体と duplicate-id キャッシュを含むすべてのメッセージ関連のデータを格納します。デフォルトでは、HornetQ はこのジャーナルに AIO を使用します。AIO が利用不可の場合は、自動的にNIO が使用されます。
大きなメッセージは、メッセージジャーナル外部で永続化されます。詳細については、21章大きなメッセージ を参照してください。
低メモリーの状況では、HornetQ がメッセージをディスクにページングするよう設定します。詳細については、22章ページング を参照してください。
永続化が必要ない場合は、「HornetQ でのゼロ永続化の設定」 で説明されたように、HornetQ がデータを永続化しないよう設定できます。

13.1. バインディングジャーナルの設定

バインディングジャーナルは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml の以下の属性を使用して設定されます。
bindings-directory
バインディングジャーナルの場所。デフォルト値は data/bindings です。
create-bindings-dir
true であり、バインディングディレクトリが存在しない場合は、bindings-directory で指定された場所でバインディングディレクトリが自動的に作成されます。デフォルト値は true です。

13.2. JMS ジャーナルの設定

JMS ジャーナルは、バインディングジャーナルと設定を共有します。

13.3. メッセージジャーナルの設定

メッセージジャーナルは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml の以下の属性を使用して設定されます。
journal-directory
メッセージジャーナルの場所。デフォルト値は data/journal です。パフォーマンスを最大にするために、このジャーナルを独自の物理ボリュームに置いて、ディスクヘッドの移動を最小化する必要があります。このジャーナルがストレージエリアネットワークに保存された場合は、ネットワークの各ジャーナルインスタンスが独自の論理単位を持つ必要があります。
create-journal-dir
true の場合は、ジャーナルディレクトリが、journal-directory で指定された場所で作成されます。デフォルト値は true です。
journal-type
有効な値は NIO または ASYNCIO です。NIO の場合は、Java NIO ジャーナルが使用されます。ASYNCIO の場合は、Linux 非同期 IO が使用されます。ASYNCIO が非 Linux または非 libaio システムで設定されている場合は、HornetQ がこれを検出し、NIO を使用します。
journal-sync-transactional
true の場合、HornetQ では、すべてのトランザクションデータがトランザクション境界 (コミット、準備、およびロールバック) でディスクにフラッシュされます。デフォルト値は true です。
journal-sync-non-transactional
true の場合、HornetQ では、非トランザクションメッセージデータ (送信および承認) がディスクにフラッシュされます。デフォルト値は true です。
journal-file-size
各ジャーナルファイルのサイズ (バイト単位)。デフォルト値は 10485760 バイト (10 メガバイト) です。
journal-min-files
ジャーナルが保持するファイルの最小数。HornetQ が起動され、初期データがない場合、HornetQ はこの数のファイルを事前に作成します。ジャーナルファイルの作成とパディングはコストがかかる操作であるため、実行時に回避されます (ファイルが満たされます)。ファイルを事前に作成する場合、ファイルが満たされると、ジャーナルがすぐに次のファイルで続行されます (ファイルを作成するために一時停止しません)。
journal-max-io
IO キューに保持する書き込み要求の最大数。書き込み要求は、実行のためにシステムに送信される前にここでキューに格納されます。キューがいっぱいになると、キューでスペースが利用可能になるまで書き込みがブロックされます。NIO の場合、これは 1 である必要があります。AIO の場合、これは 500 である必要があります。NIO が使用されているか、AIO が使用されているかに応じて異なるデフォルト値が保持されます (NIO の場合は 1、AIO の場合は 500)。AIO の最大値はオペレーティングシステムレベル (/proc/sys/fs/aio-max-nr) で設定された値 (通常は 65536) よりも大きくしてはいけません。
journal-buffer-timeout
HornetQ はフラッシュ要求のバッファーを保持し、バッファーがいっぱいになったとき、またはこのタイムアウトが経過したとき (どちらか早い方) にバッファー全体をフラッシュします。これは、NIO と AIO の両方に使用され、多くの同時書き込みとフラッシュが必要な場合にスケーリングが向上します。
journal-buffer-size
AIO でタイムアウトになったバッファーのサイズ。デフォルト値は 490 キロバイトです。
journal-compact-min-files
ジャーナルが圧縮される前のファイルの最小数。デフォルト値は 10 です。
journal-compact-percentage
ジャーナルのこの割合以下がライブデータと見なされた場合は、圧縮が行われます。デフォルト値は 30 です。また、圧縮前に journal-compact-min-files を満たす必要があります。

警告

ほとんどのディスクには、ハードウェア書き込みキャッシュが含まれます。これにより、書き込みがキャッシュされ、後でレイジー状態でディスクに書き込まれるため、ディスクのパフォーマンスが向上します。
多くのシステムでは、ディスク書き込みキャッシュがデフォルトで有効です。したがって、オペレーティングシステムから同期した後であっても、データがディスクに書き込まれる保証はありません。障害が発生した場合は、重要なデータが失われることがあります。
一部のシステムは、非揮発性、またはバッテリー駆動の書き込みキャッシュを持ちます。これらを使用した場合は、障害発生時にデータが必ずしも失われるわけではありませんが、テストが重要になります。
ディスクがこれらのバックアップを備えておらず、冗長アレイ (RAID など) の一部でない場合は、ディスク書き込みキャッシュが disabled になっていることを確認してください。これにより、パフォーマンスが低下することがありますが、データの整合性は保持されます。
Linux の場合は、IDE ディスク用の hdparm ツール、sdparm、あるいは SCSI または SATA ディスク用の sginfo ツールでディスクの書き込みキャッシュ設定を検査または変更します。
Windows の場合は、ディスクを右クリックし、[プロパティ] を選択して設定を確認または変更します。

13.4. HornetQ でのゼロ永続化の設定

HornetQ でゼロ永続化を実行するよう設定するには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlpersistence-enabled パラメーターを false に設定します。

重要

このパラメーターが false に設定された場合、永続化は実行されません。バインディングデータ、メッセージデータ、大きなメッセージデータ、重複 ID キャッシュ、またはページングデータは永続化されません。

13.5. ジャーナルデータのインポート/エクスポート

HornetQ で使用される各ジャーナルの既存のレコードを検査し、このためにエクスポート/インポートツールを使用できます。エクスポート/インポートは hornetq-core.jar に存在するクラスであり、以下のコマンドを使用してジャーナルをテキストファイルとしてエクスポートできます。
java -cp hornetq-core.jar org.hornetq.core.journal.impl.ExportJournal <JournalDirectory> <JournalPrefix> <FileExtension> <FileSize> <FileOutput>
ジャーナルでファイルをバイナリーデータとしてインポートする場合 (netty.jar も必要であることに注意してください):
java -cp hornetq-core.jar:netty.jar org.hornetq.core.journal.impl.ImportJournal <JournalDirectory> <JournalPrefix> <FileExtension> <FileSize> <FileInput>
  • JournalDirectory: 選択されたフォルダーに対して設定されたフォルダーを使用します。例: ./hornetq/data/journal
  • JournalPrefix: 説明されたように、選択されたジャーナルに対して接頭辞を使用します。
  • FileExtension: 説明されたように、選択されたジャーナルに対して拡張子を使用します。
  • FileSize: 説明されたように、選択されたジャーナルに対してサイズを使用します。
  • FileOutput: エクスポートされたデータを含むテキストファイル

第14章 トランスポートの設定

HornetQ は完全に接続可能で柔軟性が高いトランスポートレイヤーを持ちます。トランスポートレイヤーは独自の Service Provider Interface (SPI) を定義して新しいトランスポートプロバイダーでの接続を単純化します。
この章では、HornetQ トランスポートを使用および設定するのに必要なコンセプトについて説明します。

14.1. アクセプターについて

アクセプターは、以下のディレクティブを使用して JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されます。
<acceptor name="netty">
   <factory-class>
org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class>
   <param key="host"  value="${jboss.bind.address:localhost}"/>
   <param key="port"  value="${hornetq.remoting.netty.port:5445}"/>
</acceptor>
アクセプターは、常に acceptors 要素の内部で定義されます。複数のアクセプターを 1 つの acceptors 要素で定義できます。1 つのサーバーに対するアクセプターの数に上限はありません。
各アクセプターは HornetQ サーバーに対する接続を確立できる方法を定義します。
上記の例は、ポート 5446 で接続をリッスンするために Netty を使用する acceptor を定義します。
acceptor 要素には、アクセプターインスタンスを作成するために使用されるファクトリーを定義するサブ要素 factory-class が含まれます。この場合、Netty は、接続をリッスンするために使用されるため、AcceptorFactory の Netty 実装が使用されます。factory-class 要素は、どの接続可能なトランスポートをリッスンするかを決定します。
acceptor 要素は、ゼロ以上の param サブ要素で設定することもできます。各 param 要素はキーと値のペアを定義します。これらのキーと値のペアは、特定のトランスポートを設定するために使用され、有効なキーと値のペアセットは使用される特定のトランスポートに依存し、基礎となるトランスポートに直接渡されます。
特定のトランスポートに対するキーと値のペアの例は、バインドする IP アドレスまたはリッスンするポートを設定することです。

14.2. コネクターについて

コネクターを受け入れる方法を定義するためにサーバーでアクセプターが使用される場合、コネクターはサーバーに接続する方法を定義するためにクライアントによって使用されます。アクセプターとコネクターは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルで定義されます。
<connector name="netty">
  <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>
  <param key="host" value="${jboss.bind.address:localhost}"/>
  <param key="port" value="${hornetq.remoting.netty.port:5445}"/>
</connector>
コネクターは <connectors> 要素の内部で定義できます。複数のコネクターは同じ <connectors> 要素で定義できます。1 つのサーバーに対するコネクターの数に上限はありません。
コネクターはクライアントによって使用されますが、複数の理由からサーバーで定義されます。
  • 場合によっては、サーバーは別のサーバーへの接続時 (あるサーバーが別のサーバーにブリッジ接続される場合やサーバーがクラスターに参加する場合) にクライアントとして動作します。この場合、サーバーは他のサーバーに接続する方法を認識する必要があります。これは、コネクターによって定義されます。
  • JMS とサーバーサイド JMS サービスが JMS ConnectionFactory インスタンスをインスタンス化し、JNDI でバインドするために使用される場合、JMS サービスは HornetQConnectionFactory が接続ファクトリーの接続時に接続を作成するサーバーを認識する必要があります。
    これは、サーバーサイドの JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml ファイルの <connector-ref> 要素により定義されます。hornetq-jms.xml ファイルの以下のコード例は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルで定義された netty コネクターを参照する JMS 接続ファクトリーを示しています。
    <connection-factory name="NettyConnectionFactory">
        <connectors>
           <connector-ref connector-name="netty"/>
        </connectors>
        <entries>
            <entry name="/ConnectionFactory"/>
            <entry name="/XAConnectionFactory"/>
        </entries>
    </connection-factory>

14.3. クライアントサイドから直接トランスポートを設定

この節では、サーバーと接続するコア ClientSessionFactory を設定する方法を示します。
コネクターは、サーバーと対話するコア ClientSessionFactory を設定するときに間接的に使用されます。この場合、サーバーサイド設定でコネクターを定義することは必要ありません。代わりに、パラメーターを作成し、ClientSessionFactory で使用されるコネクターファクトリーを設定します。
以下の ClientSessionFactory は、この章で以前に定義したアクセプターに直接接続します。これは、標準的な Netty TCP トランスポートを使用し、ポート 5446 で localhost (デフォルト値) に接続しようとします。
Map<String, Object> connectionParams = 
  new HashMap<String, Object>();
    
  connectionParams.put(
    org.hornetq.core.remoting.impl.netty.TransportConstants.PORT_PROP_NAME, 
    5446
  );

TransportConfiguration transportConfiguration = 
  new TransportConfiguration(
    "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory", 
    connectionParams
  );

ClientSessionFactory sessionFactory = 
  HornetQClient.createClientSessionFactory(transportConfiguration);

ClientSession session = sessionFactory.createSession(...);
JMS の場合は、サーバーサイドでコネクターを定義せずに、または JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で接続ファクトリーを定義せずに、クライアントサイドで直接 JMS 接続を設定できます。
Map<String, Object> connectionParams = 
  new HashMap<String, Object>();

connectionParams.put(
  org.hornetq.core.remoting.impl.netty.TransportConstants.PORT_PROP_NAME, 
  5446
);

TransportConfiguration transportConfiguration = 
  new TransportConfiguration(
    "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory", 
    connectionParams
  );

ConnectionFactory connectionFactory = 
  HornetQJMSClient.createConnectionFactory(transportConfiguration);

Connection jmsConnection = connectionFactory.createConnection();

14.4. Netty トランスポートの設定

HornetQ は、Netty の高パフォーマンスで低レベルのネットワークライブラリを使用します。
Netty トランスポートは、古い (ブロッキング) Java IO、NIO (非ブロッキング)、TCP ソケット、SSL、HTTP、または HTTPS を使用するよう設定できます。サーブレットトランスポートも提供されます。

14.4.1. Netty TCP の設定

Netty TCP は、単純な暗号化されていない TCP ソケットベースのトランスポートです。Netty TCP は、ブロッキング Java Asynchronous IO (AIO) または非ブロッキング Java NIO (NIO) を使用するよう設定できます。NIO は、サーバーサイドの同時接続に対して推奨されます。ただし、多くの同時接続が必要でない場合、AIO は優れたレイテンシーを提供できます。

警告

信頼できないネットワークで接続を実行している場合は、代わりに SSL または HTTPS を検討してください。

重要

非ブロッキングメッセージが送信された場合は、これらのメッセージが、呼び出し側スレッドが完了した後にサーバーに到着することがあります。つまり、セキュリティーコンテキストが削除されています。この場合は、メッセージをブロッキングメッセージとして送信する必要があります。
Netty TCP トランスポートでは、すべての接続はクライアントサイドから開始されます。これは、ファイアウォールポリシーで接続を 1 方向にのみ開始することが許可されている場合に役に立ちます。
すべての有効な Netty トランスポートキーはorg.hornetq.core.remoting.impl.netty.TransportConstants で定義されます。アクセプターとコネクターでは、ほとんどのパラメーターを使用できます。一部はアクセプターでのみ動作します。単純な TCP のために Netty を設定するために、以下のパラメーターを使用できます。
use-nio
true の場合は、NIO が使用されます。false の場合は、AIO が使用されます。デフォルト値はクライアントサイドとサーバーサイドの両方で false です。サーバーが多くの同時接続を処理する必要がある場合は、NIO が推奨されます。これは、1 つの接続ごとに 1 つのスレッドが保持され、AIO よりも多くの同時接続にスケーリングできるためです。サーバーが多くの同時接続を処理する必要がない場合、AIO は優れたパフォーマンスを提供できます。
host
接続する (コネクターの場合) またはリッスンする (アクセプターの場合) ホスト名または IP アドレス。デフォルト値は localhost です。

重要

この変数のデフォルト値は localhost です。これは、リモートノードからアクセスできず、サーバーが受信接続を受け入れるよう変更する必要があります。
アクセプターは、複数のカンマ区切りのホストまたは IP アドレスで設定できます。コネクターに対して複数のアドレスは有効ではありません。0.0.0.0 の場合は、ホストのすべてのネットワークインターフェースが受け入れられます。
port
接続する (コネクターの場合) またはリッスンする (アクセプターの場合) ポートを指定します。デフォルト値は 5445 です。
tcp-no-delay
true の場合、Nagle のアルゴリズムが有効になります。デフォルト値は true です。
tcp-send-buffer-size
TCP 送信バッファーのサイズを定義します (バイト単位)。デフォルト値は32768 (32 キロバイト) です。TCP バッファーサイズはネットワークの帯域幅とレイテンシーに応じて調整する必要があります。バイト単位のバッファーサイズは 1 秒あたりのバイト数に秒単位の Network Round-Trip-Time (RTT) を掛けた数の帯域幅と等しくなる必要があります。RTT は、ping ユーティリティーを使用して測定できます。高速なネットワークが必要な場合は、デフォルト値からバッファーサイズを増やすことができます。
tcp-receive-buffer-size
TCP 受信バッファーのサイズを定義します (バイト単位)。デフォルト値は 32768 (32 キロバイト) です。
batch-delay
HornetQ は、書き込み操作をバッチに最大 batch-delay ミリ秒格納するよう設定できます。これにより、非常に小さいメッセージの場合に全体のスループットが向上しますが、メッセージ転送の平均レイテンシーが大きくなります。デフォルト値は 0 ミリ秒です。
direct-deliver
メッセージがサーバに到着し、コンシューマーに配信されると、デフォルトで、メッセージが到着した異なるスレッドで配信が行われます。これにより、全体のスループットが最大になり、スケーラビリティーが提供されます (特にマルチコアマシンにおいて)。ただし、必要なコンテキストスイッチのため、レイテンシーが追加されます。レイテンシーを小さくするには (この場合、スループットが小さくなることがあります)、direct-delivertrue (デフォルト値) に設定します。スループットを最大にするには、false に設定します。
nio-remoting-threads
NIO を使用するよう設定された場合、デフォルトで HornetQ は、Runtime.getRuntime().availableProcessors() により報告されたコア (またはハイパースレッド) としてスレッドの数の 3 倍の数を使用して受信パケットを処理します。nio-remoting-threads はこれを上書きし、使用するスレッドの数を定義します。デフォルト値は -1 であり、Runtime.getRuntime().availableProcessors() の値の 3 倍の数を表します。

14.4.2. Netty SSL の設定

Netty SSL は、Netty TCP トランスポートに似ていますが、Secure Sockets Layer (SSL) を使用して TCP 接続を暗号化することによって追加のセキュリティーを提供します。
Netty SSL は、以下のプロパティ以外に、Netty TCP と同じプロパティを使用します。
ssl-enabled
true に設定して SSL を有効にします。
key-store-path
クライアント証明書を保持するクライアントで SSL キーストアへのパスを定義します。
key-store-password
クライアントでクライアント証明書キーストアのパスを定義します。
trust-store-path
信頼できるクライアント証明書ストアへのパスをサーバーで定義します。
trust-store-password
信頼できるクライアント証明書ストアのパスワードをサーバーで定義します。

14.4.3. Netty HTTP の設定

HTTP プロトコルを介した Netty HTTP トンネルパケット。ファイアウォールで HTTP トラフィックのみを渡すことが許可されている場合に役に立ちます。
Netty HTTP は、Netty TCP と同じプロパティを使用しますが、以下のプロパティを追加します。
http-enabled
true に設定して HTTP を有効にします。
http-client-idle-time
空の HTTP 要求を送信して接続を存続させる前にクライアントをアイドル状態にできる時間 (ミリ秒単位)。
http-client-idle-scan-period
アイドル状態のクライアントをスキャンする頻度 (ミリ秒単位)。
http-response-time
空の HTTP 要求を送信して接続を存続させるまでサーバーが待機する時間 (ミリ秒単位)。
http-server-scan-period
応答が必要なクライアントをスキャンする頻度 (ミリ秒単位)。
http-requires-session-id
true の場合、クライアントは最初のコール後にセッション ID を受け取るまで待機します。これは、HTTP コネクターがサーブレットアクセプターに接続するときに使用されます (推奨されません)。

14.4.4. Netty サーブレットの設定

Netty サーブレットトランスポートでは、HornetQ トラフィックを HTTP を介してサーブレットエンジンで実行されているサーブレットにトンネリングできます (トラフィックは仮想マシン HornetQ サーバーにリダイレクトされます)。
これは、トラフィックが Web アプリケーションを提供している可能性があるサーブレットエンジンを介してルーティングされるため、Netty HTTP トランスポートとは異なります。これにより、企業ポリシーで、単一の Web サーバーが HTTP ポートでリッスンできる場合に、HornetQ を使用できます。

Netty サーバートランスポートのためにサーブレットエンジンを設定

  1. サーブレットをデプロイします。サーブレットを使用する Web アプリケーションは以下のような web.xml ファイルを持つことがあります。
    <?xml version="1.0" encoding="UTF-8"?>
    <web-app xmlns="http://java.sun.com/xml/ns/j2ee" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
      version="2.4">
      <servlet>
        <servlet-name>HornetQServlet</servlet-name>
        <servlet-class>org.jboss.netty.channel.socket.http.HttpTunnelingServlet</servlet-class>
        <init-param>
          <param-name>endpoint</param-name>
          <param-value>local:org.hornetq</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
      </servlet>
    
      <servlet-mapping>
        <servlet-name>HornetQServlet</servlet-name>
        <url-pattern>/HornetQServlet</url-pattern>
      </servlet-mapping>
    </web-app>
  2. netty-invm アクセプターを JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のサーバーサイド設定に追加します。
    <acceptors>
      <acceptor name="netty-invm">
        <factory-class>
          org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory
        </factory-class>
        <param key="use-invm" value="true"/>
        <param key="host" value="org.hornetq"/>
      </acceptor>
    </acceptors>
  3. クライアントのコネクターを JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義します。
    <connectors>
      <connector name="netty-servlet">
        <factory-class>
          org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
        </factory-class>
        <param key="host" value="localhost"/>
        <param key="port" value="8080"/>
        <param key="use-servlet" value="true"/>
        <param key="servlet-path" value="/messaging/HornetQServlet"/>
      </connector>
    </connectors>

初期パラメーター

endpoint
サーブレットがパケットを転送する netty アクセプターを定義します。host パラメーターの名前を照合します。
web.xml で設定されたサーブレットパターンは使用される URL のパスです。コネクター設定のコネクターパラメーター servlet-path は、Web アプリケーション (存在する場合) のアプリケーションコンテキストを使用してこれに照合する必要があります。
また、以下の設定をコネクターに追加することにより、SSL を介してサーブレットトランスポートを使用することもできます。
<connector name="netty-servlet">
  <factory-class>
    org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
  </factory-class>
  <param key="host" value="localhost"/>
  <param key="port" value="8443"/>
  <param key="use-servlet" value="true"/>
  <param key="servlet-path" value="/messaging/HornetQServlet"/>
  <param key="ssl-enabled" value="true"/>
  <param key="key-store-path" value="path to a keystore"/>
  <param key="key-store-password" value="keystore password"/>
</connector>
キーストアを使用するためにアプリケーションサーバーを設定する必要もあります。以下のように、SSL/TLS コネクター設定を server/default/deploy/jbossweb.sar/server.xml で編集します。
<Connector protocol="HTTP/1.1" SSLEnabled="true"
  port="8443" address="${jboss.bind.address}"
  scheme="https" secure="true" clientAuth="false"
  keystoreFile="path to a keystore"
  keystorePass="keystore password" sslProtocol = "TLS" />
両方のケースでは、キーストアとパスワードを提供する必要があります。詳細については、HornetQ に同梱された Servlet SSL の例を参照してください。

第15章 使用済みの接続の検出

この章では、接続 Time-to-Live (TTL) について説明し、HornetQ が、クラッシュしたクライアントおよび終了したクライアントをリソースを正常にクローズせずにどのように扱うかについても説明します。

15.1. サーバーで使用済みの接続リソースをクリーンアップ

HornetQ クライアントアプリケーションが終了する前に、そのリソースをfinally ブロックを使用してクローズする必要があります。

例15.1 正常に動作するコアクライアントアプリケーション

以下に、セッションとセッションファクトリーを finally ブロックでクローズする、正常に動作するコアクライアントアプリケーションの例を示します。
ClientSessionFactory sf = null;
ClientSession session = null;

try
{
   sf = HornetQClient.createClientSessionFactory(...);
   session = sf.createSession(...);   
   ... do some stuff with the session...
}
finally
{
   if (session != null)
   {
      session.close();
   }
   
   if (sf != null)
   {
      sf.close();
   }
}

例15.2 正常に動作する JMS クライアントアプリケーション

これは、正常に動作する JMS クライアントアプリケーションの例です。
Connection jmsConnection = null;

try
{
   ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactory(...);

   jmsConnection = jmsConnectionFactory.createConnection();

   ... do some stuff with the connection...
}
finally
{
   if (connection != null)
   {
      connection.close();
   }
}
クライアントがクラッシュすると、セッションのようなサーバーサイドリソースはサーバーに残ったままになることがあります。これにより、時間が経つとリソースリークが発生し、サーバーでメモリーや他のリソースが足りなくなることがあります。
残ったクライアントリソースをクリーンアップする要件は HornetQ クライアント接続サポートで満たされます。クライアントとサーバー間のネットワークは失敗し、リブートされることがあり、クライアントは再接続できます。リソースが消去された場合は、リブートが失敗します。
リソースがクライアントのクラッシュ時に消去されるようにするために (リブート時間の間は許可)、connection TTL は設定可能です。各 ClientSessionFactory は定義された connection TTL を持ちます。TTL は、クライアントから到着するデータが存在しない場合に、サーバーがe接続を保持する時間を決定します。
クライアントは、サーバーがクローズしないよう ping パケットを自動的に送信します。サーバーが接続 TTL 時間の間、接続でパケットを受け取らない場合は、その接続に関連するすべてのセッションがサーバーでクローズされます。
この機能は以下の方法で、クライアントサイドまたはサーバーサイドで設定できます。
  • クライアントサイドで、HornetQConnectionFactory インスタンス (JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar/META-INF/ra.xml) の ConnectionTTL 属性を指定します。
  • 接続ファクトリーインスタンスが JNDI に直接デプロイされるサーバーサイドで、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml ファイルの <connection-factory> ディレクティブに対して connection-ttl パラメーターを指定します。
ConnectionTTL のデフォルト値は 60000 (ミリ秒) です。ConnectionTTL 属性の値が -1 の場合は、サーバーサイドでサーバーの接続がタイムアウトしません。
クライアントで独自の接続 TTL を指定することを回避するために、他のすべての値を上書きするグローバル値をサーバーサイドで設定できます。これを行うには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml ファイルで connection-ttl-override 属性を指定します。connection-ttl-override のデフォルト値は、-1 であり、クライアントは接続 TTL に対して独自の値を設定できます。

15.1.1. クローズに失敗したコアセッションまたは JMS 接続をクローズ

すべてのコアクライアントセッションと JMS 接続が終了時に常に finally ブロックで明示的にクローズされることが重要です。
セッションまたは接続が finally ブロックでクローズされない場合は、HornetQ がガベージ コレクション時にこれを検出し、ログに次のような警告を記録します (JMS を使用している場合、警告はクライアントセッションではなく JMS 接続に関係します)。
[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession]  
  I'm closing a ClientSession you left open. Please make sure you close all ClientSessions 
  explicitly before letting them go out of scope!
[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession]  
The session you did not close was created here: 
java.lang.Exception
  at org.hornetq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
  at org.acme.yourproject.YourClass (YourClass.java:666)
HornetQ は、次に接続/クライアントセッションをクローズします。
ログはクローズされなかった JMS 接続/クライアントセッションが作成されたユーザーコードの行も出力します。これにより、エラーを特定し、適切に修正できるようになります。

15.2. クライアントサイドから障害を検出

クライアントは、使用しないリソースをサーバーが削除するのを防ぐためにサーバーに対して ping をジッコウ今す。また、サーバーまたはネットワークで障害が発生したかどうかを検出するためにサーバーに対して ping を実行します。
クライアントがサーバーからデータを受信する限り、接続が保持されていると見なされます。
クライアントが client-failure-check-period ミリ秒の間まったくパケットを受け取らない場合、クライアントは接続が失敗したと見なし、設定に応じてフェイルオーバーを開始するか、または任意の SessionFailureListener インスタンス (JMS を使用している場合は ExceptionListener インスタンス) を呼び出します。
JMS の場合は、チェック期間が HornetQConnectionFactory インスタンス上の ClientFailureCheckPeriod 属性によって定義されます。JMS 接続ファクトリーインスタンスは、サーバーサイドの JNDI に直接デプロイされる場合にパラメーター client-failure-check-period を使用して JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml 設定ファイルで指定できます。
クライアント障害チェック期間のデフォルト値は 30000ms (30 秒) です。値が -1 の場合は、データをサーバーから受け取らないときにクライアントサイドで接続が失敗します。通常、これは、一時的な障害発生時にクライアントが再接続できるよう接続 TTL 値よりも大幅に小さくなります。

15.3. 非同期接続実行の設定

デフォルトでは、サーバーサイドで受信されたパケットはリモートスレッドで実行されます。
スレッドプールのスレッドを代わりに使用して、リモートスレッドが長時間固定されないように一部のパケットを処理できます。

注記

別のスレッドで非同期的に操作を処理すると、若干のレイテンシーが追加されます。
短い間実行されるほとんどの操作は、パフォーマンスのためにリモートスレッドで処理されます。非同期接続実行を有効にするために JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のパラメーター async-connection-execution-enabled が true に設定されるようにしてください。

第16章 リソースマネージャーの設定

HornetQ は JTA トランザクションのライフスパンを処理する独自のリソースマネージャーを持ちます。トランザクションが開始された場合、リソースマネージャーは通知され、トランザクションのレコードと現在のステータスを保持します。場合によっては、トランザクションが開始され、忘れられることがあります。この場合は、トランザクションが無限に存在し続けます。設定された場合、HornetQ は古いトランザクションをスキャンし、期限が切れたすべてのトランザクションをロールバックします。トランザクションのデフォルトのライフスパンは、5 分 (つまり、3000000 ミリ秒) です。つまり、5 分前以前のすべてのトランザクションが削除されます。
このタイムアウトライフスパンは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmltransaction-timeout プロパティを編集して変更できます (値はミリ秒単位である必要があります)。プロパティ transaction-timeout-scan-period は、古いトランザクションをスキャンする頻度をミリ秒単位で設定します。
HornetQ 準備された状態のすべての XA トランザクションを一括してロールバックするわけではありません。これは、管理 API を使用してヒューリスティックにロールバックする必要があります (トランザクションマネージャーで解決できない場合)。

第17章 フロー制御

フロー制御は、クライアントとサーバー間、またはあるサーバーと別のサーバー間のデータのフローを制限するために使用されます。これは、クライアントまたはサーバーがデータでいっぱいにならないよう行われます。

17.1. コンシューマーフロー制御

これは、クライアントがメッセージを消費する場合に、サーバーとクライアント間のデータのフローを制御します。パフォーマンス上の理由から、通常、クライアントは、receive() メソッドを使用してコンシューマーに配信するか、メッセージリスナーで非同期的にコンシューマーに配信する前にメッセージをバッファーします。メッセージは、メッセージが配信され、内部バッファーにインストールされたときにコンシューマーがメッセージをすぐに処理できない場合に構築できます。これにより、メッセージを時間内に処理できない場合にクライアントでメモリーが足りなくなることがあります。

17.1.1. ウィンドウベースフロー制御

HornetQ コンシューマーでは、メッセージをクライアントに渡して消費する前にクライアントサイドで特定の数のメッセージをバッファーすることによってパフォーマンスが向上します。
各メッセージに対してネットワークラウンドトリップを回避するために、HornetQ は、各コンシューマーでバッファーにメッセージをプレフェッチします。各コンシューマーでバッファーされるメッセージの最大サイズ (バイト単位) は、consumer-window-size パラメーターによって決定されます。
デフォルトでは、consumer-window-size が 1 MiB (1024 * 1024 バイト) に設定されます。
値は以下のとおりです。
  • バインドされないバッファーの場合は -1
  • メッセージをバッファーしない場合は 0
  • 該当する最大サイズ (バイト単位) のバッファーの場合は >0
コンシューマーウィンドウサイズを設定すると、メッセージング使用ケースに応じてパフォーマンスが大幅に向上することがあります。例として、次の 2 つのケースを考えてみます。
高速なコンシューマー
高速なコンシューマーは、メッセージを消費するとすぐにメッセージを処理できます。
高速なコンシューマーを許可するには、consumer-window-size を -1 に設定します。これにより、クライアントサイドでバインドされないメッセージバッファリングが許可されます。
この設定は注意して使用してください。これは、コンシューマーがメッセージを受信したときにすぐにメッセージを処理できない場合に、クライアントのメモリーをオーバーフローすることがあります。
低速なコンシューマー
低速なコンシューマーの場合は、各メッセージを処理するのに大幅な時間がかかります。したがって、クライアントサイドでメッセージのバッファリングを回避し、メッセージを別のコンシューマーに代わりに配信できることが望まれます。
キューが 2 つのコンシューマーを持つ状況を考えます (このうちの 1 は非常に低速です)。メッセージは循環形式で両方のコンシューマーに配信されます。高速なコンシューマーは、バッファーが空になるまですべてのメッセージを非常に速く処理します。この時点で、低速なコンシューマーのバッファーには処理したいメッセージが引き続き存在し、高速なコンシューマーによってメッセージが処理されることが回避されます。したがって、高速なコンシューマーは、他のメッセージを処理できる場合にアイドル状態になります。
低速なコンシューマーを許可するには、consumer-window-size を 0 (バッファーなし) に設定します。これにより、低速なコンシューマーがクライアントサイドでメッセージをバッファーすることが回避されます。メッセージは、サーバーサイドで保持され、他のコンシューマーが消費できる状態になります。
これを 0 に設定すると、キューの複数のコンシューマー間で明確なディストリビューションが提供されます。
ほとんどのコンシューマーは高速または低速なコンシューマーとして明確に識別できず、その中間になります。この場合、パフォーマンスを最適化するための consumer-window-size の値の設定は、メッセージング使用ケースに基づき、最適な値を見つけるためにベンチマークが必要です。ただし、ほとんどの場合は、1MiB の値で適切です。

17.1.1.1. コア API の使用

HornetQ コア API が使用された場合、コンシューマーウィンドウは ClientSessionFactory.setConsumerWindowSize() メソッドと ClientSession.createConsumer() メソッドのいくつかによって指定されます。

17.1.1.2. JMS の使用

接続ファクトリーをルックアップするために JNDI が使用される場合、コンシューマーウィンドウサイズは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で設定されます。
<connection-factory name="ConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>       
   </entries>
      
   <!-- Set the consumer window size to 0 to have *no* buffer on the client side -->
   <consumer-window-size>0</consumer-window-size>
</connection-factory>
接続ファクトリーが直接インスタンス化される場合、コンシューマーウィンドウサイズは HornetQConnectionFactory.setConsumerWindowSize() メソッドで指定されます。

17.1.2. レート制限フロー制御

コンシューマーがメッセージを消費できるレートを制御することもできます。これは、コンシューマーが指定されたレートよりも速いレートでメッセージを消費しないようにするために使用できます。
この機能を有効にするためにレートは、正の整数である必要があり、1 秒あたりのメッセージ単位で指定された最大メッセージ消費レートです。これを -1 に設定すると、レート制限フロー制御が無効になります。デフォルト値は -1 です。

17.1.2.1. コア API の使用

HornetQ コア API が使用された場合、レートは ClientSessionFactory.setConsumerMaxRate(int consumerMaxRate) メソッドまたは ClientSession.createConsumer() メソッドの一部によって設定できます。

17.1.2.2. JMS の使用

接続ファクトリーをルックアップするために JNDI が使用される場合、最大レートは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で設定できます。
<connection-factory name="NettyConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>       
   </entries>
<!-- We limit consumers created on this connection factory to consume messages at a maximum rate of 10 messages per sec -->
   <consumer-max-rate>10</consumer-max-rate>
</connection-factory>
接続ファクトリーが直接インスタンス化される場合、最大レートサイズは HornetQConnectionFactory.setConsumerMaxRate(int consumerMaxRate) メソッドで設定できます。

注記

レート制限フロー制御は、ウィンドウベースのフロー制御とともに使用できます。レート制限フロー制御は、クライアントが 1 秒間に消費できるメッセージの数にのみ影響を与え、バッファーにあるメッセージの数には影響を与えません。低速なレート制限と大きいウィンドウベース制限がある場合は、クライアントの内部バッファーがすぐにメッセージで満たされます。

17.2. プロデューサーフロー制御

また、HornetQ は、クライアントからサーバーに送信されるデータの量を制限してサーバーがデータでいっぱいにならないようにすることもできます。

17.2.1. ウィンドウベースフロー制御

コンシューマーウィンドウベースのフロー制御と同様に、HornetQ プロデューサー (デフォルト) は、メッセージのみをアドレスに送信できます (これを行うのに十分なクレジットがある場合)。メッセージを送信するのに必要なクレジットの量は、メッセージのサイズによって提供されます。
プロデューサーのクレジットが小さい場合、プロデューサーはサーバーからさらに多くのクレジットを要求します。サーバーがクレジット送信する場合、クレジットが大きければ大きいほどたくさんのメッセージを送信できます。
プロデューサーが一度に要求するクレジットの量は、ウィンドウサイズと呼ばれます。
したがって、ウィンドウサイズは、より多くを要求する前にある時点で保持できるバイトの量を決定します。これにより、リモート接続が過負荷の状態になることが回避されます。

17.2.1.1. コア API の使用

HornetQ コア API が使用される場合、ウィンドウサイズは ClientSessionFactory.setProducerWindowSize(int producerWindowSize) メソッドを使用して設定できます。

17.2.1.2. JMS の使用

接続ファクトリーをルックアップするために JNDI が使用される場合、プロデューサーウィンドウサイズは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で設定できます。
<connection-factory name="NettyConnectionFactory">
   <connectors>
     <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>       
   </entries>
   <producer-window-size>10</producer-window-size>
</connection-factory>
接続ファクトリーが直接インスタンス化される場合、プロデューサーウィンドウサイズは HornetQConnectionFactory.setProducerWindowSize(int producerWindowSize) メソッドで設定できます。

17.2.1.3. ブロッキングプロデューサーウィンドウベースフロー制御

通常、サーバーは必ず要求されたのと同じクレジット数を提供します。ただし、アドレスに最大サイズを設定することもできます。これにより、メモリーを実行できないようにするために、アドレスに送信できる数のクレジットがブロックされます。
たとえば、"myqueue" という名前の JMS キューがある場合、最大メモリーサイズは 10 MB に設定でき、サーバーはメッセージを myqueue に送信しているすべてのプロデューサーに送信されたクレジットの数を制御します。つまり、キューのメッセージの合計は 10 MB を超えません。
アドレスがいっぱいになった場合、プロデューサーはアドレスでさらに多くのスペースが空くまで (つまり、メッセージがキューから消費され、より多くのメッセージを送信するためのスペースが空くまで) クライアントサイドでブロックします。これは、ブロッキングプロデューサーフロー制御と呼ばれます。
最大サイズのアドレスを設定し、このアドレスがいっぱいになった場合にこのアドレスに対するプロデューサーをブロックするようサーバーに指示するには、アドレスに対して AddressSettings (「アドレス設定を介してキューを設定」) ブロックを定義し、max-size-bytesaddress-full-policy を指定します。
アドレスブロックは、そのアドレスに登録されたすべてのキューに適用されます。つまり、そのアドレスにバインドされたすべてのキューのメモリーの合計は、max-size-bytes を超えません。JMS トピックの場合、これは、トピックのすべてのサブスクリプションのメモリー合計max-size-bytes を超えないことを意味します。
以下に例を示します。
<address-settings>
   <address-setting match="jms.queue.exampleQueue">            
      <max-size-bytes>100000</max-size-bytes>
      <address-full-policy>PAGE</address-full-policy>   
   </address-setting>
</address-settings>
上記の例では、JMS キュー "exampleQueue" の最大サイズが 100,000 バイトに設定され、その最大サイズを超えないようそのアドレスに送信するすべてのプロデューサーがブロックされます。
ブロッキングプロデューサーフロー制御を有効にするにはポリシーを BLOCK に設定する必要があることに注意してください。

17.2.2. レート制限フロー制御

プロデューサーがメッセージを送信するレートは 1 秒あたりのメッセージ単位で制限できます。つまり、プロデューサーは設定された値よりも高いレートでメッセージを生成します。
この機能を有効にするためにレートは、正の整数である必要があり、1 秒あたりのメッセージ単位で指定された最大メッセージ消費レートです。これを -1 に設定すると、レート制限フロー制御が無効になります。デフォルト値は -1 です。

17.2.2.1. コア API の使用

HornetQ コア API が使用される場合、レートは ClientSessionFactory.setProducerMaxRate(int consumerMaxRate) メソッド、または一部の ClientSession.createProducer() メソッドで設定できます。

17.2.2.2. JMS の使用

ConnectionFactory をルックアップするために JNDI が使用される場合は、最大レートを JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で設定できます。
<connection-factory name="NettyConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="ConnectionFactory"/>       
   </entries>
<!-- We limit producers created on this connection factory to produce messages at a maximum rate of 10 messages per sec -->
   <producer-max-rate>10</producer-max-rate>
</connection-factory>
接続ファクトリーが直接インスタンス化される場合、最大レートサイズは HornetQConnectionFactory.setProducerMaxRate(int consumerMaxRate) メソッドで設定できます。

第18章 送信およびコミットの保証

18.1. トランザクション完了の保証

HornetQ でトランザクションをコミットまたはロールバックする場合は、コミットまたはロールバックの要求がサーバーに送信されます。このコールは、コミットまたはロールバックが実行されたことを示す応答をサーバーから受け取るまでクライアントサイドでブロックされます。
コミットまたはロールバックをサーバーで受け取ると、ジャーナルにコミットされ、パラメーター journal-sync-transactional の値に応じて、サーバーで、応答がクライアントに送信し返される前に、コミットまたはロールバックがストレージに永続化されるようになります。このパラメーターの値が false の場合、応答がクライアントに送信された後にしばらくたつまでコミットまたはロールバックは実際にはストレージに永続化されないことがあります。サーバーでの障害発生時に、これは、コミットまたはロールバックがストレージに永続化されないことを意味します。このパラメーターのデフォルト値は true であり、クライアントで、コミットまたはロールバックのコールが返されるまですべてのトランザクションコミットまたはロールバックがストレージに永続化されるようになります。
このパラメーターを false に設定すると、トランザクション耐性がある程度失われる代わりにパフォーマンスが向上します。
このパラメーターは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されます。

18.2. 非トランザクションメッセージ送信の保証

メッセージが非トランザクションセッションを使用してサーバーに送信される場合、HornetQ はメッセージがサーバーに完全に到着し、応答がクライアントに送り返されるまで送信をブロックできます。これは、耐性および非耐性メッセージに対して個別に設定でき、以下の 2 つのパラメーターによって決定されます。
BlockOnDurableSend
これが true に設定された場合、非トランザクションセッションの耐性メッセージに対するすべての送信コールは、メッセージがサーバーに到達し、応答が送り返されるまでブロックされます。デフォルト値はtrue です。
BlockOnNonDurableSend
これが true に設定された場合、非トランザクションセッションの非耐性メッセージに対するすべての送信コールは、メッセージがサーバーに到達し、応答が送り返されるまでブロックされます。デフォルト値はfalse です。
送信ブロックを true に設定すると、次の送信が実行される前に各送信がネットワークラウンドトリップを必要とするため、パフォーマンスが低下することがあります。つまり、メッセージを送信するパフォーマンスは、ネットワークの帯域幅ではなくネットワークのネットワークラウンドトリップ時間 (RTT) によって制限されます。パフォーマンスを向上させるために、多くのメッセージ送信を 1 つのトランザクションでバッチ処理するか (トランザクションセッションでは、コミット/ロールバックのみが各送信をブロックしません)、「非同期送信承認」 で説明された 非同期送信承認機能を使用します。
JMS 接続ファクトリーインスタンスを JNDI にロードするためにサーバーで JMS と JMS サービスを使用している場合は、要素 block-on-durable-send および block-on-non-durable-send を使用してこれらのパラメーターを JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で設定できます。JMS を使用し、JNDI を使用していない場合は、適切なセッターメソッドを使用して HornetQConnectionFactory インスタンスで直接これらの値を設定できます。
コアを使用している場合は、適切なセッターメソッドを使用して ClientSessionFactory インスタンスで直接これらの値を設定できます。
サーバーが非トランザクションセッションから送信されたメッセージを受け取り、このメッセージが耐性であり、少なくとも 1 つの耐性キューにルーティングされる場合は、サーバーがメッセージを永久ストレージに永続化します。ジャーナルパラメーター journal-sync-non-transactionaltrue に設定されている場合、サーバーは、メッセージが永続化され、データがディスクに永続化されたことがサーバーで保証されるまで応答をクライアントに送り返しません。このパラメーターのデフォルト値は true です。

18.3. 非トランザクション承認の保証

非トランザクションセッションを使用してクライアントサイドでメッセージの配信を承認する場合は、承認が確実にサーバーに到達し、応答がクライアントに送り返されるまで承認コールをブロックするよう HornetQ を設定できます。これは、パラメーター BlockOnAcknowledge で設定されます。これが true に設定された場合、非トランザクションセッションのすべての承認コールは承認がサーバーに到達し、応答が送り返されるまでブロックされます。厳密な 1 度だけの配信ポリシーを実装する場合は、これを true に設定します。デフォルト値は false です。

18.4. 非同期送信承認

非トランザクションセッションを使用し、サーバーに送信される各メッセージがサーバーに到達された保証が必要な場合は、「非トランザクションメッセージ送信の保証」 で説明されたように、サーバーがメッセージを受け取り、永続化し、応答を送り返すまで送信コールをブロックするよう HornetQ を設定できます。これは有用ですが、パフォーマンスが大幅に低下します。各送信コールは最低ネットワークラウンドトリップ (RTT) の時間、ブロックする必要があります。送信のパフォーマンスはネットワークのレイテンシーにより制限され、ネットワーク帯域幅により制限されません
これに対処するために、HornetQ は非同期送信承認と呼ばれる機能を提供します。この機能を使用すると、一方向にブロックしたり、メッセージを別のストリームで受け取ったことの承認をサーバーから非同期に取得したりせずに、メッセージを送信するよう HornetQ を設定できます。送信と送信の承認を分けることにより、システムはネットワーク RTT により制限されませんが、ネットワーク帯域幅により制限されます。結果的に、ブロックする方法を使用するよりも優れたスループットを達成できます (同時に、メッセージがサーバーに正常に到達したことが確実に保証されます)。
送信承認のウィンドウサイズは、接続ファクトリーまたはクライアントセッションファクトリーの confirmation-window-size パラメーターにより決定されます。この詳細については、32章クライアントの再接続とセッションの再割り当て を参照してください。

18.4.1. 非同期送信承認

コア API により機能を使用するには、インターフェース org.hornetq.api.core.client.SendAcknowledgementHandler を実装し、ClientSession でハンドラーインスタンスを設定します。
ClientSession を使用して通常どおりメッセージを送信します。メッセージがサーバーに到着すると、サーバーは送信の承認を非同期で送り返します。HornetQ はハンドラーの sendAcknowledged(ClientMessage message) メソッドを呼び出し、送信されたメッセージへの参照を渡します。
非同期送信承認を有効にするには、confirmation-window-size が正の整数値に設定されるようにします (バイト単位で指定)。たとえば、10485760 (10 メビバイト) になります。

第19章 メッセージ再配信と未配信メッセージ

メッセージ配信は、メッセージを使用するために使用されるセッションがロールバックされた場合などに失敗することがあります。未配信メッセージは配信可能なキューに戻されます。ただし、これは、複数の配信が失敗したときに、メッセージがキューに残ったままになり、システムに負荷を与えることを意味します。system.
これらの未配信メッセージには次の 2 つのオプションがあります。
遅延再配信
メッセージ配信は、クライアント時間が一時的な失敗から回復し、ネットワークまたは CPU リソースをオーバーロードしないように遅延させることができます。
死亡したレターアドレス
配信できないと判断された後にメッセージを送信する死亡したレターアドレスを設定します。
これらのオプションは、柔軟性を最大化するために組み合わせることができます。

19.1. 遅延再配信

再配信の遅延は、定期的に失敗したり、ロールバックされたりするクライアントに役に立つことがあります。再配信の遅延がないと、システムは「非常に負荷が高い」状態になり、配信に失敗したり、クライアントがロールバックされたりして永久的な再配信が試行され、CPU およびネットワークリソースが消費されることがあります。

19.1.1. 遅延再配信の設定

遅延再配信は、address-setting 設定で定義されます。
<!-- delay redelivery of messages for 5s -->
<address-setting match="jms.queue.exampleQueue">
   <redelivery-delay>5000</redelivery-delay>
</address-setting>
redelivery-delay が指定された場合、HornetQ は該当するミリ秒の間待機し、メッセージを再配信します。再配信遅延はデフォルトで有効になり、60000 (1 分) に設定されます。
アドレスワイルドカードは、アドレスセットに対して再配信遅延を設定するために使用できます (11章HornetQ ワイルドカード構文について を参照)。この場合は、再配信遅延を各アドレスに対して個別に指定する必要はありません。

19.2. 死亡したレターアドレス

クライアントが同じ未配信メッセージを無限に受け取らないようにするために (失敗した配信の原因に関係なく)、メッセージングシステムは、死亡したレターアドレスを定義します。指定された配信失敗試行回数後に、メッセージは、キューから削除され、代わりに死亡したレターアドレスに送信されます。
このようなすべてのメッセージは 1 つ以上のキューに迂回できます。これらのメッセージは実行するアクションのためにシステム管理者が後で確認できます。
HornetQ アドレスには、死亡したレターアドレスを割り当てることができます。メッセージは、該当する試行回数配信されないと、キューから削除され、死亡したレターアドレスに送信されます。これらの死亡したレターメッセージは、後で調査のために消費できます。

19.2.1. 死亡したレターアドレスの設定

死亡したレターアドレスは address-setting 設定で定義されます。
<!-- undelivered messages in exampleQueue will be sent to the dead 
letter address deadLetterQueue after 3 unsuccessful delivery attempts-->
<address-setting match="jms.queue.exampleQueue">
   <dead-letter-address>jms.queue.deadLetterQueue</dead-letter-address>
   <max-delivery-attempts>3</max-delivery-attempts>
</address-setting>
dead-letter-address が指定されない場合、メッセージは max-delivery-attempts の失敗回数後に削除されます。
デフォルトでは、メッセージは最大 10 回再配信されます。再配信を無限に行う場合は、max-delivery-attempts-1 に設定します。
死亡したレターアドレスは、一致するアドレスセットに対してグローバルで設定できます。このアドレスにのみ無限の再配信を可能にする特定のアドレス設定の場合は、max-delivery-attempts-1 に設定します。
アドレスワイルドカードは、アドレスセットに対して死亡したレター設定を行うために使用できます (11章HornetQ ワイルドカード構文について を参照)。

19.2.2. 死亡したレターのプロパティ

死亡したレターアドレスから消費された死亡したレターメッセージのプロパティは以下のとおりです。
HQ_ORIG_ADDRESS
死亡したレターメッセージの元のアドレスを含む文字列プロパティ。

19.3. 配信数の永続化

通常は、メッセージがロールバックされるまで HornetQ は更新された配信数を永続化しません (つまり、配信数はメッセージがコンシューマーに配信されるに更新されません)。メッセージングのほとんどのケースでは、メッセージは消費および承認され、消費されたときにすぐに忘れられます。このような場合、メッセージの配信前に配信数を永続的に更新すると、配信された各メッセージに対して永続化ステップが追加され、パフォーマンスが大幅に低下します。
ただし、サーバークラッシュ時に、メッセージ配信前に配信数が永続的に更新されないと、一部のメッセージの配信が配信数に反映されないことがあります。したがって、復元段階では、サーバーは redeliveredfalse に設定されたメッセージを配信できます (true である必要がある場合)。
この動作により厳密な JMS セマンティクスが破壊されるため、HornetQ ではメッセージ配信前に配信数を永続化できます。ただし、パフォーマンス上の理由からこれはデフォルトで無効になります。この動作を有効にするには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlpersist-delivery-count-before-deliverytrue に設定します。
<persist-delivery-count-before-delivery>
  true
</persist-delivery-count-before-delivery>

第20章 メッセージの期限切れ

メッセージは、メッセージの送信時にオプションの存続期間 (TimeToLive) で設定できます。
HornetQ は、存続期間が過ぎた後にメッセージをコンシューマーに配信しません。存続期間に到達する前にメッセージが配信されない場合は、サーバーがメッセージを破棄できます。
HornetQ アドレスには、期限切れアドレスを割り当てることができます。したがって、メッセージの期限が切れた場合に、アドレスがキューから削除され、期限切れアドレスに送信されます。期限切れアドレスには多くのさまざまなキューをバインドできます。これらの期限切れメッセージは、後で消費して詳しく調査できます。

20.1. メッセージの期限切れ

HornetQ コア API を使用する場合は、メッセージに直接期限を設定できます。
// message will expire in 5000ms from now
message.setExpiration(System.currentTimeMillis() + 5000);
JMS MessageProducer を使用すると、送信されるメッセージに対して TimeToLive を設定できます。
// messages sent by this producer will be retained for 5s (5000ms) before expiration           
producer.setTimeToLive(5000);
期限切れアドレスから消費される期限切れメッセージは、以下のプロパティーを持っています。
HQ_ORIG_ADDRESS
期限切れメッセージの元のアドレスを含む文字列プロパティー
HQ_ACTUAL_EXPIRY
期限切れメッセージの実際の期限を含む Long のプロパティー

20.2. 期限切れアドレスの設定

期限切れアドレスは、address-setting 設定で定義されます。
<!-- expired messages in exampleQueue will be sent to the expiry address expiryQueue -->
<address-setting match="jms.queue.exampleQueue">
   <expiry-address>jms.queue.expiryQueue</expiry-address>
</address-setting>
メッセージの期限が切れており、期限切れアドレスが指定されない場合、これらのメッセージはキューから削除され、ドロップされます。アドレスワイルドカードは、アドレスセットに対して期限切れアドレスを設定するために使用できます (11章HornetQ ワイルドカード構文について を参照)。

20.3. 期限切れリーパースレッドの設定

リーパースレッドは、キューを定期的に調査してメッセージが期限切れになっているかどうかを確認します。
リーパースレッドは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml の以下のプロパティーで設定できます。
message-expiry-scan-period
期限切れメッセージを検出するためにキューがスキャンされる頻度 (ミリ秒単位、デフォルト値は 30000ms、リーパースレッドを無効にする場合は -1 に設定)。
message-expiry-thread-priority
リーパースレッドの優先度 (これは 0 〜 9 の間である必要があります。9 は最も高い優先度です。デフォルト値は 3 です)。

第21章 大きなメッセージ

HornetQ は、クライアントとサーバーが制限されたメモリーで稼動している場合であっても、大きいメッセージの送受信をサポートします。送信または消費できるメッセージのサイズに対する唯一の現実的な制限は、利用可能なディスク領域のサイズです。
大きいメッセージを送信するために、ユーザーはメッセージボディーで InputStream を設定できます。このメッセージが送信された場合、HornetQ は InputStream を読み取ります。たとえば、FileInputStream は、ディスク上の大きいファイルから大きいメッセージを送信するために使用できます。
InputStream が読み取られた場合、データは断片のストリームとしてサーバーに送信されます。サーバーはこれらの断片を受け取ったときにディスクに断片を永続化します。データをコンシューマーに配信するときに、データはディスクから断片単位で再び読み取られ、再配信されます。コンシューマーが大きいメッセージを受け取る場合、コンシューマーは最初にボディーが空のメッセージのみを受け取ります。メッセージで OutputStream を設定して、大きいメッセージボディーをディスク上や他の場所にあるファイルにストリーミングできます。メッセージボディー全体は、クライアントまたはサーバーのいずれかでメモリーに完全に保存されません。

21.1. サーバーの設定

大きいメッセージは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されたように、サーバーサイドのディスクディレクトリに保存されます。
設定プロパティー large-messages-directory は、大きいメッセージが保存される場所を指定します。
<configuration xmlns="urn:hornetq"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:hornetq /schema/hornetq-configuration.xsd">

...

   <large-messages-directory>${jboss.server.data.dir}/${hornetq.data.dir:hornetq}/largemessages</large-messages-directory>

...

</configuration>
デフォルトでは、大きいメッセージディレクトリは data/large-messages です。
パフォーマンスを最大化する場合は、大きいメッセージディレクトリを、メッセージジャーナルまたはページングディレクトリと異なる物理ボリュームに格納することが推奨されます。

21.2. 制限の設定

特定のサイズよりも大きいメッセージは、大きいメッセージと見なされます。大きいメッセージは断片に分割され、断片で送信されます。これは、パラメーター min-large-message-size により決定されます。
デフォルト値は 100KiB です。

21.2.1. コア API の使用

HornetQ Core API が使用された場合、大きいメッセージの最小サイズは ClientSessionFactory.setMinLargeMessageSize により指定されます。
ClientSessionFactory factory = 
  HornetQClient.createClientSessionFactory(new 
  TransportConfiguration(NettyConnectorFactory.class.getName()), null);
factory.setMinLargeMessageSize(25 * 1024);
「クライアントサイドから直接トランスポートを設定」 は、セッションファクトリーのインスタンス化方法の詳細を提供します。

21.2.2. JMS の使用

接続ファクトリーをルックアップするために JNDI が使用された場合、大きいメッセージの最小サイズは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で指定されます。
...
<connection-factory name="NettyConnectionFactory">
   <connectors>
     <connector-ref connector-name="netty"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>
      <entry name="/XAConnectionFactory"/>
   </entries>
   <min-large-message-size>250000</min-large-message-size>
</connection-factory>
...
接続ファクトリーが直接インスタンス化される場合、大きいメッセージの最小サイズは HornetQConnectionFactory.setMinLargeMessageSize で指定されます。

21.3. 大きいメッセージのストリーミング

HornetQ は、入力および出力ストリームを使用したメッセージのボディーの設定をサポートします (java.lang.io)。
これらのストリームは、メッセージを送信 (入力ストリーム) および受信 (出力ストリーム) するために直接使用されます。
メッセージを受信する場合は、出力ストリームを 2 つの方法で使用できます。メソッド ClientMessage.saveOutputStream、またはメッセージをストリームに非同期的に書きこむメソッド ClientMessage.setOutputstream を使用して出力ストリームが復元されるときにブロックを選択できます。ClientMessage.setOutputstream を選択した場合は、メッセージが完全に受信されるまでコンシューマーが存続している必要があります。
どんな種類のストリームでも使用できます。最も一般的な使用ケースは、ディスク状に保存されたファイルを送信することですが、以下のようなものを送信することもできます。
  • JDBC BLOB
  • SocketInputStream
  • HTTPRequests から復元されるものなど
メッセージを送信するために java.io.InputStream、またはメッセージを受信するために java.io.OutputStream を実装するすべてのものを使用できます。

21.3.1. コア API を介したストリーミング

以下の表は、オブジェクトプロパティーを使用することにより JMS を介して利用できる ClientMessage で利用可能なメソッドのリストを示しています。

表21.1 org.hornetq.api.core.client.ClientMessage API

名前 説明 JMS の同等プロパティー
setBodyInputStream (InputStream) メッセージの送信時にメッセージボディーを読み取るために使用する InputStream を設定します。 JMS_HQ_InputStream
setOutputStream (OutputStream) メッセージのボディーを受信する OutputStream を設定します。このメソッドはブロックしません。 JMS_HQ_OutputStream
saveToOutputStream (OutputStream) メッセージのボディーを OutputStream に保存します。これは内容全体が OutputStream に転送されるまでブロックされます。 JMS_HQ_SaveStream
コアメッセージの受信時に出力ストリームを設定する場合:
...
ClientMessage msg = consumer.receive(...);

// This will block here until the stream was transferred
msg.saveToOutputStream(someOutputStream); 

ClientMessage msg2 = consumer.receive(...);

// This will not wait the transfer to finish
msg.setOutputStream(someOtherOutputStream); 
...
コアメッセージの送信時に入力ストリームを設定する場合:
...
ClientMessage msg = session.createMessage();
msg.setInputStream(dataInputStream);
...

21.3.2. JMS を介したストリーミング

JMS を使用する場合、オブジェクトプロパティーを設定することにより、HornetQ は、コア API のストリーミングメソッドをマッピングします (表21.1「org.hornetq.api.core.client.ClientMessage API」 を参照)。入力および出力ストリームを設定するには、メソッド Message.setObjectProperty を使用できます。
InputStream は、送信されるメッセージで JMS Object Property JMS_HQ_InputStream によって定義できます。
BytesMessage message = session.createBytesMessage();

FileInputStream fileInputStream = new FileInputStream(fileInput);

BufferedInputStream bufferedInput = new BufferedInputStream(fileInputStream);

message.setObjectProperty("JMS_HQ_InputStream", bufferedInput);

someProducer.send(message);
OutputStream は、ブロッキングの方法で受信されるメッセージで、JMS Object Property JMS_HQ_SaveStream によって設定できます。
BytesMessage messageReceived = (BytesMessage)messageConsumer.receive(120000);
                
File outputFile = new File("huge_message_received.dat");
                
FileOutputStream fileOutputStream = new FileOutputStream(outputFile);
                
BufferedOutputStream bufferedOutput = new BufferedOutputStream(fileOutputStream);
                
// This will block until the entire content is saved on disk
messageReceived.setObjectProperty("JMS_HQ_SaveStream", bufferedOutput);
OutputStream の設定は、プロパティー JMS_HQ_OutputStream を使用して非ブロッキングの方法で行うこともできます。
// This will not wait the stream to finish. You need to keep the consumer active.
messageReceived.setObjectProperty("JMS_HQ_OutputStream", bufferedOutput);

注記

JMS を使用する場合、大きいメッセージのストリーミングは、StreamMessageBytesMessage でだけサポートされます。

21.4. 別のストリーミング方法

HornetQ の InputStream または OutputStream 機能を使用しない場合、データには別の方法で直接アクセスできます。
コア API で、7章コアの使用 で説明されたようにボディーのバイトを取得します。
ClientMessage msg = consumer.receive();
         
byte[] bytes = new byte[1024];
for (int i = 0 ;  i < msg.getBodySize(); i += bytes.length)
{
   msg.getBody().readBytes(bytes);
   // Whatever you want to do with the bytes
}
JMS API を使用する場合、BytesMessageStreamMessage は、これを透過的にサポートします。
BytesMessage rm = (BytesMessage)cons.receive(10000);

byte data[] = new byte[1024];

for (int i = 0; i < rm.getBodyLength(); i += 1024)
{
   int numberOfBytes = rm.readBytes(data);
   // Do whatever you want with the data
}

21.5. クライアントでの大きいメッセージのキャッシュ

大きいメッセージは、ストリーミングによりサーバーからクライアントに転送されます。メッセージは小さいパケットに分割され、メッセージが読み取られるときにより多くのパケットが受信されます。このため、大きいメッセージは 1 度だけしか読み取ることができず、結果として、受信されたメッセージは別のプロデューサーに 1 度だけしか送信できません。たとえば、障害発生時に、JMS ブリッジは大きいメッセージを再送信できません。
この問題を解決するために、接続ファクトリーでプロパティー cache-large-message-client を有効にできます。このプロパティーを有効にした場合、クライアントコンシューマーは大きいメッセージの内容を保持する一時ファイルを作成するため、大きいメッセージを再送信できます。

注記

大きいメッセージに JMS ブリッジが使用される場合は、JMS ブリッジで使用された接続ファクトリーでこのオプションを使用します。

第22章 ページング

HornetQ は、サーバーが制限されたメモリーで稼動しているときに、数百万のメッセージを含む巨大なキューを透過的にサポートします。
このような状況では、一度にすべてのキューをメモリーに格納できないため、HornetQ は必要に応じてメッセージをメモリーに対して透過的にページングします。これにより、メモリーフットプリントが小さくても巨大なキューを使用できます。
HornetQ は、アドレスに対するメモリー内のすべてのメッセージのサイズが、設定された最大サイズを超えた場合にディスクへのメッセージのページングを開始します。
デフォルトでは、HornetQ はメッセージをページングしません。これは、明示的に有効に設定する必要があります。

22.1. ページファイル

メッセージは、各アドレスごとにファイルシステムに保存されます。各アドレスは、メッセージが複数のファイル (ページファイル) に保存された個々のフォルダーを持ちます。各ファイルには、設定された最大サイズ (page-size-bytes) までのメッセージが含まれます。ページファイルを読み取る場合は、ページファイルのすべてのメッセージが読み取られ、ルーティングされます。ファイルは、メッセージが復元されたらすぐに削除されます。

22.2. 設定

ページングフォルダーの場所を設定できます。
グローバルページングパラメーターは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で指定されます。
<configuration xmlns="urn:hornetq"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="urn:hornetq /schema/hornetq-configuration.xsd">
            
            ...
            
            <paging-directory>${jboss.server.data.dir}/hornetq/paging</paging-directory>
            
            ...
paging-directory
これは、ページファイルが格納された場所です。HornetQ は設定されたこの場所に基づいて各アドレスに対して 1 つのフォルダーを作成します。このデフォルト値はデータ/ページングです。

22.3. ページングモード

アドレスに配信されたメッセージが設定されたサイズを超えた場合は、すぐにそのアドレスだけがページモードに変わります。

注記

ページングは、各アドレスに対して個別に行われます。アドレスに対して max-size-bytes を設定すると、一致する各アドレスで、最大サイズが指定されます。これは、一致するすべてのアドレスの合計サイズが max-size-bytes に制限されることを意味しないことに注意してください。

22.3.1. 設定

設定は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のアドレス設定で行われます。
<address-settings>
   <address-setting match="jms.someaddress">
      <max-size-bytes>104857600</max-size-bytes>
      <page-size-bytes>10485760</page-size-bytes>
      <address-full-policy>PAGE</address-full-policy>
   </address-setting>
</address-settings>
これは、アドレス設定で利用可能なパラメーターのリストです。

表22.1 ページングアドレス設定

プロパティー名 説明 デフォルト
max-size-bytes ページモードになる前にアドレスが持つことができる最大メモリー。 -1 (無効)
page-size-bytes ページングシステムで使用される各ページファイルのサイズ 10MiB (10 * 1024 * 1024 バイト)
address-full-policy ページングを有効にするには、これを PAGE に設定する必要があります。
  • 値が PAGE の場合、それ以降のメッセージはディスクにページングされます。
  • 値が DROP の場合、追加のメッセージはサイレント状態でドロップされます。
  • 値が BLOCK の場合、クライアントメッセージプロデューサーは追加のメッセージを送信しようとしたときにブロックされます。
PAGE
page-max-cache-size ページングナビゲーション中に入力/出力サイクルを最適化するためにメモリーに保持されるページファイルの数を指定します。 5

22.4. メッセージのドロップ

最大サイズに達したときにメッセージをページングする代わりに、アドレスはアドレスがいっぱいになったときにメッセージをドロップするよう設定することもできます。
これを行うには、アドレス設定で address-full-policyDROP に設定します。

22.5. プロデューサーのブロック

最大サイズに達したときにメッセージをページングする代わりに、アドレスはアドレスがいっぱいになったときにプロデューサーがさらにメッセージを送信することをブロックするよう設定することもできます。これにより、サーバーでメモリーが足りなくなることが回避されます。
プロデューサーは、自動的にブロック解除され、メモリーがサーバーで解放されたときに送信し続けることができます。
これを行うには、アドレス設定で address-full-policyBLOCK に設定します。

重要

ブロックはブリッジの使用時には推奨されません。これは、ブロックが無視され、メッセージが常に転送されるためです。ブリッジの場合は、宛先がブロックの代わりにページングを使用するように設定するか、ターゲット宛先に常にコンシューマーがあるようにします。
デフォルトの設定では、すべてのアドレスが、アドレス内にあるデータが 10 MiB を超えた場合にプロデューサーをブロックするよう設定されます。

22.6. 複数のキューを持つアドレスの注意

メッセージが、バインドされた複数のキューを持つアドレスにルーティングされた場合 (たとえば、JMS サブスクリプション) は、メモリー内にメッセージのコピーが 1 つしかありません。各キューはこれに対する参照のみを扱います。つまり、メッセージを参照するすべてのキューがそのメッセージを配信すると、初めてメモリーが解放されます。
例:
  • アドレスが 10 個のキューを持ちます。
  • キューの 1 つがメッセージを配信しません (おそらく、低速なコンシューマーが原因)。
  • メッセージは、連続してアドレスに到着し、ページングが開始されます。
  • メッセージが送信された場合であっても他の 9 個のキューは空になります。
この例では、プロセスがページング解除し、他のキューが最終的にいくつかのメッセージを受け取る前にいくつかのメッセージを最後のキューが配信するまでプロセスは待機する必要があります。

重要

メッセージセレクターは、メモリー内のメッセージに対してのみ動作します。大量のメッセージをディスクにページングし、ページングされる一部のメッセージのみに一致するセレクターがある場合、これらのメッセージは、メモリー内のメッセージが消費されるまで消費されません。
HornetQ は、一致するメッセージを見つけるためにディスク上のページファイルをスキャンしません。これはメッセージングシステムの主な役割ではありません。セレクターを使用して非常に大きいキューでメッセージの小さいサブセットを選択する実装には、リレーショナルデータベースが推奨されます。これは、この機能がリレーショナルデータベースのテーブルに対してクエリーを実行することに似ているためです。

重要

page-size-bytes (サーバー) を ack-batch-size (クライアント) よりも小さい値に設定しないでください。設定すると、システムがハングしているように見えることがあります。
メッセージは、サーバーで識別されるまでサーバーメモリーに残るため、特定のアドレスのメッセージサイズに影響を与えます。
アドレスに対するメッセージがディスクにページングされ、消費される場合、メッセージが消費および承認された後にこのアドレスで十分なメモリーが解放されたときに、これらのメッセージはディスクからページング解除されます。ただし、メッセージが承認されない場合は、メモリー内に空き領域がないため、追加のメッセージはページング解除されません。この場合は、メッセージ消費がハングしているように見えることがあります。
メッセージが明示的に承認されない場合、メッセージは、クライアントの "ack-batch-size" 設定に基づいて承認されます。

第23章 キュー属性

キュー属性は、設定ファイルを使用するか、コア API を使用するかいずれかの方法で設定できます。本章では、各属性の設定方法と属性の影響について説明します。

23.1. 事前定義されたキュー

キューは、コアレベルまたは JMS レベルで設定により事前定義できます。最初に JMS レベルについて説明します。
JMS レベル

以下は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml 設定ファイルで事前定義されたキューを示しています。

<queue name="selectorQueue">
   <entry name="/queue/selectorQueue"/>
   <selector string="color='red'"/>
   <durable>true</durable>
</queue>
<queue> のこの name 属性は、キューの名前を定義します。これを JMS レベルで行う場合は、命名規則に従い、コアキューの実際の名前が jms.queue.selectorQueue になるようにします。
必須の <entry> 要素は、キューを JNDI にバインドするために使用される名前を設定します。<queue> には、同じキューをさまざまな名前にバインドする複数の <entry> 要素を含めることができます。
オプションの <selector> 要素は、事前定義されたキューが持つ JMS メッセージセレクターを定義します。セレクターに一致するメッセージのみがキューに追加されます。<queue> から省略された場合、デフォルト値は null になります。
オプションの <durable> 要素はキューが永続化されたかどうかを指定します。<queue> から省略された場合、デフォルト値は true です。
コアレベル

キューは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルにおいてコアレベルで事前定義できます。

<queues>     
   <queue name="jms.queue.selectorQueue">
      <address>jms.queue.selectorQueue</address>
      <filter string="color='red'"/>
      <durable>true</durable>
</queues>
これは、JMS 設定に非常に似ていますが、以下の例外があります。
  1. キューの名前属性が JMS の命名規則がないキューに対して使用された実際の名前になります。
  2. アドレス要素は、メッセージをルーティングするために使用されるアドレスを定義します。
  3. エントリー要素はありません。
  4. フィルターは、JMS セクレター構文ではなくコアフィルター構文 (12章フィルター表現 で説明) を使用します。

23.2. API の使用

また、キューは、コア API または管理 API を使用して作成することもできます。
コア API の場合、キューは org.hornetq.api.core.client.ClientSession インターフェースを使用して作成できます。以前に記載されたすべての属性の設定をサポートする複数の createQueue メソッドが存在します。この API を使用して temporary である特別な属性を設定できます。これを true に設定すると、セッションが切断されたときにキューが削除されます。
キューを作成する管理 API については、28章管理 を参照してください。

23.3. アドレス設定を介してキューを設定

一部の属性は、特定のキューではなくアドレスワイルドカードを使用して定義されます。以下に、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルにある address-setting エントリの例を示します。
<address-settings>
   <address-setting match="jms.queue.exampleQueue">
      <dead-letter-address>jms.queue.deadLetterQueue</dead-letter-address>
      <max-delivery-attempts>3</max-delivery-attempts>
      <redelivery-delay>5000</redelivery-delay>
      <expiry-address>jms.queue.expiryQueue</expiry-address>
      <last-value-queue>true</last-value-queue>        
      <max-size-bytes>100000</max-size-bytes>
      <page-size-bytes>20000</page-size-bytes>
      <redistribution-delay>0</redistribution-delay>
      <send-to-dla-on-no-route>true</send-to-dla-on-no-route>
      <address-full-policy>PAGE</address-full-policy>
   </address-setting>
</address-settings>
アドレス設定では、match 属性の文字列に一致するすべてのアドレスに対して適用される設定のブロックを提供できます。上記の例では、設定は、アドレス jms.queue.exampleQueue に完全一致するすべてのアドレスにのみ適用されますが、ワイルドカードを使用して多くのアドレスに対して設定セットを適用することもできます。使用されるワイルドカード構文は、11章HornetQ ワイルドカード構文について で説明されています。
たとえば、match 文字列 jms.queue.# を使用した場合、設定は、JMS キューである jms.queue. で始まるすべてのアドレスに適用されます。
特定の設定の意味については、ユーザーマニュアル全体で詳しく説明されます。ここでは、簡単な説明を適切な章 (存在する場合) へのリンクとともに示します。
max-delivery-attempts
キャンセルされたメッセージを dead-letter-address に送信する前に、そのメッセージを再配信できる回数を定義します。完全な説明については、「死亡したレターアドレスの設定」 を参照してください。
redelivery-delay
キャンセルされたメッセージの再配信を施行するまで待機する時間を定義します。「遅延再配信の設定」 を参照してください。
expiry-address
期限が切れたメッセージを送信する場所を定義します。「期限切れアドレスの設定」 を参照してください。
last-value-queue
キューが最後の値のみを使用するかどうかを定義します。25章Last-Value キュー を参照してください。
max-size-bytes および page-size-bytes
アドレスでページングを設定するために使用されます。これについては、22章ページング を参照してください。
redistribution-delay
メッセージの再配信前に最後のコンシューマーが閉じられたときに待機する時間を定義します。「メッセージ再分散」 を参照してください。
send-to-dla-on-no-route
メッセージがアドレスに送信され、サーバーがメッセージをキューにルーティングしない場合 (たとえば、そのアドレスにバインドされたキューが存在しない場合や一致するフィルターを持つキューが存在しない場合)、メッセージは通常破棄されます。ただし、このアドレスに対してこのパラメーターが true に設定された場合、メッセージがどのキューにもルーティングされないと、このアドレスに対するメッセージは代わりに Dead Letter Address (DLA) に送信されます (存在する場合)。
address-full-policy
この属性には、PAGE、DROP、または BLOCK のいずれかの値を含めることができ、これにより、max-size-bytes が指定されたアドレスがいっぱいになったときの動作が決定されます。デフォルト値は PAGE です。値が PAGE の場合は、追加のメッセージがディスクにページングされます。
  • 値が DROP の場合、追加のメッセージはサイレント状態でドロップされます。
  • 値が BLOCK の場合、クライアントメッセージプロデューサーは追加のメッセージを送信しようとしたときにブロックされます。
詳細については、17章フロー制御22章ページング を参照してください。

第24章 スケジュールされたメッセージ

スケジュールされたメッセージは、指定された将来の時間まで配信されないため、通常のメッセージとは異なります。
これを行うために、メッセージを送信する前にメッセージで特別なプロパティーが設定されます。

24.1. スケジュールされた配信プロパティ

スケジュールされたメッセージの指定に使用されるプロパティー名は、"_HQ_SCHED_DELIVERY" (または、定数 Message.HDR_SCHEDULED_DELIVERY_TIME) です。
指定された値は、メッセージを配信する必要がある時間 (ミリ秒単位) に対応する正の long である必要があります。JMS API を使用してスケジュールされたメッセージを送信する例は次のとおりです。
  TextMessage message = 
   session.createTextMessage("This is a scheduled message message which will be delivered
     in 5 sec.");
  message.setLongProperty("_HQ_SCHED_DELIVERY", System.currentTimeMillis() + 5000);
  producer.send(message);

  ...
         
  // message will not be received immediately but 5 seconds later
  TextMessage messageReceived = (TextMessage) consumer.receive();
スケジュールされたメッセージは、コア API を使用して、送信前にコアメッセージに同じプロパティーを設定して送信することもできます。

第25章 Last-Value キュー

Last-Value キューは適切に定義された Last-Value プロパティーに対して同じ値を持つ新しいメッセージがキューに格納されたときにすべてのメッセージを破棄する特殊なキューです。
Last-Value キューの一般的な例は、特定の株の最終価格にのみ興味を持つ場合の株価です。

25.1. Last-Value キューの設定

Last-value キューは address-setting 設定で定義されます。
<address-setting match="jms.queue.lastValueQueue">
   <last-value-queue>true</last-value-queue>
</address-setting>
デフォルトで、last-value-queue は false です。アドレスワイルドカードは、アドレスセットに対して Last-Value キューを設定するために使用できます (11章HornetQ ワイルドカード構文について を参照)。

25.2. Last-Value プロパティーの使用

最終値を識別するために使用するプロパティー名は "_HQ_LVQ_NAME" (または、定数 Message.HDR_LAST_VALUE_NAME from the Core API) です。
たとえば、Last-Value プロパティーに対して同じ値を持つ 2 つのメッセージが Last-Value キューに送信された場合は、最新メッセージのみがキューに保持されます。
// send 1st message with Last-Value property set to STOCK_NAME
TextMessage message = 
  session.createTextMessage("1st message with Last-Value property set");
message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
producer.send(message);

// send 2nd message with Last-Value property set to STOCK_NAME             
message = 
  session.createTextMessage("2nd message with Last-Value property set");
message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
producer.send(message);
       
...
       
// only the 2nd message will be received: it is the latest with 
// the Last-Value property set
TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
System.out.format("Received message: %s
", messageReceived.getText());

第26章 メッセージグループ化

メッセージグループは、以下の特徴を持つメッセージセットです。
  • メッセージグループ内のメッセージは、同じグループ ID を共有します。つまり、これらは同じグループ ID プロパティーを持っています (JMS の場合は JMSXGroupID、HornetQ コア API の場合は _HQ_GROUP_ID)。
  • メッセージグループ内のメッセージは、キューに多くのコンシューマーがある場合であっても常に同じコンシューマーにより消費されます。これらは同じグループ ID を持つすべてのメッセージを同じコンシューマー割り当てます。このコンシューマーが閉じられると、別のコンシューマーが選択され、同じグループ ID を持つすべてのメッセージを受け取ります。
メッセージグループは、プロパティーの特定の値のすべてのメッセージを同じコンシューマーによって順番に処理する場合に役に立ちます。
例としては、特定の下部の注文などがあります。特定の株の注文を同じコンシューマーによって順番に処理したいとします。この場合は、コンシューマーのプールを作成し (おそらく、各株に対して 1 つ)、株の名前を _HQ_GROUP_ID プロパティーの値として設定できます。
これにより、特定の株のすべてのメッセージが常に同じコンシューマーによって処理されます。

26.1. コア API の使用

メッセージグループを識別するために使用されるプロパティー名は "_HQ_GROUP_ID" (または定数 MessageImpl.HDR_GROUP_ID) です。または、ランダムで一意の ID を所得する SessionFactoryautogroup を設定できます。

26.2. JMS の使用

メッセージグループを識別するために使用されるプロパティー名は JMSXGroupID です。
 // send 2 messages in the same group to ensure the same
 // consumer will receive both
 Message message = ...
 message.setStringProperty("JMSXGroupID", "Group-0");
 producer.send(message);

 message = ...
 message.setStringProperty("JMSXGroupID", "Group-0");
 producer.send(message);
または、ランダムで一意の ID を取得する HornetQConnectionFactoryautogroup を true に設定できます。これは、以下のように JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml ファイルで設定することもできます。
<connection-factory name="NettyConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>
   </entries>
   <autogroup>true</autogroup>
</connection-factory>
または、接続ファクトリーを使用してグループ ID を設定できます。この接続ファクトリーによって作成されたプロデューサーで送信されたすべてのメッセージは、JMSXGroupID を、送信されたすべてのメッセージの指定された値に設定します。グループ ID を設定するには、以下のように、hornetq-jms.xml 設定ファイルの接続ファクトリーで設定します。
<connection-factory name="NettyConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>
   </entries>
   <group-id>Group-0</group-id>
</connection-factory>

26.3. クラスタリングされたグループ化

クラスターでのメッセージグループの使用は、特定のグループ ID を持つメッセージが任意のノードに到着するため、少し複雑になります。各ノードは、どのグループ ID がどのノードでどのコンシューマーにバインドされるかを知る必要があります。
特定のグループ ID に対するメッセージを処理するコンシューマーは、クラスターの異なるノードに存在することがあるため、各ノードはこの情報を知る必要があります (したがって、そのコンシューマーを持つノードに適切にメッセージをルーティングできます)。
これを解決するために、グループ化ハンドラーがあります。各ノードは独自のグループ化ハンドラーを持ち、メッセージが割り当てられたグループ ID とともに送信された場合に、ハンドラーはメッセージが選択すべきルートを決定します。
ハンドラーにはローカルとリモートの 2 つの種類があります。各クラスターはローカルグループ化ハンドラーを持つ 1 つのノードを選択し、他のすべてのノードはリモートハンドラーを持つ必要があります。ローカルハンドラーは、使用するルートに関する決定を行います。リモートハンドラーはこれと対話します。ここでは、両方の種類のハンドラーのサンプル設定を示します。これは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルで設定する必要があります。
<grouping-handler name="my-grouping-handler">
   <type>LOCAL</type>
   <address>jms</address>
   <timeout>5000</timeout>
</grouping-handler>
<grouping-handler name="my-grouping-handler">
   <type>REMOTE</type>
   <address>jms</address>
   <timeout>5000</timeout>
</grouping-handler>
address 属性は、クラスター接続と、使用するアドレス指定の種類 (jms またはコア) を参照します。timeout 属性は、決定を行うまでの待機時間 (ミリ秒単位) を参照します。タイムアウトに到達すると、送信中に例外がスローされます。これにより、厳密な順序付けが保持されます。

注記

クラスターの設定については、36章クラスター を参照してください。
メッセージをルーティングする場所に関する決定は、最初に、メッセージを受信するノードにより提示されます。ノードはクラスタリングされた通常のルーティング状況に応じて適切なルートを選択します (つまり、利用可能なキューを配布し、ローカルキューを最初に使用し、コンシューマーを持つキューを選択します)。提示がグループ化ハンドラーにより受け取られた場合は、ノードがその時点からこのキューにメッセージをルーティングします。拒否された場合は、代替のルートが提供され、ノードがこのキューに無限にルーティングされます。他のすべてのノードは、提示時に選択されたキューにルーティングされます。メッセージがキューに到着すると、通常の単一サーバーメッセージグループセマンティクスが引き継がれ、メッセージがそのキューのコンシューマーに割り当てられます。
単一のローカルハンドラーがある単一障害点が存在することに気づいたかもしれません。このノードがクラッシュした場合は、決定を行うことができなくなります。送信されたメッセージは、配信されず、例外がスローされます。これを回避するには、ローカルハンドラーは別のバックアップノードでレプリケートします。また、バックアップノードを作成し、同じローカルハンドラーで設定します。

26.3.1. クラスタリングされたグループ化のベストプラクティス

クラスタリングされたグループ化を使用する場合は、いくつかのベストプラクティスに従う必要があります。
  1. 可能な場合は、コンシューマーがさまざまなノードで均等に分散されるようにします。これは、コンシューマーを定期的に作成し、閉じる場合にのみ問題になります。メッセージは割り当てられた同じキュー常にルーティングされるため、このキューからコンシューマーを削除すると、コンシューマーがなくなり、キューがメッセージを受信し続けることになります。コンシューマーを閉じないようにするか、常にたくさんのコンシューマーがあるようにします。つまり、3 つのノードがある場合は、3 つのコンシューマーを用意します。
  2. 可能な場合は、耐性キューを使用します。グループがキューにバインドされたときにキューが削除された場合は、他のノードがメッセージをキューにルーティングすることを試行できます。これは、メッセージを送信するセッションでキューが削除されるようにすることにより回避できます。つまり、テキストメッセージが送信された場合、メッセージはキューが削除されたノードに送信され、新しい提示が適切に行わなわれるようになります。または、異なるグループ ID を使用して開始することもできます。
  3. 常に、ローカルグループ化ハンドラーを持つノードがレプリケートされるようにしてください。つまり、グループ化はフェイルオーバーで引き続き実行できます。

第27章 事前承認モード

JMS は、次の 3 つの承認モードを指定します。
  • AUTO_ACKNOWLEDGE
  • CLIENT_ACKNOWLEDGE
  • DUPS_OK_ACKNOWLEDGE
ただし、JMS によってサポートされない別のケースがあります。場合によっては、障害発生時にメッセージを失い、メッセージをクライアントに配信する前にサーバーでメッセージを承認することが適切なことがあります。
HornetQ では、この特別なモードは pre-acknowledge モードと呼ばれます。
配信前にサーバーで承認する欠点は、サーバーでメッセージを承認してからメッセージがクライアントに配信されるまでにシステムがクラッシュした場合に、メッセージが失われることです。
メッセージングのケースに応じて、事前承認モードでは、メッセージが失われることがある代わりにネットワークトラフィックと CPU の負荷を回避できます。
事前承認の使用例は、株価更新メッセージです。これらのメッセージでは、クラッシュ時にメッセージを失うことが適切な場合があります。これは、次の株価更新メッセージがすぐに到着し、前の株価を上書きするためです。

注記

事前承認モードを使用する場合は、消費されるメッセージのトランザクションセマンティクスが失われます。これは、メッセージが、トランザクションをコミットしたときではなく、サーバーで最初に承認されるためです。

27.1. PRE_ACKNOWLEDGE の使用

これは、以下のように JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml ファイルの connection factory で設定できます。
<connection-factory name="NettyConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>
   </entries>
   <pre-acknowledge>true</pre-acknowledge>
</connection-factory>
または、JMS API で事前承認モードを使用するために、HornetQSession.PRE_ACKNOWLEDGE 定数で JMS セッションを作成します。
// messages will be acknowledge on the server *before* being delivered to the client
Session session = connection.createSession(false, HornetQSession.PRE_ACKNOWLEDGE);
または、セッターメソッドを使用して、HornetQConnectionFactory インストールで直接事前承認を設定できます。
コア API で事前承認を使用するために、セッターメソッドを使用して ClientSessionFactory インスタンスで直接これを設定できます。

第28章 管理

HornetQ には、拡張管理 API が含まれ、ユーザーは以下のことを行えます。
  • サーバー設定の変更。
  • 新しいリソースの作成 (たとえば、JMS キューやトピック)。
  • これらのリソースの検査 (たとえば、キューに現在保持されているメッセージの数)。
  • これらのリソースとの対話 (つまり、キューからのメッセージの削除)。
すべての操作で、クライアントが HornetQ を管理できます。また、クライアントは管理通知をサブスクライブできます。
HornetQ を管理するには 3 つの方法があります。
  • JMX の使用。JMX は、Java アプリケーションを管理する標準的な方法です。
  • コア API の使用。管理操作はコアメッセージを使用して HornetQ サーバーに送信されます。
  • JMS API の使用。管理操作は JMS メッセージを使用して HornetQ サーバーに送信されます。
HornetQ を管理するために 3 つの異なる方法がありますが、各 API は同じ機能をサポートします。JMX を使用してリソースを管理できる場合は、コアメッセージまたは JMS メッセージを使用して同じ結果を達成できます。
どれが最適かを決定する選択は要件、アプリケーション設定、および環境に基づきます。

28.1. 管理 API

管理 API は、管理操作を呼び出す方法に関係なく同じです。管理対象リソースの各タイプに対して、呼び出すことができる対象を定義する Java インターフェースが存在します。
HornetQ は、2 つのパッケージで管理対象リソースを公開します。
  • コアリソースは、org.hornetq.api.core.management パッケージに含まれます。
  • JMS リソースは org.hornetq.api.jms.management パッケージに含まれます。
管理操作を呼び出す方法は、JMX、コアメッセージ、または JMS を使用するかどうかによって異なります。

注記

いくつかの管理操作では、フィルターパラメーターによって、操作で呼び出すメッセージを選択する必要があります。null または空の文字列を渡すと、管理操作がすべてのメッセージで実行されます。

28.1.1. コア管理 API

HornetQ は、コアリソースを管理するコア管理 API を定義します。概要を以下に示します。

28.1.1.1. コアサーバー管理

キューのリスト、作成、デプロイ、および破棄
デプロイされたコアキューのリストは、getQueueNames() メソッドを使用して取得できます。
コアキューは、管理操作を使用して作成または破棄できます。
  • createQueue()
  • deployQueue()
  • HornetQServerControldestroyQueue() (ObjectName org.hornetq:module=Core,type=Server またはリソース名 core.server を使用)
キューがすでに存在し、deployQueue が何も行わない場合は、createQueue が失敗します。
キューの一時停止と再開
QueueControl は、基礎となるキューを一時停止および再開できます。キューが一時停止した場合、キューはメッセージを受け取りますが、配信しません。キューが再開された場合に、キューに格納されたメッセージの配信が開始されます。
リモート接続をリストし、閉じる
クライアントリモートアドレスは、listRemoteAddresses() を使用して取得できます。closeConnectionsForAddress() メソッドを使用してリモートアドレスに関連付けられた接続を閉じることもできます。
または、接続 ID を listConnectionIDs() を使用してリストしたり、該当する接続 ID のすべてのセッションを listSessions() を使用してリストしたりできます。
トランザクションヒューリスティック操作
サーバークラッシュの場合に、一部のトランザクションでは、サーバーの再起動時に手動で作業する必要があることがあります。listPreparedTransactions() メソッドは、準備状態のトランザクションをリストします (トランザクションは不透明な Base64 文字列として表されます)。該当する準備状態のトランザクションをコミットまたはロールバックするために、commitPreparedTransaction() または rollbackPreparedTransaction() メソッドを使用してヒューリスティックトランザクションを解決できます。ヒューリスティックに完了したトランザクションは、listHeuristicCommittedTransactions() メソッドと listHeuristicRolledBackTransactions メソッドを使用してリストできます。
メッセージカウンターの有効化とリセット
メッセージカウンターは、enableMessageCounters() または disableMessageCounters() メソッドを使用して有効化または無効化できます。メッセージカウンターをリセットするために、resetAllMessageCounters() および resetAllMessageCounterHistories() メソッドを呼び出すことができます。
サーバー設定と属性の取得
HornetQServerControl は、HornetQ サーバー設定をそのすべての属性を介して公開します (たとえば、サーバーのバージョンを取得する getVersion() メソッドなど)。

28.1.1.2. コアアドレス管理

コアアドレスは、AddressControl クラス (ObjectName org.hornetq:module=Core,type=Address,name="<the address name>" またはリソース名 core.address.<the address name> と使用) を使用して管理できます。
アドレスのロールとパーミッションの変更
addRole() または removeRole() メソッドを使用してキューに関連付けられたロールを追加または削除できます。キューに関連付けられたすべてのロールはgetRoles() メソッドでリストできます。

28.1.1.3. コアキュー管理

たくさんのコア管理 API はコアキューを取り扱います。QueueControl クラスは、コアキュー管理操作を定義します (ObjectName org.hornetq:module=Core,type=Queue,address="<the bound address>",name="<the queue name>" またはリソース名 core.queue.<the queue name> と使用)。
キューに関するほとんどの管理操作は単一のメッセージ ID (たとえば、単一のメッセージを削除するために) またはフィルター (たとえば、該当するプロパティーのすべてのメッセージを期限切れにするために) を取得します。
デッドレターアドレスの期限切れ、デッドレターアドレスへの送信、メッセージの移動
メッセージは、expireMessages() メソッドを使用してキューで期限切れにすることができます。期限が切れたアドレスが定義された場合、メッセージはそのアドレスに送信され、送信されない場合は破棄されます。キューの期限切れのアドレスは setExpiryAddress() メソッドで設定できます。
また、メッセージは sendMessagesToDeadLetterAddress() メソッドを使用してデッドレターアドレスに送信することもできます。これは、デッドレターアドレスに送信されたメッセージの数を返します。デッドレターアドレスが定義されない場合、メッセージはキューから削除され、破棄されます。キューのデッドレターアドレスは、setDeadLetterAddress() メソッドで設定できます。
メッセージは、moveMessages() メソッドを使用してあるキューから別のキューに移動することもできます。
メッセージのリストと削除
メッセージは、listMessages() メソッドを使用してキューからリストできます。このメソッドは Map のアレイを返します。各メッセージに対して 1 つの Map が存在します。
メッセージは、単一のメッセージ ID バリアントに対して boolean またはフィルターバリアントに対して削除済みメッセージの数を返す removeMessages() メソッドを使用してキューから削除することもできます。removeMessages() メソッドは filter 引数を受け取ってフィルタリングされたメッセージのみを削除します。フィルターを空の文字列に設定すると、すべてのメッセージが削除されます。
メッセージのカウント
キュー内のメッセージの数は、getMessageCount() メソッドにより返されます。また、countMessages() は、該当するフィルターに一致したキュー内のメッセージの数を返します。
メッセージ優先度の変更
メッセージ優先度は、単一のメッセージ ID バリアントに対して boolean、フィルターバリアントに対して更新済みメッセージの数を返す changeMessagesPriority() メソッドを使用して変更できます。
メッセージカウンター
メッセージカウンターは、listMessageCounter()listMessageCounterHistory() メソッドでキューに対してリストできます (「メッセージカウンター」 を参照)。また、メッセージカウンターは、resetMessageCounter() メソッドを使用して単一のキューに対してリセットできます。
キュー属性の取得
QueueControl は、属性を介してコアキューの設定を公開します (たとえば、キューのフィルターを取得する getFilter() (作成された場合) やキューが耐性かどうかを認識する isDurable() など)。
キューの一時停止と再開
QueueControl は、基礎となるキューを一時停止および再開できます。キューが一時停止した場合、キューはメッセージを受け取りますが、配信しません。キューが再開された場合に、キューに格納されたメッセージの配信が開始されます。

28.1.1.4. 他のコアリソース管理

HornetQ では、ユーザーがリモートリソース (アクセプター、迂回、ブリッジなど) を開始および停止できるため、サーバーを完全に停止せずにオフラインにできます (たとえば、ヒューリスティックトランザクションの解決など他の管理操作を実行する必要がある場合)。これらのリソースは以下のとおりです。
アクセプター
アクセプターは、AcceptorControl クラスの start() または stop() メソッドを使用して開始または停止できます (org.hornetq:module=Core,type=Acceptor,name="<the acceptor name>" またはリソース名 core.acceptor.<the address name> とともに使用)。アクセプターのパラメーターは、AcceptorControl 属性を使用して取得できます (「アクセプターについて」 を参照)。
迂回
迂回は DivertControl クラスの start() または stop() を使用して開始または停止できます (ObjectName org.hornetq:module=Core,type=Divert,name=<the divert name> またはリソース名 core.divert.<the divert name> とともに使用)。迂回パラメーターは、DivertControl 属性を使用して取得できます (33章メッセージフローの迂回と分割 を参照)。
ブリッジ
これらは、BridgeControl クラスの start() (resp. stop()) メソッドを使用して開始または停止できます (ObjectName org.hornetq:module=Core,type=Bridge,name="<the bridge name>" またはリソース名 core.bridge.<the bridge name> とともに使用)。ブリッジパラメーターは、BridgeControl 属性を使用して取得できます (34章コアブリッジ を参照)。
ブロードキャストグループ
ブロードキャストグループは、BroadcastGroupControl クラスの start() または stop() を使用して開始または停止できます (ObjectName org.hornetq:module=Core,type=BroadcastGroup,name="<the broadcast group name>" またはリソース名 core.broadcastgroup.<the broadcast group name> とともに使用)。ブロードキャストグループパラメーターは、BroadcastGroupControl 属性を使用して取得できます (「ブロードキャストグループ」 を参照)。
検出グループ
これらは、DiscoveryGroupControl クラスの start() または stop() めそっどを使用して開始または停止できます (ObjectName org.hornetq:module=Core,type=DiscoveryGroup,name="<the discovery group name>" またはリソース名 core.discovery.<the discovery group name> とともに使用)。検出グループパラメーターは、DiscoveryGroupControl 属性を使用して取得できます (「検出グループ」 を参照)。
クラスター接続
これらは、ClusterConnectionControl クラスの start() または stop() メソッドを使用して開始または停止できます (ObjectName org.hornetq:module=Core,type=ClusterConnection,name="<the cluster connection name>" またはリソース名 core.clusterconnection.<the cluster connection name> とともに使用)。クラスター接続パラメーターは、ClusterConnectionControl 属性を使用して取得できます (「クラスター接続の設定」 を参照)。

28.1.2. JMS 管理 API

HornetQ は、JMS 管理オブジェクト (つまり、JMS キュー、トピック、および接続ファクトリー) を管理する JMS 管理 API を定義します。

28.1.2.1. JMS サーバー管理

JMS リソース (接続ファクトリーおよび宛先) は、JMSServerControl クラスを使用して作成できます (ObjectName org.hornetq:module=JMS,type=Server またはリソース名 jms.server とともに使用)。
接続ファクトリーのリスト、作成、破棄
デプロイされた接続ファクトリーの名前は、getConnectionFactoryNames() メソッドにより取得できます。
JMS 接続ファクトリーは、createConnectionFactory() メソッドまたは destroyConnectionFactory() メソッドを使用して作成または破棄できます。これらの接続ファクトリーは、JNDI にバインドされ、JMS クライアントはこれらをルックアップできます。接続ファクトリーを作成するためにグラフィカルコンソールが使用された場合は、トランザクションパラメーターがテキストフィールド入力で、キー = 値 (つまり、key1=10, key2="value", key3=false) のカンマ区切りのリストとして指定されます。複数のトランスポートが定義された場合は、キーと値のペアを中かっこで囲む必要があります (たとえば、{key=10}, {key=20})。この場合、最初の key は最初のトランスポート設定に関連付けられ、2 つ目の key は 2 つ目のトランスポート設定に関連付けられます (トランスポートパラメーターのリストについては、14章トランスポートの設定 を参照してください)。
キューのリスト、作成、破棄
デプロイされた JMS キューの名前は、getQueueNames() メソッドを使用して取得できます。
JMS キューは、createQueue() メソッドまたは destroyQueue() メソッドを使用して作成または破棄できます。これらのキューは JNDI にバインドされるため、JMS クライアントはこれらをルックアップできます。
トピックのリスト、作成、破棄
デプロイされたトピックの名前は、getTopicNames() メソッドを使用して取得できます。
JMS トピックは、createTopic() または destroyTopic() メソッドを使用して作成または破棄できます。これらのトピックは JNDI にバインドされるため、JMS クライアントはこれらをルックアップできます。
リモート接続をリストし、閉じる
JMS クライアントリモートアドレスは、listRemoteAddresses() を使用して取得できます。また、closeConnectionsForAddress() メソッドを使用してリモートアドレスに関連付けられた接続を閉じることもできます。
または、接続 ID を listConnectionIDs() を使用してリストしたり、該当する接続 ID のすべてのセッションを listSessions() を使用してリストしたりできます。

28.1.2.2. JMS ConnectionFactory 管理

JMS 接続ファクトリーは、ConnectionFactoryControl クラスを使用して管理できます (ObjectName org.hornetq:module=JMS,type=ConnectionFactory,name="<the connection factory name>" またはリソース名 jms.connectionfactory.<the connection factory name> とともに使用)。
接続ファクトリー属性の取得
ConnectionFactoryControl は、JMS ConnectionFactory 設定をその属性を介して公開します (つまり、フロー制御に対してコンシューマーウィンドウサイズを取得するために getConsumerWindowSize()、非耐性メッセージの送信時に接続ファクトリーから作成されたプロデューサーがブロックされるかどうかを認識するために isBlockOnNonDurableSend())。

28.1.2.3. JMS キュー管理

JMS キューは、JMSQueueControl クラスを使用して管理できます (ObjectName org.hornetq:module=JMS,type=Queue,name="<the queue name>" またはリソース名 jms.queue.<the queue name> とともに使用)。
JMS キューに関する管理操作は、コアキューに関する管理操作と非常に似ています。
デッドレターアドレスの期限切れ、デッドレターアドレスへの送信、メッセージの移動
メッセージは、expireMessages() メソッドを使用してキューで期限切れにすることができます。期限が切れたアドレスが定義された場合、メッセージはそのアドレスに送信され、送信されない場合は破棄されます。キューの期限切れのアドレスは setExpiryAddress() メソッドで設定できます。
また、メッセージは sendMessagesToDeadLetterAddress() メソッドを使用してデッドレターアドレスに送信することもできます。これは、デッドレターアドレスに送信されたメッセージの数を返します。デッドレターアドレスが定義されない場合、メッセージはキューから削除され、破棄されます。キューのデッドレターアドレスは、setDeadLetterAddress() メソッドで設定できます。
メッセージは、moveMessages() メソッドを使用してあるキューから別のキューに移動することもできます。
メッセージのリストと削除
メッセージは、listMessages() メソッドを使用してキューからリストできます。このメソッドは Map のアレイを返します。各メッセージに対して 1 つの Map が存在します。
メッセージは、単一のメッセージ ID バリアントに対して boolean またはフィルターバリアントに対して削除済みメッセージの数を返す removeMessages() メソッドを使用してキューから削除することもできます。removeMessages() メソッドは filter 引数を受け取ってフィルタリングされたメッセージのみを実際に削除します。フィルターを空の文字列に設定すると、すべてのメッセージが削除されます。
メッセージのカウント
キュー内のメッセージの数は、getMessageCount() メソッドにより返されます。また、countMessages() は、該当するフィルターに一致したキュー内のメッセージの数を返します。
メッセージ優先度の変更
メッセージ優先度は、単一のメッセージ ID バリアントに対して boolean、フィルターバリアントに対して更新済みメッセージの数を返す changeMessagesPriority() メソッドを使用して変更できます。
メッセージカウンター
メッセージカウンターは、listMessageCounter()listMessageCounterHistory() メソッドでキューに対してリストできます (「メッセージカウンター」 を参照)。
キュー属性の取得
JMSQueueControl は、JMS キューの設定をその属性を介して公開します (たとえば、キューが一時的かどうかを識別するために isTemporary()、キューが耐性かどうかを識別するために isDurable())。
キューの一時停止と再開
JMSQueueControl は、基礎となるキューを一時停止および再開できます。キューが一時停止した場合、キューはメッセージを受け取りますが、配信しません。キューが再開された場合に、キューに格納されたメッセージが配信されます。

28.1.2.4. JMS トピック管理

JMS トピックは、TopicControl クラスを使用して管理できます (ObjectName org.hornetq:module=JMS,type=Topic,name="<the topic name>" またはリソース名 jms.topic.<the topic name> とともに使用)。
サブスクリプションおよびメッセージのリスト
JMS トピックサブスクリプションは、listAllSubscriptions()listDurableSubscriptions()listNonDurableSubscriptions() メソッドを使用してリストできます。これらのメソッドは、サブスクリプション情報 (サブスクリプション名、クライアント ID、耐性、メッセージ数など) を表す Object のアレイを返します。また、listMessagesForSubscription() メソッドを使用して該当するサブスクリプションの JMS メッセージをリストすることもできます。
サブスクリプションのドロップ
耐性サブスクリプションは、dropDurableSubscription() メソッドを使用してトピックからドロップできます。
サブスクリプションメッセージのカウント
countMessagesForSubscription() メソッドは、該当するサブスクリプションに対して保持されたメッセージの数を調べるために使用できます (セレクターに一致するメッセージの数を調べるためのオプションのメッセージセレクターがあります)。

28.2. JMX を介した管理の使用

HornetQ は、JMX を使用して管理できます。
管理 API は、MBean インターフェースを使用して HornetQ によって公開されます。HornetQ は、ドメイン org.hornetq でリソースを登録します。
たとえば、JMS キューexampleQueue を管理する ObjectName は、以下のようになります。
org.hornetq:module=JMS,type=Queue,name="exampleQueue"
MBean は以下のようになります。
org.hornetq.api.jms.management.JMSQueueControl
MBean ObjectName は、ヘルパークラスorg.hornetq.api.core.management.ObjectNameBuilder を使用して構築されます。また、jconsole を使用して管理する MBean のObjectName を見つけることもできます。
JMX を使用した HornetQ の管理は、JMX を使用した Java アプリケーションの管理と同じです。これは、リフレクションによって、または MBean のプロキシを作成することによって実行できます。

28.2.1. JMX の設定

デフォルトでは、JMX は、HornetQ を管理するために有効になります。これは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmljmx-management-enabledfalse に設定することにより無効にできます。
<!-- false to disable JMX management for HornetQ -->
<jmx-management-enabled>false</jmx-management-enabled>
JMX が有効な場合、HornetQ は、 jconsole を使用してローカルで管理できます。

注記

JMX に対するリモート接続は、セキュリティー上の理由からデフォルトで有効になりません。システムプロパティーは、run.sh または run.bat スクリプトで設定する必要があります。
デフォルトでは、HornetQ サーバーは JMX ドメイン "org.hornetq" を使用します。複数の HornetQ サーバーを同じ MBeanServer から管理するために、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmljmx-domain を設定することにより、各 HornetQ サーバーに対して JMX ドメインを設定できます。
<!-- use a specific JMX domain for HornetQ MBeans -->
<jmx-domain>my.org.hornetq</jmx-domain>

28.3. コア API を介した管理の使用

HornetQ のコア管理 API は、コアメッセージを管理アドレス に送信することによって呼び出されます。
管理メッセージは、サーバーが管理 API と対話するために理解する必要があるよく知られたプロパティーを持つ通常のコアメッセージです。
  • 管理対象リソースの名前
  • 管理操作の名前
  • 管理操作のパラメーター
管理メッセージが管理アドレスに送信された場合、HornetQ は、次のようにメッセージを処理します。
  • 情報を抽出します。
  • 管理対象リソースに対する操作を呼び出します。
  • 管理メッセージの返信先アドレスに管理返信を送信します。
返信先アドレスに送信された管理返信は、org.hornetq.core.client.impl.ClientMessageImpl.REPLYTO_HEADER_NAME パラメーターにより制御されます。
ClientConsumer は、管理返信を消費し、返信のボディーに保存された操作 (存在する場合) の結果を取得するために使用できます。移植性のために、結果は Java Serialization ではなく JSON 文字列で返されます。org.hornetq.api.core.management.ManagementHelper は、JSON 文字列を Java オブジェクトに変換するために使用できます。
これらの手順は、コアメッセージを使用して管理操作を呼び出すことを簡単にするために単純化できます。

手順28.1 管理操作の呼び出し

  1. 手順 1

    ClientRequestor を作成して、メッセージを管理アドレスに送信し、返信を受け取ります。
  2. 手順 2

    ClientMessage を作成します。
  3. 手順 3

    ヘルパークラス org.hornetq.api.core.management.ManagementHelper を使用してメッセージに管理プロパティーを満たします。
  4. 手順 4

    ClientRequestor を使用してメッセージを送信します。
  5. 手順 5

    ヘルパークラス org.hornetq.api.core.management.ManagementHelper を使用して管理返信から操作結果を取得します。
たとえば、コアキュー exampleQueue 内のメッセージの数を調べる場合は、以下のようになります。
   ClientSession session = ...
   ClientRequestor requestor = new ClientRequestor(session, "jms.queue.hornetq.management");
   ClientMessage message = session.createMessage(false);
   ManagementHelper.putAttribute(message, "core.queue.exampleQueue", "messageCount");
   ClientMessage reply = requestor.request(m);
   int count = (Integer) ManagementHelper.getResult(reply);
   System.out.println("There are " + count + " messages in exampleQueue");
管理操作名とパラメーターは、management パッケージで定義された Java インターフェースに準拠する必要があります。
リソースの名前は、ヘルパークラス org.hornetq.api.core.management.ResourceNames を使用して構築され、わかりやすくなります(コアキュー exampleQueue に対する core.queue.exampleQueue、JMS トピック exampleTopic に対する jms.topic.exampleTopic など)。

28.3.1. コア管理の設定

管理メッセージを送信する管理アドレスは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されます。
<management-address>jms.queue.hornetq.management</management-address>
デフォルトでは、アドレスは jms.queue.hornetq.management です (この先頭には "jms.queue" が付加されるため、JMS クライアントは管理メッセージを送信することもできます)。
管理アドレスは、管理メッセージを受信および処理するために特別なユーザーパーミッション manage を必要とします。これは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml でも設定されます。
<!-- users with the admin role will be allowed to manage --> 
<!-- HornetQ using management messages        -->
<security-setting match="jms.queue.hornetq.management">
   <permission type="manage" roles="admin" />
</security-setting>

28.4. JMS を介した管理の使用

HornetQ を管理するために JMS メッセージを使用することはコア API を使用することに非常に似ています。
重要な違いは、JMS がメッセージを送信する JMS キューを必要とすることです (コア API の場合はアドレスが必要)。
管理キューは、特別なキューであり、クライアントにより直接インスタンス化する必要があります。
   Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management");
他のすべての手順はコア API の場合と同じですが、代わりに JMS API を使用します。
  1. QueueRequestor を作成して、管理アドレスにメッセージを送信し、返信を受け取ります。
  2. Message を作成します。
  3. ヘルパークラス org.hornetq.api.jms.management.JMSManagementHelper を使用してメッセージに管理プロパティーを満たします。
  4. QueueRequestor を使用してメッセージを送信します。
  5. ヘルパークラス org.hornetq.api.jms.management.JMSManagementHelper を使用して管理返信から操作結果を取得します。
たとえば、JMS キュー exampleQueue 内のメッセージの数を調べる場合は、以下のようになります。
   Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management");   
   
   QueueSession session = ...      
   QueueRequestor requestor = new QueueRequestor(session, managementQueue);
   connection.start();
   Message message = session.createMessage();
   JMSManagementHelper.putAttribute(message, "jms.queue.exampleQueue", "messageCount");
   Message reply = requestor.request(message);
   int count = (Integer)JMSManagementHelper.getResult(reply);
   System.out.println("There are " + count + " messages in exampleQueue");

28.4.1. JMS 管理の設定

管理に JMS が使用された場合であっても、コア API が使用された場合であっても、設定手順は同じです (「コア管理の設定」 を参照)。

28.5. 管理通知

HornetQ は、通知を送信してリスナーに、関連するイベント (新しいリソースの作成やセキュリティー違反など) を知らせます。
これらの通知は、以下の 3 つの異なる方法で取得できます。
  • JMX 通知
  • コアメッセージ
  • JMS メッセージ

28.5.1. JMX 通知

JMX が有効な場合 (「JMX の設定」 を参照)、JMX 通知は 2 つの MBean をサブスクライブすることによって取得できます。
  • コアリソースに関する通知の場合は org.hornetq:module=Core,type=Server
  • JMS リソースに関する通知の場合は org.hornetq:module=JMS,type=Server

28.5.2. コアメッセージ通知

HornetQ は、管理通知アドレスを定義します。コアキューは、このアドレスにバインドでき、クライアントは管理通知をコアメッセージとして受け取ります。
管理通知を受け取りたいコアクライアントは、管理通知アドレスにバインドされたコアキューを作成する必要があります。これは、キューから通知を受け取ることができます。
通知メッセージは、通知に対応する追加のプロパティーを通常のコアメッセージです (タイプ (存在する場合)、関係するリソースなど)。
通知は通常のコアメッセージであるため、メッセージセレクターを使用して通知をフィルタリングし、サーバーから送信されたすべての通知のサブセットのみを受け取ることができます。

28.5.2.1. コア管理通知アドレスの設定

管理通知を受け取る管理通知アドレスは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されます。
<management-notification-address>hornetq.notifications</management-notification-address>
デフォルトでは、アドレスは hornetq.notifications です。

28.5.3. JMS メッセージ通知

HornetQ 通知は、JMS メッセージを使用して取得することもできます。
これは、Core API を使用して通知を受信することに似ていますが、重要な違いは、JMS がメッセージ (理想的にはトピック) を受信するために JMS 宛先が必要なことです。
JMS宛先を使用して管理通知を受信するには、jms.queue (JMS キューの場合) または jms.topic (JMS トピックの場合) で開始するサーバーの管理通知アドレスを変更する必要があります。
<!-- notifications will be consumed from "notificationsTopic" JMS Topic -->
<management-notification-address>jms.topic.notificationsTopic</management-notification-address>
通知トピックが作成されたら、それからメッセージを受け取ることができます。または以下のように MessageListener を設定できます。
   Topic notificationsTopic = HornetQJMSClient.createTopic("notificationsTopic");

   Session session = ...
   MessageConsumer notificationConsumer = session.createConsumer(notificationsTopic);
      notificationConsumer.setMessageListener(new MessageListener()
      {
         public void onMessage(Message notif)
         {
            System.out.println("------------------------");
            System.out.println("Received notification:");
            try
            {
               Enumeration propertyNames = notif.getPropertyNames();
               while (propertyNames.hasMoreElements())
               {
                  String propertyName = (String)propertyNames.nextElement();
                  System.out.format("  %s: %s
", propertyName, notif.getObjectProperty(propertyName));
               }
            }
            catch (JMSException e)
            {
            }
            System.out.println("------------------------");
         }            
      });

28.6. メッセージカウンター

メッセージカウンターは、HornetQ がキューメトリックスの履歴を保持する場合にキューに関する一定の時間の情報を取得するために使用できます。
これらは、キューのトレンドを示すために使用できます。たとえば、管理 API を使用する場合は、キュー内のメッセージの数を一定の間隔で問い合わせることができます。また、JMX コンソールを使用してこの情報を参照したり、コア API (org.hornetq.api.core.management.MessageCounterInfo) を使用してこの情報を抽出したりできます。
ただし、キューが使用される場合は、これで十分ではありません。誰もキューに対してメッセージを送受信しないため、またはキューに送信されるメッセージの数がキューから消費されるメッセージの数と同じであるため、メッセージの数は、一定になることがあります。両方のケースでキュー内のメッセージの数は、同じになりますが、その使用は異なります。
メッセージカウンターは、キューに関する追加情報を提供します。
count
サーバーが起動された以降にキューに追加されたメッセージの合計数。
countDelta
最後のメッセージカウンターが更新された以降にキューに追加されたメッセージの数。
depth
キュー内にあるメッセージの現在の数。
depthDelta
最後のメッセージカウンターが更新された以降にキューに対して追加または削除されたメッセージの合計数。たとえば、depthDelta-10 に等しい場合、合計で 10 個のメッセージがキューから削除されたことを意味します。
lastAddTimestamp
メッセージが最後にキューに追加されたときのタイムスタンプ。
udpateTimestamp
最後のメッセージカウンター更新のタイムスタンプ。

28.6.1. メッセージカウンターの設定

メッセージカウンターは、メモリーに悪い影響を与えることがあるため、デフォルトで無効になります。
メッセージカウンターを無効にするには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml でメッセージカウンターを true に設定します。
<message-counter-enabled>true</message-counter-enabled>
メッセージカウンターは、キューメトリックスの履歴 (デフォルトで 10 日間) を保持し、すべてのキューを一定の間隔 (デフォルトで 10 秒間) でサンプリングします。メッセージカウンターが有効な場合、これらの値は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のメッセージング使用ケースを満たすように設定する必要があります。
<!-- keep history for a week -->
<message-counter-max-day-history>7</message-counter-max-day-history>        
<!-- sample the queues every minute (60000ms) -->
<message-counter-sample-period>60000</message-counter-sample-period>
メッセージカウンターは、管理 API を使用して取得できます。たとえば、JMX を使用して JMS キューに関するメッセージカウンターを取得します。
// retrieve a connection to HornetQ's MBeanServer
MBeanServerConnection mbsc = ...
JMSQueueControlMBean queueControl = (JMSQueueControl)MBeanServerInvocationHandler.newProxyInstance(mbsc,
   on,
   JMSQueueControl.class,
   false);
// message counters are retrieved as a JSON String                                                                                                      
String counters = queueControl.listMessageCounter();
// use the MessageCounterInfo helper class to manipulate message counters more easily
MessageCounterInfo messageCounter = MessageCounterInfo.fromJSON(counters);         
System.out.format("%s message(s) in the queue (since last sample: %s)
",
   counter.getDepth(),
   counter.getDepthDelta());

28.7. 管理コンソールを使用して HornetQ リソースを管理

JBoss Enterprise Application Platform 内の管理コンソールを使用して HornetQ リソースを作成および設定できます。
管理コンソールでは、宛先 (JMS トピックおよびキュー) と JMS 接続ファクトリーを作成できます。
管理コンソールにログインしたら、左側のツリーに JMS Manager アイテムが表示されます。すべての HornetQ リソースは、これを使用して設定されます。これは JMS キュー、トピック、および接続ファクトリーの子アイテムを持ちます。各ノードをクリックすると、現在利用可能なリソースが表示されます。以下の項では、各リソースを作成および設定する方法を順番に説明します。

28.7.1. JMS キュー

新しい JMS キューを作成するには、JMS キューアイテムをクリックして利用可能なキューを表示します。右側のパネルには、[Add a New Resource] ボタンが表示されます。このボタンをクリックし、デフォルト (JMS キュー) のテンプレートを選択します。[Continue] をクリックします。ここで入力する重要な情報は、キューの名前とキューの JNDI 名です。JNDI 名はクライアントから JNDI 内のキューをルックアップするために使用します。ほとんどのキューでは、これは、提供する必要がある唯一の情報です。他のものについては適切なデフォルト値が提供されます。また、下部付近にはセキュリティーロールセクションがあります。このキューにロールを提供しない場合は、サーバーのデフォルトセキュリティー設定が使用されます。キューを作成した後で、これらは設定に示されます。名前と JNDI 名を除くすべての値は、管理コンソールでキューをクリックした後に設定タブを使用して変更できます。以下の項では、これらについて詳しく説明します。
設定を強調表示すると、以下の画面が示されます。
名前と JNDI 名は変更できません。これらの名前を変更する場合は、キューを適切な設定で再び作成します。特定のアドレスに関する、セキュリティーロールを除く他の設定オプションは、アドレス設定に関係します。デフォルトのアドレス設定は、サーバー設定から取得されます。これらいずれかの設定を変更したり、コンソールでキューを作成したりする場合は、新しいアドレス設定エントリが追加されます。アドレス設定の詳細については、「アドレス設定を介してキューを設定」 を参照してください。
キューを削除するには、メイン JMS キュー画面のキュー名の横にある [Delete] ボタンをクリックします。これにより、キューアドレスに対して以前に作成されたすべてのアドレス設定またはセキュリティー設定も削除されます。
設定オプションの最後の部分は、セキュリティーロールです。作成時に何も提供されない場合は、サーバーのデフォルトのセキュリティー設定が示されます。これらが変更または更新された場合は、このキューのアドレスに対して新しいセキュリティー設定が作成されます。セキュリティー設定の詳細については、29章セキュリティ を参照してください。
このキューに対する統計情報はメトリックスタブを使用して参照できます。これは、メッセージ数やコンシューマー数などの統計情報を示します。
操作は、制御タブでキューに対して実行できます。この場合、キューを開始および停止したり、キューに対してリスト、移動、期限切れ設定、および削除を行ったり、他の役に立つ操作を実行したりできます。操作を呼び出すには、必要な操作のボタンをクリックします。この結果、操作のパラメーターを設定できる画面に移動します。設定したら、[OK] ボタンをクリックして操作を呼び出します。結果は画面の下部に表示されます。

28.7.2. JMS トピック

JMS トピックの作成と設定は、キューの作成とほとんど同じです。唯一の違いは、設定が、サブスクリプションを表すキューに適用されることです。

28.7.3. JMS 接続ファクトリー

接続ファクトリーを作成する形式は JMS キューおよびトピックに似ています。接続ファクトリーのすべての設定のリストについては、「hornetq-jms.xml」 を参照してください。

第29章 セキュリティ

本章では、HornetQ でセキュリティがどのように動作するかについてとセキュリティの設定方法について説明します。
パフォーマンス上の理由から、セキュリティはキャッシュされ、定期的に検証されます。この期間を変更するには、プロパティ security-invalidation-interval (ミリ秒単位) を設定します。デフォルト値は 10000 ms です。

警告

セキュリティは、本番稼働システムのセキュリティが適切に設定された後に高くなるようデフォルトで有効になります。JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルで、明示的に security-enabled プロパティを false に設定することによりセキュリティを完全に無効にできます。本番稼働環境にこの方法を使用することは強く推奨されません。

29.1. アドレスに対するロールベースセキュリティ

HornetQ には、アドレスに基づいてセキュリティをキューに適用する柔軟なロールベースセキュリティモデルが含まれます。
7章コアの使用 で説明されたように、HornetQ コアは主にアドレスにバインドされたキューのセットから構成されます。メッセージはアドレスに送信され、サーバーはそのアドレスにバインドされたキューのセットをルックアップします。次に、サーバーはメッセージをキューのこれらのセットにルーティングします。
HornetQ では、アドレスに基づいてキューに対してパーミッションセットを定義できます。アドレスの完全一致を使用したり、ワイルドカード文字 '#' と '*' を使用してワイルドカード一致を使用したりできます。
アドレスに一致するキューセットに対して 7 つの異なるパーミッションを割り当てることができます。これらのパーミッションは以下のとおりです。
createDurableQueue
このパーミッションでは、ユーザーが、一致するアドレスに基づいて耐性キューを作成できます。
deleteDurableQueue
このパーミッションでは、ユーザーが、一致するアドレスに基づいて耐性キューを削除できます。
createNonDurableQueue
このパーミッションでは、ユーザーが、一致するアドレスに基づいて非耐性キューを作成できます。
deleteNonDurableQueue
このパーミッションでは、ユーザーが、一致するアドレスに基づいて非耐性キューを削除できます。
send
このパーミッションでは、ユーザーが、一致するアドレスにメッセージを送信できます。
consume
このパーミッションでは、ユーザーが、一致するアドレスにバインドされたキューからメッセージを消費できます。
manage
このパーミッションでは、管理メッセージを管理アドレスに送信することにより、ユーザーが管理操作を呼び出すことができます。
各パーミッションに対して、そのパーミッションが付与されたロールのリストが指定されます。ユーザーがこれらいずれかのロールを持つ場合、ユーザーには、アドレスセットに対するこのパーミッションが付与されます。
セキュリティブロック例は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で記述されています。
<security-setting match="globalqueues.europe.#">
   <permission type="createDurableQueue" roles="admin"/>
   <permission type="deleteDurableQueue" roles="admin"/>
   <permission type="createNonDurableQueue" roles="admin, guest, europe-users"/>
   <permission type="deleteNonDurableQueue" roles="admin, guest, europe-users"/>
   <permission type="send" roles="admin, europe-users"/>
   <permission type="consume" roles="admin, europe-users"/>
</security-setting>
'#' 文字は、"任意の単語シーケンス" を示します。単語は '.' 文字で区切られます。ワイルドカード構文の完全な説明については、11章HornetQ ワイルドカード構文について を参照をしてください。上記のセキュリティブロックは、文字列 "globalqueues.europe." で始まる任意のアドレスに適用されます。
admin ロールを持つユーザーのみが文字列 "globalqueues.europe." で始まるアドレスにバインドされた耐性キューを作成または削除できます。
ロール adminguest、または europe-users を持つユーザーは、文字列"globalqueues.europe." で始まるアドレスにバインドされた一時キューを作成または削除できます。
ロール admin または europe-users を持つユーザーは、メッセージをこれらのアドレスに送信したり、文字列 "globalqueues.europe." で始まるアドレスにバインドされたキューからメッセージを消費したりできます。
ユーザーと、ユーザーが持つロール間のマッピングは、セキュリティマネージャーによって処理されます。HornetQ には、ディスクでファイルからユーザークレデンシャルを読み取るユーザーマネージャーが同梱され、JAAS または JBoss Enterprise Application Platform セキュリティをプラグインとして使用できます。
セキュリティマネージャーの設定の詳細については、「セキュリティーマネージャーの変更」 を参照してください。
各 XML ファイルには、ゼロ以上の security-setting 要素が含まれることがあります。複数の一致がアドレスセットに適用される場合は、より具体的な一致が実行されます。
<security-setting match="globalqueues.europe.orders.#">
   <permission type="send" roles="europe-users"/>
   <permission type="consume" roles="europe-users"/>
</security-setting>
この security-setting ブロックでは、一致 'globalqueues.europe.orders.#' は以前の一致 'globalqueues.europe.#' よりもより具体的です。したがって、'globalqueues.europe.orders.#' に一致する任意のアドレスは、最後の security-setting ブロックからのみセキュリティ設定を取得します。
設定は前のブロックから継承されないことに注意してください。すべての設定は、より具体的な一致ブロックから取得されます。したがって、アドレス 'globalqueues.europe.orders.plastics' の場合、存在するパーミッションはロール europe-users に対する sendconsume だけです。パーミッション createDurableQueuedeleteDurableQueuecreateNonDurableQueuedeleteNonDurableQueue は他の security-setting ブロックから継承されません。
パーミッションを継承しないことにより、より具体的な security-setting ブロックでパーミッションを効果的に拒否できます (パーミッションを指定しません)。これ以外の場合は、アドレスのサブグループでパーミッションを拒否できません。

29.2. Secure Sockets Layer (SSL) トランスポート

メッセージングクライアントがサーバーに接続されている場合、またはサーバーが信頼できないネットワーク (ブリッジなど) を介して他のサーバーに接続されている場合、HornetQ では Secure Sockets Layer (SSL) トランスポートを使用してそのトラフィックを暗号化できます。
SSL トランスポートの詳細については、14章トランスポートの設定 を参照してください。

29.3. 基本的なユーザークレデンシャル

HornetQ には、ユーザークレデンシャル (ユーザー名とパスワード) とロール情報を hornetq-users.properties および hornetq-users.roles ファイルから読み取るセキュリティーマネージャー実装が同梱されます。これら両方のファイルは実行するプロファイル内の /conf/props/ ディレクトリに存在します。
ユーザークレデンシャルおよびロールはこれらのファイルに簡単に追加できます。
例29.1「hornetq-users.properties サンプルファイル」 and 例29.2「hornetq-users.roles サンプルファイル」 には 4 つのユーザーが含まれます。各ユーザーは .properties ファイルと .roles ファイルの両方で指定されます。
各ファイルのコメントの構文に従い、各ユーザーに一意のパスワードを割り当て、ロールを各ユーザーに割り当てて変更できる HornetQ の部分を制御します。

例29.1 hornetq-users.properties サンプルファイル

#
# user=password
#
guest=guest
tim=marmite
andy=doner_kebab
jeff=camembert

例29.2 hornetq-users.roles サンプルファイル

#
# user=role1,role2,...
#
guest=guest
tim=admin
andy=admin,guest
jeff=europe-users,guest
注意すべき最初のことは、両方のファイルで定義されたゲストユーザーです。セッションの作成時にクライアントがユーザー名/パスワードを指定しない場合、ユーザーはゲストと分類されます。この場合、これらはユーザーゲストとなり、ゲストと呼ばれるロールを持ちます。デフォルトのユーザーに対して複数のロールを指定できます。
ロール admin を持つ tim、ロール adminguest を持つ andy、ロール europe-usersguest を持つ jeff の 3 つのユーザーがあります。

29.4. セキュリティーマネージャーの変更

デフォルトのセキュリティーマネージャーを使用したくない場合は、ファイル hornetq-jboss-beans.xml を編集し、HornetQSecurityManager Bean のクラスを変更することによって別のセキュリティーマネージャーを指定できます。
HornetQ では、2 つのセキュリティーマネージャー実装を使用できます。1 つは JAAS セキュリティーマネージャーであり、もう 1 つは JBoss Enterprise Application Platform セキュリティーと対話します。または、org.hornetq.spi.core.security.HornetQSecurityManager インターフェースを実装し、ファイル hornetq-jboss-beans.xml で実装のクラス名を指定することにより、独自の実装を記述することもできます。
これら 2 つの実装については、次の 2 つの項で説明します。

29.5. JAAS セキュリティーマネージャー

JAAS (Java Authentication and Authorization Service) は、Java プラットフォームの標準部分です。これは、セキュリティー認証と承認のために一般的な API を提供し、ユーザーは事前に構築された実装をプラグインとして使用できます。
JAAS セキュリティーマネージャーが事前に構築された JAAS インフラストラクチャーと連携するよう設定するには、Bean ファイルでセキュリティーマネージャーを JAASSecurityManager として指定する必要があります。
<bean name="HornetQSecurityManager"
      class="org.hornetq.integration.jboss.security.JAASSecurityManager">
    <start ignored="true"/>
    <stop ignored="true"/>

    <property name="ConfigurationName">org.hornetq.jms.example.ExampleLoginModule</property>
    <property name="Configuration">
       <inject bean="ExampleConfiguration"/>
    </property>
    <property name="CallbackHandler">
       <inject bean="ExampleCallbackHandler"/>
    </property>
</bean>
JAAS セキュリティーマネージャーには 3 つのプロパティーを提供する必要があることに注意してください。
ConfigurationName
JAAS が使用する必要がある LoginModule 実装の名前
Configuration
JAAS により使用される Configuration 実装
CallbackHandler
ユーザー対話が必要な場合に使用する CallbackHandler 実装

29.6. HornetQ セキュリティーマネージャー

HornetQ セキュリティーマネージャーは、JBoss Enterprise Application Platform セキュリティーモデルと密接に統合されます。
このセキュリティーマネージャーのクラス名は org.hornetq.integration.jboss.security.JBossASSecurityManager です。
JBossASSecurityManager の設定方法の例は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jboss-beans.xml で説明されています。

29.6.1. クライアントログインの設定

JBoss Enterprise Application Platform はクライアントログインを許可するよう設定できます。これは、Servlet や EJB などの Java EE コンポーネントが現在のセキュリティーコンテキストでセキュリティクレデンシャルを設定し、これらがコール全体で使用される場合に有用です。
HornetQ は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jboss-beans.xmlallowClientLogin プロパティーを true (デフォルト値は false) に変更することによりメッセージを送信または消費する場合に これらの設定を使用します。これにより、HornetQ 認証は省略され、提供されたセキュリティーコンテキストが伝播されます。
HornetQ が伝播されたセキュリティーを使用して認証する必要がある場合は、allowClientLogin の他に、authoriseOnClientLogintrue に設定します。

29.7. クラスタリングのためにユーザー名/パスワードを変更

クラスター接続が正常に動作するように、クラスター内の各ノードは他のノードに対して接続を確立する必要があります。これに使用されるユーザー名/パスワードは、セキュリティーリスクを回避するためにインストールのデフォルト値から必ず変更する必要があります。
この方法については、28章管理 を参照してください。

第30章 アプリケーションサーバー統合と Java EE

HornetQ は JCA アダプターも提供するため、他の Java EE 準拠アプリケーションサーバーで HornetQ を JMS プロバイダーとして統合できます。リモート JCA アダプターを別のアプリケーションサーバーに統合する方法については、他のアプリケーションサーバーの指示を参照してください。
JCA アダプターは、基本的に Message-Driven Bean (MDB) へのメッセージのインフローと他の Java EE コンポーネント (EJB やサーブレットなど) から送信されたメッセージのアウトフローを制御します。
この項では、AS でさまざまな Java EE コンポーネントを設定する場合に背後にある基本的なことについて説明します。

30.1. Message-Driven Bean の設定

HornetQ を使用した MDB へのメッセージ配信は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar/META-INF/ra.xml ファイルの JCA アダプターで設定されます。デフォルトでは、これは、アプリケーションサーバー内で実行されている HornetQ のインスタンスから InVM コネクターを使用してメッセージを消費するゆ設定されます。設定パラメーターを調整する必要がある場合、パラメーターの詳細は 「JCA アダプターの設定」 に記載されています。
HornetQ は、デフォルトのインストールで標準的な設定を提供し、MDB がリソースアダプター宛先と宛先タイプを参照できます。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/jms-ds.xml データソースファイルは、<rar-name> ディレクティブを使用して ra.xml ファイルの宛先および宛先タイプ設定情報をリンクします。

30.1.1. Container-Managed Transaction の使用

MDB が Container-Managed Transaction (CMT) を使用している場合、メッセージの配信は、JTA トランザクションのスコープ内で行われます。このトランザクションのコミットまたはロールバックはコンテナ自体により制御されます。トランザクションがロールバックされると、メッセージ配信セマンティクスが有効になります (デフォルトでは、DLQ への送信前にメッセージを最大 10 回再配信しようとします)。アノテーションを使用する場合、これは以下のように設定されます。
@MessageDriven(name = "MDB_CMP_TxRequiredExample",
  activationConfig =
  {
    @ActivationConfigProperty
      (propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
    @ActivationConfigProperty
      (propertyName = "destination", propertyValue = "queue/testQueue")
  })
@TransactionManagement(value= TransactionManagementType.CONTAINER)
@TransactionAttribute(value= TransactionAttributeType.REQUIRED)
public class MDB_CMP_TxRequiredExample implements MessageListener
{
   public void onMessage(Message message)...
}
TransactionManagement アノテーションは、コンテナがトランザクションを管理するよう指示します。TransactionAttribute アノテーションは、この MDB に対して JTA が必要であることをコンテナに伝えます。これに対する他の有効な値は TransactionAttributeType.NOT_SUPPORTED であり、この MDB が JTA トランザクションをサポートせず、トランザクションを作成すべきでないことをコンテナに伝えます。
また、MessageDrivenContextsetRollbackOnly を呼び出すことにより、トランザクションをロールバックする必要があることをコンテナに通知することができます。このコードは以下のようになります。
@Resource
   MessageDrivenContextContext ctx;

   public void onMessage(Message message)
   {
      try
      {
         //something here fails
      }
      catch (Exception e)
      {
         ctx.setRollbackOnly();
      }
   }
作成される XA トランザクションのオーバーヘッドを必要とせず、トランザクション内で配信されたメッセージが必要な場合 (JMS リソースのみを使用している場合など) は、ローカルトランザクションを使用するよう MDB を設定できます。これは以下のように設定されます。
@MessageDriven(name = "MDB_CMP_TxLocalExample",
  activationConfig =
  {
    @ActivationConfigProperty
      (propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
    @ActivationConfigProperty
      (propertyName = "destination", propertyValue = "queue/testQueue"),
    @ActivationConfigProperty
      (propertyName = "useLocalTx", propertyValue = "true")
  })
@TransactionManagement(value = TransactionManagementType.CONTAINER)
@TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED)
public class MDB_CMP_TxLocalExample implements MessageListener
{
   public void onMessage(Message message)...
}

30.1.2. Bean-Managed Transaction の使用

Message-Driven Bean は、Bean-Managed Transaction (BMT) を使用するよう設定することもできます。この場合は、ユーザートランザクションが作成されます。これは、以下のように設定されます。
@MessageDriven(name = "MDB_BMPExample",
  activationConfig =
    {
      @ActivationConfigProperty
        (propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
      @ActivationConfigProperty
        (propertyName = "destination", propertyValue = "queue/testQueue"),
      @ActivationConfigProperty
        (propertyName = "acknowledgeMode", propertyValue = "Dups-ok-acknowledge")
    })
@TransactionManagement(value= TransactionManagementType.BEAN)
public class MDB_BMPExample implements MessageListener
{
   public void onMessage(Message message)
}
Bean-Managed Transaction を使用している場合、MDB へのメッセージ配信はユーザートランザクションのスコープ外で行われ、ユーザーによって acknowledgeMode プロパティーで指定された承認モードを使用します。この Auto-acknowledgeDups-ok-acknowledge には 2 つの許容値しかありません。メッセージ配信はトランザクションのスコープ外で行われるため、MDB 内で障害が発生するとメッセージが再配信されません。
ユーザーはトランザクションのライフサイクルを以下のように制御します。
@Resource
  MessageDrivenContext ctx;

  public void onMessage(Message message)
  {
    UserTransaction tx;
    try
    {
      TextMessage textMessage = (TextMessage)message;
      String text = textMessage.getText();
      UserTransaction tx = ctx.getUserTransaction();
      tx.begin();
      //do some stuff within the transaction
      tx.commit();
    }
    catch (Exception e)
    {
       tx.rollback();
    }
  }

30.1.3. Message-Driven Bean でのメッセージセレクターの使用

また、メッセージセレクターで MDB を使用することもできます。これを行うには、以下のようにメッセージセレクターを定義します。
@MessageDriven(name = "MDBMessageSelectorExample",
  activationConfig =
    {
      @ActivationConfigProperty
        (propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
      @ActivationConfigProperty
        (propertyName = "destination", propertyValue = "queue/testQueue"),
      @ActivationConfigProperty
        (propertyName = "messageSelector", propertyValue = "color = 'RED'")
    })
@TransactionManagement(value= TransactionManagementType.CONTAINER)
@TransactionAttribute(value= TransactionAttributeType.REQUIRED)
public class MDBMessageSelectorExample implements MessageListener
{
   public void onMessage(Message message)....
}

30.1.4. Message-Driven Bean の高可用性

Message-Driven Bean が高可用性 (HA) 環境と互換性を持つようにするには、Bean で HA んい関連する @ActivationConfigProperty を設定する必要があります。

重要

デフォルトでクラスタリングに対してすべてのサーバープロファイルが有効になるわけではありません。<clustered>true</clustered> ディレクティブが JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されていることを確認します。<clustered> ディレクティブが適切に指定されていない場合に、アクティベーションプロパティーにより、HornetQException がスローされます。クラスタリングの詳細については、36章クラスター を参照してください。
アクティベーションプロパティーを Bean の activationConfig ブロックに追加して MDB が HA 環境と互換性を持つようにします。
activationConfig =
    {
     @ActivationConfigProperty
        (propertyName = "hA", propertyValue = "true"),
    }
高可用性の詳細については、37章高可用性およびフェイルオーバー を参照してください。

30.2. Java EE コンポーネント内からメッセージを送信

JCA アダプターはメッセージを送信するためにも使用できます。使用する接続ファクトリーはデフォルトで JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/jms-ds.xml ファイルで設定され、java:/JmsXA に対してマッピングされます。
Java EE コンポーネント内からこれを使用して、メッセージ送信が、コンポーネントにより使用された JTA トランザクションの一部として実行されることを指定します。メッセージ送信が失敗した場合は、トランザクション全体がロールバックされ、メッセージが再送信されます。以下に、MDB 内からのこの例を示します。
@MessageDriven(name = "MDBMessageSendTxExample",
  activationConfig =
    {
      @ActivationConfigProperty
        (propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
      @ActivationConfigProperty
        (propertyName = "destination", propertyValue = "queue/testQueue")
    })
@TransactionManagement(value= TransactionManagementType.CONTAINER)
@TransactionAttribute(value= TransactionAttributeType.REQUIRED)
public class MDBMessageSendTxExample implements MessageListener
{
   @Resource(mappedName = "java:/JmsXA")
   ConnectionFactory connectionFactory;

   @Resource(mappedName = "queue/replyQueue")
   Queue replyQueue;

   public void onMessage(Message message)
   {
      Connection conn = null;
      try
      {
         //Step 9. We know the client is sending a text message so we cast
         TextMessage textMessage = (TextMessage)message;

         //Step 10. get the text from the message.
         String text = textMessage.getText();

         System.out.println("message " + text);

         conn = connectionFactory.createConnection();

         Session sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);

         MessageProducer producer = sess.createProducer(replyQueue);

         producer.send(sess.createTextMessage("this is a reply"));

      }
      catch (Exception e)
      {
         e.printStackTrace();
      }
      finally
      {
         if(conn != null)
         {
            try
            {
               conn.close();
            }
            catch (JMSException e)
            { 
            }
         }
      }
   }
   }
また、EJB (セッション、エンティティ、および Message-Driven Bean を含む)、サーブレット (JSP を含む)、およびカスタム MBean からメッセージを送信するために JMS JCA アダプターを使用できます。

30.3. MDB およびコンシューマープールサイズ

JBoss を含むほとんどのアプリケーションサーバーでは、プール内の MDB の数を設定できます。ejb3-interceptors-aop.xml ファイル内の MaxPoolSize パラメーターが、作成されるセッションまたはコンシューマーの数に影響を持たないことを理解することが重要です。これは、リソースアダプター実装がアプリケーションサーバー MDB 実装を認識しないためです。
たとえば、MDB MaxPoolSize を 1 に設定すると、15 個のセッションまたはコンシューマーが作成されます (15 がデフォルト値)。作成されるセッションまたはコンシューマーの数を制限するには、リソースアダプターまたは MDBのActivationConfigProperty アノテーションで maxSession パラメーターを設定します。
@MessageDriven(name = "MDBMessageSendTxExample",
  activationConfig =
    {
      @ActivationConfigProperty
        (propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
      @ActivationConfigProperty
        (propertyName = "destination", propertyValue = "queue/testQueue"),
      @ActivationConfigProperty
        (propertyName = "maxSession", propertyValue = "1")
    })
@TransactionManagement(value= TransactionManagementType.CONTAINER)
@TransactionAttribute(value= TransactionAttributeType.REQUIRED)
public class MyMDB implements MessageListener
{ ....}

30.4. JCA アダプターの設定

Java Connector Architecture (JCA) アダプターを使用すると、HornetQ を MDB や EJB などの Java EE コンポーネントと統合できます。これは、MDB などのコンポーネントが HornetQ サーバーからメッセージをどのように消費するかや、EJB またはサーブレットなどのコンポーネントがメッセージをどのように送信できるかを設定します。
HornetQ JCA アダプターは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar アーカイブでデプロイされます。アダプターの設定は、META-INF/ra.xml 下のこのアーカイブにあります。
これを参照する必要がある場合は、このファイルのサイズのため、これは、付録B ra.xml HornetQ リソースアダプターファイル に含まれます。また、指定されたディレクトリからこのファイルを開き、以下の情報とともに確認することもできます。
この設定には 3 つの主要な部分があります。これらについては、次の項で説明されています。

30.4.1. JCA グローバルプロパティー

表示された最初の要素は resourceadapter-class であり、変更しないでください。これは、HornetQ リソースアダプタークラスです。
この後に、設定プロパティーのリストがあります。ここでは、ほとんどの設定が行われます。最初の 2 つのプロパティーはアダプターにより使用されるトランスポートを設定し、残りは接続ファクトリー自体を設定します。

注記

すべての接続ファクトリープロパティーは、デフォルト値が -1 である reconnectAttempts を除いて、デフォルト値を使用します。これは、接続が接続障害時に再接続を無限に行うことを意味します。これは、InVM コネクターが失敗できない場合に、アダプターがリモートサーバーに接続するよう設定された場合のみ使用されます。
以下の表は、各プロパティの使用目的について説明しています。

表30.1 グローバル設定プロパティー

プロパティー名 プロパティータイプ プロパティーの説明
ConnectorClassName 文字列 Connector クラス名 (詳細については、14章トランスポートの設定 を参照)
ConnectionParameters 文字列 トランスポート設定。これらのパラメーターは、key1=val1;key2=val2; という形式である必要があり、使用されるコネクターに固有です。
useLocalTx ブール値 True の場合は、ローカルトランザクションの最適化が有効になります。
UserName 文字列 接続を確立するときに使用するユーザー名
Password 文字列 接続を確立するときに使用するパスワード
BackupConnectorClassName 文字列 ライブノードで障害が発生したときに使用するバックアップトランスポート
BackupConnectionParameters 文字列 バックアップトランスポート設定パラメーター
DiscoveryAddress 文字列 サーバーを自動検出するために使用する検出グループアドレス
DiscoveryPort 整数 検出に使用するポート
DiscoveryRefreshTimeout Long 更新するタイムアウト (ミリ秒単位)
DiscoveryInitialWaitTimeout Long 検出を待機する初期時間
ConnectionLoadBalancingPolicyClassName 文字列 使用するロードバランシングポリシークラス
ConnectionTTL Long 接続のために存続する時間 (ミリ秒単位)
CallTimeout Long 送信された各パケットに対するコールタイムアウト (ミリ秒単位)。
DupsOKBatchSize 整数 DUPS_OK_ACKNOWLEDGE モードを使用する場合の、承認間のバッチサイズ (バイト単位)。
TransactionBatchSize 整数 トランザクションセッションの使用時の、承認間のバッチサイズ (バイト単位)。
ConsumerWindowSize 整数 コンシューマーフロー制御のウィンドウサイズ (バイト単位)
ConsumerMaxRate 整数 コンシューマーが 1 秒ごとにメッセージを消費できる最速レート
ConfirmationWindowSize 整数 再添付の確認のためのウィンドウサイズ (バイト単位)
ProducerMaxRate 整数 1 秒ごとに送信できるメッセージの最大レート
MinLargeMessageSize 整数 バイト単位のサイズ。これよりも大きいと、メッセージが大きいと見なされます。
BlockOnAcknowledge ブール値 メッセージが同期的に承認されるかどうか。
BlockOnNonDurableSend ブール値 非耐性メッセージが同期的に送信されるかどうか。
BlockOnDurableSend ブール値 耐性メッセージが同期的に送信されるかどうか。
AutoGroup ブール値 メッセージグルーピングが自動的に使用されるか、されないか。
PreAcknowledge ブール値 送信前にメッセージをサーバーが事前に承認するかどうか。
ReconnectAttempts 整数 再試行の最大回数。リソースアダプターのデフォルト値は -1 (無限の試行回数) です。
RetryInterval Long 失敗後に接続を再試行する時間 (ミリ秒単位)。
RetryIntervalMultiplier Double 連続する再試行間隔に適用する乗数。
FailoverOnServerShutdown ブール値 true の場合は、クライアントが別のサーバー (利用可能な場合) に最接続します。
ClientID 文字列 接続ファクトリーに対して事前に設定されたクライアント ID。
ClientFailureCheckPeriod Long ミリ秒単位の時間。この時間の経過後、クライアントはサーバーからパケットを受け取らない場合に接続が失敗したと見なします。
UseGlobalPools ブール値 スレッドにグローバルスレッドプールを使用するかどうか。
ScheduledThreadPoolMaxSize 整数 スケジュールされたスレッドプールのサイズ。
ThreadPoolMaxSize 整数 スレッドプールのサイズ。
SetupAttempts 整数 JMS 接続をを設定する試行回数 (デフォルト値は 10 であり、-1 は無限に再試行することを意味します)。MDB は、JMS リソースが利用可能になる前にデプロイされることがあります。この場合、リソースアダプターは、リソースが利用可能になるまで複数回設定の試行を行います。これは、インバウンド接続にのみ適用されます。
SetupInterval Long JMS 接続を設定するための、連続する試行間のミリ秒単位の時間(デフォルト値は 2000m)。これは、インバウンド接続に対してのみ適用されます。

30.4.2. JCA アウトバウンド設定

アウトバウンド設定は、Java EE コンポーネントにより使用される接続ファクトリーを定義するため、未変更のままになります。これんらお接続ファクトリーは、名前 *-ds.xml に一致する設定ファイルの内部で定義できます。デフォルトの jms-ds.xml 設定ファイルは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/jms-ds.xml に存在ます。このファイルで定義された接続ファクトリーは主要な ra.xml 設定からプロパティーを継承しますが、オーバーライドすることもできます。次の例はオーバーライドする方法を示しています。
<tx-connection-factory>
      <jndi-name>RemoteJmsXA</jndi-name>
      <xa-transaction/>
      <rar-name>jms-ra.rar</rar-name>
      <connection-definition>
        org.hornetq.ra.HornetQRAConnectionFactory
      </connection-definition>
      <config-property name="SessionDefaultType" type="String">javax.jms.Topic
      </config-property>
      <config-property name="ConnectorClassName" type="String">
        org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
      </config-property>
      <config-property name="ConnectionParameters" type="String">
        port=5445
      </config-property>
      <max-pool-size>20</max-pool-size>
</tx-connection-factory>
この例では、接続ファクトリーは名前が RemoteJmsXA の JNDI にバインドされ、JNDI を使用して通常の方法でルックアップしたり、EJB や MDB 内で以下のように定義したりできます。
@Resource(mappedName="java:/RemoteJmsXA")
private ConnectionFactory connectionFactory;
config-property 要素は、ra.xml 設定ファイルでこれらをオーバーライドします。ここでは、接続ファクトリーに関係するいずれかの要素をオーバーライドできます。
また、アウトバウンド設定は、グローバル設定プロパティー以外に追加のプロパティーを定義します。

表30.2 アウトバウンド設定プロパティー

プロパティー名 プロパティータイプ プロパティーの説明
SessionDefaultType 文字列 デフォルトのセッションタイプ
UseTryLock 整数 指定された秒数の間、ロックを取得しようとします。0 以下の場合、この機能は無効になります。

30.4.3. JCA インバウンド設定

インバウンド設定は、未変更のままである必要があります。これは、メッセージを MDB に転送するものを制御します。アクティベーション設定を MDB 自体に追加することにより、MDB のプロパティーをオーバーライドできます。これは、MDB が異なるサーバーから消費するよう設定するために使用できます。
また、インバウンド設定は、グローバル設定プロパティー以外に追加のプロパティーを定義します。

表30.3 インバウンド設定プロパティー

プロパティー名 プロパティータイプ プロパティーの説明
定義 文字列 宛先の JNDI 名
DestinationType 文字列 宛先のタイプ。javax.jms.Queue または javax.jms.Topic (デフォルト値は javax.jms.Queue) のいずれかになります。
AcknowledgeMode 文字列 承認モード。Auto-acknowledge または Dups-ok-acknowledge (デフォルト値は Auto-acknowledge) のいずれかになります。AUTO_ACKNOWLEDGEDUPS_OK_ACKNOWLEDGE は許容値です。
MaxSession 整数 このインバウンド設定により作成されたセッションの最大数 (デフォルト値は 15)
MessageSelector 文字列 コンシューマーのメッセージセレクター
SubscriptionDurability 文字列 サブスクリプションのタイプ。Durable または NonDurable のいずれかになります。
SubscriptionName 文字列 サブスクリプションの名前
TransactionTimeout Long トランザクションタイムアウト (ミリ秒単位。デフォルト値は 0 であり、トランザクションはタイムアウトしません)
UseJNDI ブール値 宛先をルックアップするために JNDI を使用するかどうか (デフォルト値は true)

30.4.4. 高可用性 JNDI (HA-JNDI)

JNDI を使用してサーバーのクラスターから JMS キュー、トピック、および接続ファクトリーをルックアップする場合は、HA-JNDI を使用して、クラスター内の 1 つまたは複数のサーバーで障害が発生したときに、JNDI ルックアップが動作し続けることが望まれます。
HA-JNDI は、クラスター内の各サーバーの JNDI 接続詳細を認識せずにクライアントから JNDI を使用することを可能にする JBoss Application Server サービスであります。このサービスは、JBoss Application Server インスタンスのクラスターを使用する場合のみ利用可能です。
これを使用するには、JNDI への接続時に以下のプロパティーを使用します。
Hashtable<String, String> 
  jndiParameters = new Hashtable<String, String>();
jndiParameters.put("java.naming.factory.initial", 
    "org.jnp.interfaces.NamingContextFactory");
jndiParameters.put("java.naming.factory.url.pkgs=", 
    "org.jboss.naming:org.jnp.interfaces");

initialContext = new InitialContext(jndiParameters);
HA-JNDI の使用の詳細については、JBoss Enterprise Application Platform のこのリリースに対する 『Administration and Configuration Guide (管理および設定ガイド)』 の項「Clustering (クラスタリング)」を参照してください。

30.4.5. XA 復元

XA 復元はシステム障害またはアプリケーション障害に対応し、いずれかのアプリケーションプロセスまたはアプリケーションプロセスをホストしているマシンがクラッシュまたはネットワーク接続を失った場合であっても、トランザクションのリソースがトランザクションによって影響されるすべてのリソースに一括して適用されます。XA 復元の詳細については、このリリースの JBoss Enterprise Application Platform で提供される JBoss Transactions の文書を参照してください。
HornetQ は JBoss Transactions を使用してメッセージングリソースの復元を提供します。メッセージが XA トランザクションで関係する場合は、サーバークラッシュ時に、復元マネージャーにより、トランザクションが復元され、サーバーが再起動されたときにメッセージがコミットまたはロールバックされます (トランザクションの結果に基づきます)。

30.4.5.1. XA 復元設定

HornetQ XA 復元を有効にするには、復元マネージャーが HornetQ に接続してリソースを復元するよう設定する必要があります。以下のプロパティーを JBOSS_DIST/jboss-as/server/PROFILE/conf/jbossts-properties.xmljta セクションに追加する必要があります。
<properties depends="arjuna" name="jta">
   ...
                     
   <property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HornetQ1"
      value="org.hornetq.jms.server.recovery.HornetQXAResourceRecovery;[connection configuration]"/>
</properties>
[connection configuration] には、[connector factory class name],[user name], [password], [connector parameters] という形式で HornetQ ノードに接続するために必要なすべての情報が含まれます。
  • [connector factory class name] は HornetQ に接続するために使用される ConnectorFactory の名前に対応します。値は org.hornetq.core.remoting.impl.invm.InVMConnectorFactory または org.hornetq.core.remoting.impl.netty.NettyConnectorFactory のいずれかになります。
  • [user name] は、クライアントセッションを作成するユーザー名です。これはオプションです。
  • [password] は、クライアントセッションを作成するパスワードです。これは、ユーザー名が指定された場合のみ必須になります。
  • [connector parameters] は、接続ファクトリーに渡されるカンマで区切られたキーと値のペアのリストです (トランスポートパラメーターのリストについては、14章トランスポートの設定 を参照してください)。

注記

HornetQ は、JBOSS_DIST/jboss-as/server/PROFILE/conf/jbossts-properties.xml で指定されたコネクターに対応する有効なアクセプターを持つ必要があります。

30.4.5.2. 設定

HornetQ がデフォルトの InVM アクセプターで設定される場合:
<acceptor name="in-vm">
  
<factory-class>org.hornetq.core.remoting.impl.invm.InVMAcceptorFactory</factory-class>
</acceptor>
JBOSS_DIST/jboss-as/server/PROFILE/conf/jbossts-properties.xml の対応する設定は、以下のようになります。
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HORNETQ1"
 value="org.hornetq.jms.server.recovery.HornetQXAResourceRecovery;
        org.hornetq.core.remoting.impl.invm.InVMConnectorFactory"/>
これが、デフォルトでないポートの netty アクセプターで設定された場合:
<acceptor name="netty">
  <factory-class>
    org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory
  </factory-class>
  <param key="port" value="8888"/>
</acceptor>
JBOSS_DIST/jboss-as/server/PROFILE/conf/jbossts-properties.xml の対応する設定は以下のようになります。
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HORNETQ1"
  value="org.hornetq.jms.server.recovery.HornetQXAResourceRecovery;
        org.hornetq.core.remoting.impl.netty.NettyConnectorFactory, , , port=8888"/>

注記

ユーザーとパスワードをスキップするコネクターパラメーターの前の追加のカンマに注意してください。
復元が admin, adminpass を使用する必要がある場合、設定は以下のようになります。
<property name="com.arjuna.ats.jta.recovery.XAResourceRecovery.HORNETQ1"   
  value="org.hornetq.jms.server.recovery.HornetQXAResourceRecovery;
        org.hornetq.core.remoting.impl.netty.NettyConnectorFactory, admin, adminpass, port=8888"/>
XA 復元を有効にするには、InVM アクセプターでの HornetQ の設定と InVM コネクターでの Recovery Manager の設定が推奨される方法です。

第31章 JMS ブリッジ

HornetQ には、完全に機能する JMS メッセージングブリッジが含まれ、ソースキューまたはトピックからメッセージを消費し、通常は異なるサーバー上のターゲットキューまたはトピックに送信します。
ソースおよびターゲットサーバーは同じクラスター内に属する必要がないため、あるクラスターから別のクラスター (WAN 間、および接続が信頼できない場合) に安定してメッセージを送信する場合にブリッジングが適切になります。
また、ブリッジは、JMS 1.1 に準拠する他の非 HornetQ JMS サーバーからメッセージをブリッジ接続するために使用できます。

重要

JMS ブリッジは、任意の 2 つの JMS 1.1 準拠 JMS プロバイダーをブリッジ接続するために使用でき、JMS API を使用します。コアブリッジ (34章コアブリッジ で説明) は任意の 2 つの HornetQ インスタンスをブリッジ接続するために使用され、コア API を使用します。コアブリッジは、通常 JMS ブリッジよりも優れたパフォーマンスを提供し、XA を使用せずに 1 度だけの配信保証を提供します。
ブリッジには、耐障害性が組み込まれているため、ソースまたはターゲットサーバー接続が失われた場合 (たとえば、ネットワーク障害のため)、ブリッジはオンライン状態に戻るまでターゲットサーバーに再接続しようとします。この時点で操作は通常に戻ります。
ブリッジは、オプションの JMS セレクターで設定できるため、その JMS セレクターに一致するメッセージのみを消費します。
これは、キューまたはトピックから消費するよう設定できます。これは、トピックから消費するときに、非耐性または耐性サブスクライブを使用して消費するよう設定できます。
ブリッジは通常、JBOSS_DIST/jboss-as/server/PROFILE/deploy にある Bean 設定ファイル (jms-bridge-jboss-beans.xml) を使用して JBoss Microcontainer によってデプロイされます。
例31.1「jms-bridge-jboss-beans.xml サンプル設定」 は、同じサーバーで 2 つの宛先をブリッジ接続する設定例を示しています。

例31.1 jms-bridge-jboss-beans.xml サンプル設定

<?xml version="1.0" encoding="UTF-8"?>

<deployment xmlns="urn:jboss:bean-deployer:2.0">

  <bean name="JMSBridge" class="org.hornetq.api.jms.bridge.impl.JMSBridgeImpl">
     <!-- HornetQ must be started before the bridge -->
     <depends>HornetQServer</depends>
     <constructor>
         <!-- Source ConnectionFactory Factory -->
         <parameter>
             <inject bean="SourceCFF"/>
         </parameter>
         <!-- Target ConnectionFactory Factory -->
         <parameter>
             <inject bean="TargetCFF"/>
         </parameter>
         <!-- Source DestinationFactory -->
         <parameter>
             <inject bean="SourceDestinationFactory"/>
         </parameter>
         <!-- Target DestinationFactory -->
         <parameter>
             <inject bean="TargetDestinationFactory"/>
         </parameter>
         <!-- Source User Name (no user name here) -->
         <parameter><null /></parameter>
         <!-- Source Password (no password here)-->
         <parameter><null /></parameter>
         <!-- Target User Name (no user name here)-->
         <parameter><null /></parameter>
         <!-- Target Password (no password here)-->
         <parameter><null /></parameter>
         <!-- Selector -->
         <parameter><null /></parameter>
         <!-- Failure Retry Interval (in ms) -->
         <parameter>5000</parameter>
         <!-- Max Retries -->
         <parameter>10</parameter>
         <!-- Quality Of Service -->
         <parameter>ONCE_AND_ONLY_ONCE</parameter>
         <!-- Max Batch Size -->
         <parameter>1</parameter>
         <!-- Max Batch Time (-1 means infinite) -->
         <parameter>-1</parameter>
         <!-- Subscription name (no subscription name here)-->
         <parameter><null /></parameter>
         <!-- Client ID  (no client ID here)-->
         <parameter><null /></parameter>
         <!-- Add MessageID In Header -->
         <parameter>true</parameter>
         <!-- register the JMS Bridge in the AS MBeanServer -->
         <parameter>
             <inject bean="MBeanServer"/>
         </parameter>
         <parameter>org.hornetq:service=JMSBridge</parameter>
       </constructor>
     <property name="transactionManager">
         <inject bean="RealTransactionManager"/>
     </property>
  </bean>

  <!-- SourceCFF describes the ConnectionFactory used to connect to the 
      source destination -->
  <bean name="SourceCFF" 
      class="org.hornetq.api.jms.bridge.impl.JNDIConnectionFactoryFactory">
     <constructor>
         <parameter>
             <inject bean="JNDI" />
         </parameter>
         <parameter>/ConnectionFactory</parameter>
     </constructor>  
  </bean>

  <!-- TargetCFF describes the ConnectionFactory used to connect to the 
  target destination -->
  <bean name="TargetCFF" 
      class="org.hornetq.api.jms.bridge.impl.JNDIConnectionFactoryFactory">
     <constructor>
         <parameter>
             <inject bean="JNDI" />
         </parameter>
         <parameter>/ConnectionFactory</parameter>
     </constructor>  
  </bean>

  <!-- SourceDestinationFactory describes the Destination used as the source -->
  <bean name="SourceDestinationFactory" 
      class="org.hornetq.api.jms.bridge.impl.JNDIDestinationFactory">
     <constructor>
         <parameter>
             <inject bean="JNDI" />
         </parameter>
         <parameter>/queue/source</parameter>
     </constructor>  
  </bean>

  <!-- TargetDestinationFactory describes the Destination used as the target -->
  <bean name="TargetDestinationFactory" 
      class="org.hornetq.api.jms.bridge.impl.JNDIDestinationFactory">
     <constructor>
         <parameter>
             <inject bean="JNDI" />
         </parameter>
         <parameter>/queue/target</parameter>
     </constructor>  
  </bean>

  <!-- JNDI is a Hashtable containing the JNDI properties required -->
  <!-- to connect to the sources and targets JMS resources         -->       
  <bean name="JNDI" class="java.util.Hashtable">
   <constructor class="java.util.Map">
      <map class="java.util.Hashtable" keyClass="String"
                                       valueClass="String">
         <entry>
            <key>java.naming.factory.initial</key>
            <value>org.jnp.interfaces.NamingContextFactory</value>
         </entry>
         <entry>
            <key>java.naming.provider.url</key>
            <value>jnp://localhost:1099</value>
         </entry>
         <entry>
            <key>java.naming.factory.url.pkgs</key>
            <value>org.jboss.naming:org.jnp.interfaces"</value>
         </entry>
      </map>
   </constructor>
  </bean>

  <bean name="MBeanServer" class="javax.management.MBeanServer">
   <constructor factoryClass="org.jboss.mx.util.MBeanServerLocator"
                factoryMethod="locateJBoss"/>
  </bean>
</deployment>

31.1. JMS ブリッジパラメーター

例31.1「jms-bridge-jboss-beans.xml サンプル設定」 で示された JMSBridge Bean は、特定の順序でコンストラクターに渡されるパラメーターを介して設定されます。この順序と各パラメーターの説明は以下のリストで示されています。

注記

パラメーターを未指定のままにする場合 (たとえば、認証が匿名である場合や、メッセージセレクターが提供されない場合) は、未指定のパラメーター値に対して <null /> を使用します。
Source Connection Factory Factory
jms-bridge-jboss-beans.xml ファイルで定義された SourceCFF Bean を挿入します (ConnectionFactory が作成されます)。
Target Connection Factory Factory
jms-bridge-jboss-beans.xml ファイルで定義された TargetCFF Bean を挿入します (ターゲット ConnectionFactory が作成されます)。
Source Destination Factory Factory
jms-bridge-jboss-beans.xml ファイルで定義された SourceDestinationFactory Bean を挿入します (ソース Destination が作成されます)。
Target Destination Factory Factory
jms-bridge-jboss-beans.xml ファイルで定義された TargetDestinationFactory Bean を挿入します (ターゲット Destination が作成されます)。
Source User Name
ソース接続を作成するために使用するユーザー名を定義します。
Source Password
ソース接続を作成するために使用するユーザー名のパスワードを定義します。
Target User Name
ターゲット接続を作成するために使用するユーザー名を定義します。
Target Password
ターゲット接続を作成するために使用するユーザー名のパスワードを定義します。
Selector
ソース宛先からメッセージを消費する場合に使用される JMS セレクター表現を指定します。セレクター表現に一致するメッセージのみがソース宛先からターゲット宛先にブリッジされます。セレクター表現は、JMS セレクター構文に従う必要があります。
Failure Retry Interval
ブリッジが接続障害を検出したときにソースサーバーまたはターゲットサーバーへの接続を再作成しようとするときにその試行間で待機する時間 (ミリ秒単位) を指定します。
Max Retries
ブリッジが接続障害を検出したときにソースまたはターゲットサーバーに対する接続を再作成しようとする回数を指定します。この回数後にブリッジは再接続の試行を止めます。-1 は、「永久的な試行」を意味します。
Quality of Service
サービスモードの品質を定義します。可能な値は次のとおりです。
  • AT_MOST_ONCE
  • DUPLICATES_OK
  • ONCE_AND_ONLY_ONCE
これらのモードについては、「サービス品質モード」 を参照してください。
Max Batch Size
ターゲット宛先にメッセージをバッチで送信する前にソース接続から消費する必要があるメッセージの最大数を定義します。この値は 1 以上である必要があります。
Max Batch Time
消費されるメッセージの数が MaxBatchSize に到達しない場合であっても、ターゲット宛先にバッチを送信するまで待機する時間 (ミリ秒単位) を定義します。この値は 1 以上または -1 (「永久的に待機」を指定する場合) である必要があります。
Subscription Name
ソース宛先がトピックであり、耐性サブスクリプションを持つトピックから消費する場合、このパラメーターは耐性サブスクリプション名を定義します。
Client ID
ソース宛先がトピックであり、耐性サブスクリプションを持つトピックから消費する場合、耐性サブスクリプションを作成またはルックアップするときにこのパラメーターは使用する JMS クライアント ID を定義します。
Add MessageID In Header
true の場合、元のメッセージのメッセージ ID が、HORNETQ_BRIDGE_MSG_ID_LIST ヘッダーの宛先に送信されるメッセージに付加されます。メッセージが複数回ブリッジ接続された場合は、各メッセージ ID が付加されます。これにより、分散応答パターンを使用できるようになります。

注記

メッセージが受信された場合は、最初のメッセージ ID の相関 ID を使用して応答を送信できるため、元の送信者が応答を受け取ると、メッセージを関連付けることができます。
MBean Server
JMS ブリッジを JMX で管理するために、これを JMS ブリッジが登録された場所 (アプリケーションサーバー MBeanServer) に設定します。
ObjectName
MBeanServer が設定された場合は、JMS Bridge MBean を登録するために使用する名前を定義するためにこのパラメーターを設定する必要があります。この名前は一意である必要があります。

31.2. ソースおよびターゲット接続ファクトリー

ソースおよびターゲット接続ファクトリーは、ソースまたはターゲットサーバーに対して接続を作成する接続ファクトリーを作成するために使用されます。
例31.1「jms-bridge-jboss-beans.xml サンプル設定」 は、HornetQ により提供されるデフォルトの実装を使用し、JNDI を使用して接続ファクトリーをルックアップします。他の JMS プロバイダーの場合は、異なる実装が必要になる場合があります。これを行うには、org.hornetq.jms.bridge.ConnectionFactoryFactory インターフェースを実装します。

31.3. ソースおよびターゲット宛先ファクトリー

これらは宛先を作成またはルックアップします。
例31.1「jms-bridge-jboss-beans.xml サンプル設定」 は、JNDI を使用して宛先をルックアップする、HornetQ により提供されたデフォルトの実装を使用します。
org.hornetq.jms.bridge.DestinationFactory インターフェースでは、さまざまな実装を提供できます。

31.4. サービス品質モード

ブリッジで使用されるサービス品質モードは、ここで詳しく説明されます。

31.4.1. AT_MOST_ONCE

メッセージが宛先に一度だけ到達します。メッセージは、宛先に送信される前にソースから消費され、承認されます。ソースから送信され、宛先に到達する間に障害が発生した場合は、メッセージが失われることがあります。このモードは耐性および非耐性メッセージの両方で利用可能です。

31.4.2. DUPLICATES_OK

メッセージはソースから消費され、宛先に正常に送信された後に承認されます。メッセージの送信後に (ただし、承認が返される前) 障害が発生した場合は、システムが復元したらメッセージを再送信できます。この結果、宛先は障害発生後に重複メッセージを受け取ることがあります。このモードは、耐性および非耐性メッセージの両方で利用可能です。

31.4.3. ONCE_AND_ONLY_ONCE

メッセージは宛先に 1 度だけ到達します。ソースおよび宛先が同じ HornetQ サーバーインスタンスに存在する場合、このモードは同じローカルトランザクションの一部としてメッセージを送信および承認します。ソースおよび宛先が異なるサーバーに存在する場合、このモードは送信および消費セッションを JTA トランザクションに含めます。
この JTA トランザクションは JBoss トランザクション JTA によって制御されます。JBoss トランザクション JTA は完全な復元トランザクションマネージャーであり、非常に高度な耐性を提供します。JTA が必要な場合、提供された両方の接続ファクトリーは XAConnectionFactory 実装である必要があります。
多くの場合、これは、特別な永続化が必要になるため、最も低速なモードになります。このモードは耐性メッセージでのみ利用可能です。

注記

一部のアプリケーションでは、1 度だけのセマンティクスは DUPLICATES_OK モードを設定し、宛先で重複メッセージを確認し、破棄することによって提供できます。この方法は、ONCE_AND_ONLY_ONCE モードを使用した場合よりも信頼できませんが、代替手段として役に立ちます。

31.4.4. タイムアウトおよび JMS ブリッジ

ターゲットまたはソースサーバーがある時点で利用可能でないことがあります。この場合は、JMS ブリッジ定義で指定されたように、ブリッジが Failure Retry Interval ミリ秒ごとにMax Retries の回数、再接続しようとします。
ただし、サードパーティーの JNDI が使用されているため (この場合は、JBoss ネーミングサーバー)、JNDI ルックアップ中にネットワークが失われた場合に JNDI ルックアップがハングすることがあります。このことを防ぐために、 ハングした場合にタイムアウトするよう JNDI 定義を設定できます。これを行うには、初期コンテキスト定義で jnp.timeoutjnp.sotimeout を設定します。jnp.timeout は初期接続のタイムアウトを設定し、jnp.sotimeout はソケットの読み取りタイムアウトを設定します。

注記

初期 JNDI 接続が成功すると、Remote Method Invocation (RMI) を使用してすべてのコールが行われます。RMI 接続のタイムアウトを制御する場合は、システムプロパティーを使用して行えます。JBoss は Oracle の RMI を使用します。これらのプロパティー については、ここを参照してください。デフォルトの接続タイムアウトは 10 秒であり、デフォルトの読み取りタイムアウトは 18 秒です。
JMS リソースをルックアップするために独自のファクトリーを実装する場合は、タイムアウトの問題に注意する必要があります。

第32章 クライアントの再接続とセッションの再割り当て

HornetQ クライアントは、サーバークライアント接続で障害が検出された場合に、サーバーに自動的に再接続または再割り当てするよう設定できます。

32.1. 100% の透過セッションの再割り当て

障害が一時的 (つまり、一時ネットワーク障害が原因) であり、対象サーバーが再起動されない場合、セッションは connection-ttl の期限が切れない限りサーバーに存在します (connection-ttl の詳細については、15章使用済みの接続の検出 を参照してください)。
この場合、HornetQ によって、接続が再び確立されるときにクライアントセッションがサーバーセッションに再割り当てされます。これは、100% 透過的に行われ、クライアントは以前のように稼働し続けることができます。
HornetQ クライアントがコマンドをサーバーに送信する場合、サーバーは送信された各コマンドをメモリ内バッファーに格納します。接続障害が発生し、クライアントがサーバーに再接続されると、サーバーは、再割り当てプロトコルの一部として、正常に受信された最後のコマンドの ID をクライアントに渡し返します。クライアントが他のいずれかのコマンドを送信しようとした場合、クライアントとサーバーが差異を調整できるようクライアントはバッファからこれらのコマンドを再送信できます。
ConfirmationWindowSize パラメータ (通常は JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar/META-INF/ra.xml ファイルで設定されます) によってバッファのサイズがバイト単位で定義されます。サーバーはコマンドの ConfirmationWindowSize バイトを受信し、処理すると、コマンド情報をクライアントに送信し返します。次に、クライアントは確認されたコマンドをバッファから削除できます。
ConfirmationWindowSize-1 (デフォルト値) に設定すると、バッファリングが無効になり、再接続が行われなくなり、代わりに再割り当てが強制的に実行されます。
JMS を使用しており、JMS 接続ファクトリーインスタンスを JNDI にロードするためにサーバー上の JMS サービスを使用している場合は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar/META-INF/ra.xml ファイルの ConfirmationWindowSize パラメータをコメント解除します。JNDI ではなく JMS を使用している場合は、適切な setter メソッドを使用して HornetQConnectionFactory インスタンス上で直接これらの値を設定します。Core を使用している場合は、適切な setter メソッドを使用して ClientSessionFactory インスタンスで直接これらの値を設定できます。

32.2. セッションの再接続

クラッシュまたは停止後にサーバーが再起動された場合、セッションはサーバーに存在しなくなり、完全に透過的な再割り当てを行うことはできません。
この場合、HornetQ によって自動的に再接続が行われ、クライアントのセッションとコンシューマーに基づいてサーバーにセッションとコンシューマーが再び作成されます (このプロセスはバックアップサーバーでのフェールオーバーと同一です)。クライアントの再接続は、対象サーバーに再接続するためにコアブリッジなどのコンポーネントによって内部的にも使用されます。フェールオーバー中にトランザクションセッションと非トランザクションセッションがどのように再接続されるかの詳細と、1 度だけの配信保証の要件については、「自動クライアントフェイルオーバー」 を参照してください。

32.3. 再接続/再割り当て属性の設定

JMS を使用しており、JMS 接続ファクトリーインスタンスを JNDI にロードするためにサーバー上の JMS サービスが使用されている場合は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で以下のパラメータを指定できます。
<connection-factory name="NettyConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>
      <entry name="/XAConnectionFactory"/>
   </entries>
   <retry-interval>1000</retry-interval>
   <retry-interval-multiplier>1.5</retry-interval-multiplier>
   <max-retry-interval>60000</max-retry-interval>
   <reconnect-attempts>1000</reconnect-attempts>
</connection-factory>
retry-interval
再接続間の時間 (ミリ秒単位) を定義するオプションのパラメータ (対象サーバーへの接続が失敗した場合)。デフォルト値は 2000 ミリ秒です。
retry-interval-multiplier
次の再試行までの時間を計算するために最後の再試行以降の時間に適用する乗数を定義するオプションのパラメータ。つまり、再試行間の時間は試行の失敗ごとに指数的に増加します。デフォルト値 1.0 であり、各再接続試行を等間隔で設定します。
max-retry-interval
再試行間の最大間隔をミリ秒単位で定義するオプションのパラメータ。retry-interval-multiplier が設定された場合であっても、再試行間の間隔はこの値よりも大きくなりません。デフォルト値は 2000 ミリ秒です。
reconnect-attempts
再接続の試行を停止し、シャットダウンするまでの、再接続試行の合計数を定義するオプションのパラメータ。値が -1 の場合は、制限がない再試行回数が設定されます。デフォルト値は 0 です。
JMS を使用しており、JMS 接続ファクトリーを直接インスタンス化している場合は、作成直後に HornetQConnectionFactory で適切な setter メソッドを使用してパラメータを指定できます。
コア API を使用し、ClientSessionFactory インスタンスを直接インスタンス化している場合は、作成直後に ClientSessionFactory で適切な setter メソッドを使用してパラメータを指定することもできます。
クライアントが再接続を行い、セッションがサーバーで利用可能でなくなった場合 (たとえば、サーバーが再起動された場合、またはタイムアウトになった場合) は、クライアントは再割り当てを行うことができず、接続で登録されたすべての ExceptionListener または SessionFailureListener インスタンスが呼び出されます。

注記

登録された JMS ExceptionListener または Core SessionFailureListener インスタンスは、クライアントの再接続または再割り当てが行われたときに呼び出されます。

第33章 メッセージフローの迂回と分割

迂回は、あるアドレスにルーティングされたメッセージを他のアドレスに透過的に迂回するオブジェクトです (クライアントアプリケーションロジックには変更を加えません)。
迂回は 特別 (メッセージが新しいアドレスに迂回されますが、以前のアドレスには送信されません) または 特別でない (メッセージのコピーが新しいアドレスに送信され、元のメッセージが古いアドレスに送信されます) のいずれかです。したがって、特別でない迂回は、メッセージフローを分割するために使用できます (たとえば、注文キューに送信された各注文を監視する必要がある場合)。
迂回はフィルターで設定することもでき、フィルターに一致するメッセージのみが迂回されます。
迂回は Transformer を適用するために設定することもできます。指定された場合、迂回されたすべてのメッセージをこの Transformer により変換できます。
迂回は同じサーバーでメッセージをアドレスに移動しますが、ブリッジと組み合わせて使用すると、より複雑なルーティングを設定できます。異なるサーバーに「迂回」させる一般的な使用例の 1 つはメッセージをローカルストアに迂回し、キューを転送して、そのキューから消費するブリッジを設定し、消費されたメッセージを別のサーバーのアドレスに転送することです。サーバーの迂回はメッセージのルーティングテーブルと考えることができます。迂回とブリッジを組み合わせると、地理的に分散された複数のサーバー間で信頼できるルーティング接続の分散ネットワークを作成できます。
迂回は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルで定義されます。ファイルにはゼロ個以上の迂回を定義できます。

33.1. 特別な迂回

特別な迂回は古いアドレスにルーティングされたすべての一致メッセージを新しいアドレスに迂回します。一致メッセージは古いアドレスにルーティングされません。
迂回は以下のディレクティブを使用して JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されます。
<divert name="prices-divert">                  
   <address>jms.topic.priceUpdates</address>
   <forwarding-address>jms.queue.priceForwarding</forwarding-address>    
   <filter string="office='New York'"/>
   <transformer-class-name>
    org.hornetq.jms.example.AddForwardingTimeTransformer
   </transformer-class-name>     
   <exclusive>true</exclusive>
</divert>
上記で指定された prices-divert 迂回はアドレス jms.topic.priceUpdates (priceUpdates という名前のローカル JMS トピック) に送信されたすべてのメッセージを別のローカルアドレス jms.queue.priceForwarding (priceForwarding という名前のローカル JMS キュー) に迂回します。
メッセージプロパティ office='New York' を持つメッセージだけが迂回されるよう フィルター文字列 が指定されます。他のすべてのメッセージは通常のアドレスにルーティングされ続けます。フィルター文字列はオプションです。指定されない場合は、すべてのメッセージが迂回されます。
トランスフォーマークラスもオプションです。指定されると、一致する各メッセージに対して変換が実行されます。これにより、メッセージが迂回される前にメッセージボディーまたはプロパティーを変更できます。上記の例では、迂回が発生した時間を記録するヘッダーを追加するために変換を使用します。
全体として、上記の例では、ブリッジで設定されるメッセージをローカルストアおよび転送キューに迂回し、メッセージを別の HornetQ サーバーのアドレスに転送します。

33.2. 特別でない迂回

特別でない迂回はメッセージのコピーを新しいアドレスに転送し、元のメッセージを前のアドレスに送信できます。これらはメッセージフローの分割と考えることができます。
特別でない迂回は、以下のようにオプションのフィルターとトランスフォーマーを使用して特別な迂回と同じように設定されます。
<divert name="order-divert">                 
   <address>jms.queue.orders</address>
   <forwarding-address>jms.topic.spyTopic</forwarding-address>         
   <exclusive>false</exclusive>
</divert>
order-divert 例は jms.queue.orders アドレス (orders という名前の JMS キュー) に送信された各メッセージをコピーし、そのコピーをローカルアドレス jms.topic.SpyTopic (SpyTopic という名前の JMS トピック) に転送します。

第34章 コアブリッジ

ブリッジの機能は、ソースキューからメッセージを消費し、一般的に異なる HornetQ サーバーのターゲットアドレス転送することです。
ソースおよびターゲットサーバーは同じクラスター内に属する必要がないため、あるクラスターから別のクラスター (WAN 間またはインターネット、接続が信頼できない場合) に安定してメッセージを送信する場合にブリッジングが適切になります。
ブリッジには障害からの回復力があるため、ネットワーク障害のためターゲットサーバー接続が失われた場合に、ブリッジはオンライン状態に戻るまでターゲットに接続しようとします。ブリッジはオンライン状態に戻ると、通常どおり稼働し続けます。
要するに、ブリッジを使用すると、2 つの個別の HornetQ サーバー同士を安定的に接続できます。コアブリッジを使用する場合は、ソースサーバーとターゲットサーバーが HornetQ サーバーである必要があります。
ブリッジは、ソースまたはターゲットサーバーの障害発生時であっても1 度だけの配信保証を提供するよう設定できます。これは、重複検出を使用して行われます (35章重複メッセージ検出 で説明)。

注記

これらは類似した機能を持ちますが、コアブリッジと JMS ブリッジを混同しないでください。
コアブリッジはある HornetQ ノードと別の HornetQ ノードを接続するために使用され、JMS API を使用しません。JMS ブリッジは任意の 2 つの JMS 1.1 準拠 JMS プロバイダーを接続するために使用されます。したがって、JMS ブリッジは異なる JMS 準拠メッセージングシステムに対するブリッジングに使用できます。できる限り、コアブリッジを使用することが推奨されます。コアブリッジは重複検出を使用して 1 度だけの保証を提供します。JMS ブリッジを施用して同じ保証を提供するには、オーバーヘッドが大きく設定が複雑な XA を使用する必要があります。

34.1. ブリッジの設定

ブリッジは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されます。以下に例を示します (これは実際のブリッジの例を基にしています)。
<bridge name="my-bridge">
   <queue-name>jms.queue.sausage-factory</queue-name>
   <forwarding-address>jms.queue.mincing-machine</forwarding-address>
   <filter-string="name='aardvark'"/>
   <transformer-class-name>
        org.hornetq.jms.example.HatColourChangeTransformer
   </transformer-class-name>
   <retry-interval>1000</retry-interval>
   <retry-interval-multiplier>1.0</retry-interval-multiplier>
   <reconnect-attempts>-1</reconnect-attempts>
   <failover-on-server-shutdown>false</failover-on-server-shutdown>
   <use-duplicate-detection>true</use-duplicate-detection>
   <confirmation-window-size>10000000</confirmation-window-size>
   <connector-ref connector-name="remote-connector" 
        backup-connector-name="backup-remote-connector"/>     
   <user>foouser</user>
   <password>foopassword</password>
</bridge>
上記の例では、ブリッジに設定できるすべてのパラメーターが示されています。実際には、多くのデフォルト値を使用できるため、これらすべてを明示的に指定する必要はありません。
パラメーターは以下のリストで説明されています。

コアブリッジパラメーター

name
すべてのブリッジはサーバーで一意の名前を持っている必要があります。
queue-name
これは、コンシューマーをブリッジするローカルキューの一意の名前であり、必須パラメーターです。
キューは、起動時にブリッジがインスタンス化されるまでにすでに存在している必要があります。

注記

JMS を使用している場合は、通常、 コア設定ファイル JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml がロードされた後に JMS 設定 (JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml) がロードされます。ブリッジが JMS キューから消費された場合は、JMS キューがコア設定でコアキューとしてデプロイされるようにしてください。この例については、ブリッジの例を参照してください。
forwarding-address
これは、メッセージが転送されるターゲットサーバー上のアドレスです。転送先アドレスが指定されない場合は、メッセージの元のアドレスが保持されます。
filter-string
オプションのフィルター文字列を提供できます。指定された場合は、フィルター文字列で指定されたフィルター式に一致するメッセージだけが転送されます。フィルター文字列は 12章フィルター表現 で説明された HornetQ フィルター式構文に従います。
transformer-class-name
オプションの transformer-class-name を指定できます。これは、org.hornetq.core.server.cluster.Transformer インターフェースを実装するユーザー定義クラスの名前です。
これが指定された場合は、メッセージが転送される前に、トランスフォーマーの transform() メソッドがメッセージで呼び出されます。これにより、転送前にメッセージヘッダーまたはボディを変換できるようになります。
retry-interval
このオプションのパラメーターは、ターゲットサーバーへの接続が失敗した場合に、以降の再接続試行間の時間 (ミリ秒単位) を決定します。デフォルト値は 2000 ミリ秒です。
retry-interval-multiplier
このオプションのパラメーターは、次の再試行までの時間を計算するために、最後の再試行以降の時間に適用する乗数を決定します。
これにより、再試行間の exponential backoff を実装できるようになります。
例:
retry-interval1000 ms に設定され、retry-interval-multiplier2.0 に設定される場合は、最初の再接続試行が失敗すると、以降の再接続試行間で 1000 ms、2000 ms、および 4000 ms の待機が発生します。
デフォルト値は 1.0 であり、各再接続試行が等間隔で設定されます。
reconnect-attempts
このオプションのパラメーターは、諦めてシャットダウンする前に、ブリッジが行う再接続の合計数を決定します。値が -1 の場合は、無制限の試行回数が設定されます。デフォルト値は -1 です。
failover-on-server-shutdown
このオプションのパラメーターは、ターゲットサーバーがクラッシュせずに正常にシャットダウンしたときにブリッジがバックアップサーバー (指定された場合) にフェイルオーバーするかどうかを決定します。
ブリッジコネクターはライブサーバーとバックアップサーバーの両方を指定できます。バックアップサーバーを指定し、このパラメーターが true に設定された場合は、ターゲットサーバーが正常にシャットダウンされ、ブリッジコネクターがバックアップにフェイルオーバーしようとします。ブリッジコネクターでバックアップサーバーが設定されていない場合、このパラメーターは無効です。
このパラメーターは、ライブおよびバックアップターゲットサーバーが設定されたブリッジが必要な場合に役に立ちますが、ライブサーバーが保守のために一時的にダウンする場合は、バックアップへのフェイルオーバーが必要ありません。
このパラメーターのデフォルト値は false です。
use-duplicate-detection
このオプションのパラメーターは、ブリッジが、転送する各メッセージに重複する ID プロパティーを自動的に挿入するかどうかを決定します。
これを行うと、ターゲットサーバーがソースサーバーから受け取るメッセージに対して重複検出を実行できます。接続が失敗した場合、またはサーバーがクラッシュした場合は、ブリッジが再開したときに、未承認メッセージが再送信されます。この結果、重複メッセージがターゲットサーバーに送信されることがあります。重複検出を有効にすると、これらの重複を隠したり、無視したりできます。
これにより、ブリッジは XA などの大規模な手段を使用せずに 1 度だけの配信保証を提供できます (詳細については、35章重複メッセージ検出 を参照してください)。
このパラメーターのデフォルト値は true です。
confirmation-window-size
このオプションのパラメーターはターゲットノードにメッセージを転送するために使用される接続に使用する confirmation-window-size を決定します。この属性は、項 32章クライアントの再接続とセッションの再割り当て で説明されています。

警告

ブリッジを使用してメッセージを max-size-bytes が設定されたキューから転送する場合は、confirmation-window-size を max-size-bytes 以下に指定し、メッセージのフローが消失しないようにすることが重要です。
connector-ref
この必須パラメーターは、ターゲットサーバーに対して接続を実際に確立するためにブリッジが使用するコネクターペアを決定します。
コネクターは、使用するトランスポート (TCP、SSL、HTTP など) とサーバー接続パラメーター (ホストやポートなど) の情報をカプセル化します。コネクターとその設定の詳細については、14章トランスポートの設定 を参照してください。
connector-ref 要素は次の 2 つの属性で設定できます。
  • connector-name。これは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されたコネクターの名前を参照します。ブリッジはこのコネクターを使用してターゲットサーバーへの接続を確立します。この属性は必須です。
  • backup-connector-name。このオプションパラメーターも JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されたコネクターの名前を参照します。これは、ライブサーバー接続が失敗したことを検出した場合に、ブリッジがフェイルオーバーするコネクターを表します。これが指定され、failover-on-server-shutdowntrue に設定された場合は、ライブサーバーが正常にシャットダウンされたときにこのコネクターにフェイルオーバーしようとします。
user
このオプションパラメーターは、リモートサーバーへのブリッジ接続を作成するときに使用するユーザー名を決定します。指定されない場合は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlcluster-user で指定されたデフォルトのクラスターユーザーが使用されます。
password
このオプションパラメーターは、リモートサーバーへのブリッジ接続を作成するときに使用するパスワードを決定します。指定されない場合は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlcluster-password で指定されたデフォルトのクラスターパスワードが使用されます。

第35章 重複メッセージ検出

HornetQ には、強力な自動重複メッセージ検出が含まれ、アプリケーションレベルで重複検出ロジックをコーディングせずに重複メッセージをフィルタリングできます。この章では、重複検出と、HornetQ が重複検出をどのように使用するか、重複検出をどのようにいつ設定するかについて説明します。
クライアントからサーバー、またはサーバーから別のサーバーにメッセージを送信する場合、ターゲットサーバーまたは接続がメッセージの送信後に失敗すると (ただし、送信者が送信 (またはコミット) が正常に処理されたことを示す応答を受け取る前)、送信者はメッセージがアドレスに正常に送信されたかどうかを知ることができません。
送信が受け取られ、処理された後 (ただし、応答が送信される前) にターゲットサーバーまたは接続が失敗した場合、メッセージはアドレスに正常に送信されますが、送信が受け取られ、処理が終了する前にターゲットサーバーまたは接続が失敗した場合は、メッセージがアドレスに正常に送信されません。送信者の観点から、これらの 2 つのケースを区別することはできません。
サーバーが回復すると、クライアントは困難な状況に置かれます。クライアントはターゲットサーバーで障害が発生したことを知っていますが、最後のメッセージがその宛先に正常に到達したかどうかを知りません。最後のメッセージを最送信する場合は、重複メッセージがアドレスに送信されることがあります。各メッセージが注文または取引の場合は、この結果注文が 2 回行われたり、取引が重複して記録されたりして、望まない状況が発生することがあります。
トランザクションでメッセージを送信することは正しい解決法ではありません。トランザクションコミットが処理されている間にサーバーまたは接続が失敗すると、トランザクションが正常にコミットされたかどうかがわかりません。
これらの問題を解決するために、HornetQ はアドレスに送信されたメッセージに対して自動重複メッセージ検出を提供します。

35.1. メッセージの送信に重複検出を使用

送信されたメッセージに対して重複メッセージ検出を有効にします。メッセージの特別なプロパティーに作成された一意の値を設定します。ターゲットサーバーはメッセージを受信すると、そのプロパティーが設定されているかどうかを確認します。設定されている場合、ターゲットサーバーはメモリキャッシュで、このヘッダーの値を持つメッセージがすでに受信されているかどうかを確認します。以前に同じ値を持つメッセージを受信した場合は、メッセージが無視されます。

注記

ノード間でメッセージを移動するために重複検出を使用する場合は、ソースからメッセージを消費し、ターゲットに送信するために XA トランザクションが使用されたときと同じ1 度だけの配信保証が提供されます (ただし、XA を使用する場合よりもオーバーヘッドが少なくなり、設定が大幅に簡単になります)。
トランザクションでメッセージを送信する場合は、そのトランザクションで送信されたメッセージに対してプロパティーを設定する必要はありません。それはトランザクションで 1 度だけ設定します。サーバーがトランザクションの任意のメッセージに対して重複メッセージを検出した場合は、トランザクション全体が無視されます。
設定されたプロパティーの名前は org.hornetq.api.core.HDR_DUPLICATE_DETECTION_ID の値 (_HQ_DUPL_ID) です。
プロパティの値のタイプは byte[] または SimpleString (コア API を使用する場合) のいずれかです。JMS を使用している場合は、String である必要があり、その値は一意である必要があります。一意の ID を生成する簡単な方法は UUID を生成することです。
コア API を使用してプロパティーを設定する例は次のとおりです。
...     

ClientMessage message = session.createMessage(true);

SimpleString myUniqueID = "This is my unique id";   // Could use a UUID for this

message.setStringProperty(HDR_DUPLICATE_DETECTION_ID, myUniqueID);

...
JMS API を使用する例は次のとおりです。
...     

Message jmsMessage = session.createMessage();

String myUniqueID = "This is my unique id";   // Could use a UUID for this

message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID);

...

35.2. 重複 ID キャッシュの設定

サーバーは、各アドレスに送信された org.hornetq.core.message.impl.HDR_DUPLICATE_DETECTION_ID プロパティーの受信された値のキャッシュを保持します。各アドレスは独自のキャッシュを持ちます。
キャッシュは循環型固定サイズキャッシュです。キャッシュの最大サイズが n 要素の場合は、格納された n + 1 番目の ID がキャッシュ内の 0 番目の要素を上書きします。
キャッシュの最大サイズは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のパラメーター id-cache-size によって設定されます。デフォルト値は 2000 (要素) です。
また、キャッシュはディスクに保持するか、保持しないように設定できます。これは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のパラメーター persist-id-cache によって設定されます。これが true に設定された場合は、各 ID が受信されたときに永久ストレージに保持されます。このパラメーターのデフォルト値は true です。

注記

重複する ID キャッシュに対するサイズを選択する場合は、以前に送信されたメッセージが上書きされないように十分に大きなサイズに設定してください。

35.3. 重複検出およびブリッジ

コアブリッジは、メッセージをターゲットに転送する前に一意の重複 ID 値 (メッセージにすでにこれが存在しない場合) を自動的に追加するよう設定できます。これにより、ターゲットサーバーがクラッシュした場合や接続が中断され、ブリッジがメッセージを再送信した場合は、ターゲットサーバーによりすでにメッセージが受信されたときに、これは無視されます。
重複 ID ヘッダーを追加するようコアブリッジを設定するには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml でブリッジを設定するときに use-duplicate-detectiontrue に設定します。
このパラメーターのデフォルト値は true です。
コアブリッジの詳細と、コアブリッジの設定方法については、34章コアブリッジ を参照してください。

35.4. 重複検出およびクラスター接続

クラスター接続は内部的にコアブリッジを使用してクラスターのノード間で信頼できるメッセージを移動します。結果的に、クラスター接続は、内部ブリッジを使用して移動された各メッセージに対して重複 ID ヘッダーを挿入するよう設定することもできます。
重複 ID ヘッダーを追加するようクラスター接続を設定するには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml でクラスター接続を設定するときに use-duplicate-detectiontrue に設定します。
このパラメーターのデフォルト値は true です。
クラスター接続の詳細と、クラスター接続の設定方法については、36章クラスター を参照してください。

35.5. 重複検出およびページング

HornetQ は、メッセージをストレージにページングするときに重複検出を使用します。サーバーの障害発生時にメッセージがストレージからページ解除された場合は、複数のメッセージがページ解除された状況で結果的に配信が重複することが回避されます。
ページングとページングの設定方法の詳細については、22章ページング を参照してください。

第36章 クラスター

36.1. クラスターの概要

HornetQ クラスターを使用すると、メッセージ処理の負荷を共有するために HornetQ サーバーのグループを一緒にまとめることができます。クラスター内の各アクティブノードは、独自のメッセージを管理し、独自の接続を処理するアクティブな HornetQ サーバーです。サーバーをクラスター化するよう設定するには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlclustered 要素を true (デフォルト値は false) に設定する必要があります。

重要

/hornetq ディレクトリにすでに含まれるプロファイルに対してクラスタリングを有効にする必要があります (MinimalWeb を除くすべてのプロファイル)。/hornetq ディレクトリに含まれないプロファイルには、クラスターをサポートする適切なネイティブコンポーネントが含まれません。
クラスターは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で他のノードへのクラスター接続を宣言する各ノードによって形成されます。ノードが別のノードに対するクラスター接続を形成する場合は、内部的にそのノードと他のノード間のコアブリッジ (34章コアブリッジ を参照) 接続が作成され、この処理が背後で透過的に行われます。各ノードに対して明示的なブリッジを宣言する必要はありません。これらのクラスター接続を使用すると、負荷を分散するためにクラスターのノード間でメッセージを移動できます。
複数のノードを一緒に接続してさまざまなトポロジーのクラスターを形成することができます。一般的なトポロジーについては、この章の後半で説明します。
クラスタのノード全体でクライアント接続を分散できるクライアントサイドロードバランシングについて説明します。また、HornetQ がノード間でメッセージを再分散して枯渇を回避するメッセージ再分散についても説明します。
クラスタリングの他の重要な部分は、クライアントまたは他のサーバーが最小の設定で接続できるようサーバーが接続詳細をブロードキャストできるサーバー検出です。

警告

JBoss Enterprise Application Platform インスタンスを 'localhost' にバインドされた HornetQ サーバーで起動した場合、HornetQ インスタンスは同じネットワーク上の別の HornetQ インスタンスとクラスターを形成できます。localhost にバインドした場合は、HornetQ サーバーに対してクラスターの隔離が提供されません。
クラスターを正常に隔離するには、 「ブロードキャストグループ」 を参照して適切にブロードキャストを設定し、各サーバーのアドレスを検出します。

36.2. サーバー検出

サーバー検出はサーバーが接続詳細を以下のものに伝播できるメカニズムです。
  • メッセージングクライアント。メッセージングクライアントは、ある時点で稼動しているクラスター内のサーバーを認識せずにクラスターのサーバーに接続できます。
  • 他のサーバー。クラスター内のサーバーは、クラスター内の他のすべてのサーバーについて事前に認識せずにお互いのクラスター接続を作成できます。
サーバー検出は User Datagram Protocol (UDP) マルチキャストを使用してサーバー接続設定をブロードキャストします。UDP がネットワークで無効な場合は、これを使用することはできず、クラスターの設定時やメッセージングクライアントの使用時にサーバーを明示的に指定する必要があります。

36.2.1. ブロードキャストグループ

ブロードキャストグループは、サーバーがネットワーク上に接続をブロードキャストする手段です。コネクターはクライアント (または他のサーバー) がサーバーとの接続を確立する方法を定義します。コネクターの詳細については、14章トランスポートの設定 を参照してください。
ブロードキャストグループは一連のコネクターペアを取得し、各コネクターペアにはライブの (オプション) のバックアップサーバーの接続設定が含まれ、ネットワークに接続設定がブロードキャストされます。また、UDP アドレスとポートの設定も定義されます。
ブロードキャストグループは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されます。1 つの HornetQ サーバーに対して多くのブロードキャストグループが存在することがあります。すべてのブロードキャストグループは、broadcast-groups 要素で定義する必要があります。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のブロードキャストグループの例を見てみましょう。
<broadcast-groups>
   <broadcast-group name="my-broadcast-group">
      <local-bind-address>172.16.9.3</local-bind-address>
      <local-bind-port>5432</local-bind-port>
      <group-address>231.7.7.7</group-address>
      <group-port>9876</group-port>
      <broadcast-period>2000</broadcast-period>
      <connector-ref connector-name="netty" 
        backup-connector-name="backup-connector"/>
   </broadcast-group>
</broadcast-groups>
ブロードキャストグループパラメータの一部はオプションであり、通常デフォルト値が使用されますが、わかりやすくするために上記の例ではすべてが指定されています。それぞれについては以下で説明します。

ブロードキャストグループパラメータ

name
サーバー内の各ブロードキャストグループは、サーバーで一意の名前を持つ必要があります。
local-bind-address
これは、データグラムソケットがバインドされるローカルバインドアドレスです。サーバーに複数のネットワークインターフェースがある場合は、このプロパティを設定してブロードキャストに使用するものを指定します。このプロパティが指定されない場合は、ソケットがワイルドカードアドレスとカーネルにより選択された IP アドレスにバインドされます。
local-bind-port
データグラムソケットがバインドされるローカルポートを指定する場合は、ここで指定できます。通常は、匿名ポートを使用することを示すデフォルト値 -1 を使用します。このパラメータは、常に local-bind-address とともに指定されます。
group-address
これは、データをブロードキャストするマルチキャストアドレスであり、範囲が 224.0.0.0239.255.255.255 のクラス D IP アドレスです。アドレス 224.0.0.0 は予約されており、使用できません。このパラメータは必須です。
group-port
これはブロードキャストに使用される UDP ポート番号です。このパラメータは必須です。
broadcast-period
これは、連続するブロードキャスト間の時間 (ミリ秒単位) です。このパラメータはオプションであり、デフォルト値は 2000 ミリ秒です。
connector-ref
これは、ブロードキャストするコネクターとオプションのバックアップコネクターを指定します (コネクターの詳細については、14章トランスポートの設定 を参照してください)。ブロードキャストするコネクターは connector-name 属性により指定され、ブロードキャストするバックアップコネクターは backup-connector 属性によって指定されます。backup-connector 属性はオプションです。

36.2.2. 検出グループ

ブロードキャストグループはコネクター情報がサーバーからどのようにブロードキャストされるかを定義しますが、検出グループはコネクター情報をマルチキャストアドレスからどのように受け取るかを定義します。
検出グループは接続ペアのリストを保持します (さまざまなサーバーの各ブロードキャストに対して 1 つ)。特定のサーバーからマルチキャストグループ上にブロードキャストを受け取ると、リスト内のそのサーバーのエントリが更新されます。
ある時間の間特定のサーバーからブロードキャストを受け取らない場合は、そのサーバーのエントリがリストから削除されます。
検出グループは HornetQ の以下の 2 つの場所で使用されます。
  • クラスタ接続。接続を確立する必要があるクラスター内の他のサーバーについて認識できます。
  • メッセージングクライアント。接続できるクラスター内のサーバーを検出できます。
検出グループは常にブロードキャストを受け入れますが、利用可能なライブおよびバックアップサーバーの現在のリストは、最初の接続が確立された場合のみ使用されます。これ以降、サーバー検出は通常の HornetQ 接続に対して行われます。

36.2.3. サーバー上の検出グループを定義

クラスター接続の場合、検出グループは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されます。すべての検出グループは、discovery-groups 要素内で定義する必要があります。HornetQ サーバーでは多くの検出グループを定義できます。以下に例を示します。
<discovery-groups>
   <discovery-group name="my-discovery-group">
      <local-bind-address>172.16.9.7</local-bind-address>
      <group-address>231.7.7.7</group-address>
      <group-port>9876</group-port>
      <refresh-timeout>10000</refresh-timeout>
   </discovery-group>
</discovery-groups>
検出グループの各パラメータは以下のように見なされます。

検出グループパラメータ

name
各検出グループは、サーバーごとに一意の名前を持つ必要があります。
local-bind-address
同じマシンで複数のネットワークインターフェースを使用している場合は、検出グループが特定のインターフェースのみをリッスンするよう指定できます。これを行うには、このパラメータでインターフェースアドレスを指定できます。このパラメータはオプションです。
group-address
これは、リッスンするグループのマルチキャスト IP アドレスです。これは、リッスンするブロードキャストグループの group-address に一致する必要があります。このパラメータは必須です。
group-port
これは、マルチキャストグループの UDP ポートです。これは、リッスンするブロードキャストグループの group-port に一致する必要があります。このパラメータは必須です。
refresh-timeout
これは、サーバーのコネクターペアエントリをリストから削除する前に、特定のサーバーから最後のブロードキャストを受け取るまで検出グループが待機する時間です。通常は、これをブロードキャストグループの broadcast-period よりも大幅に大きい値に設定します。このように設定しないと、タイミングの若干の違いから、ブロードキャストしているサーバーがリストから断続的に消失することがあります。このパラメータはオプションであり、デフォルト値は 10000 ミリ秒 (10 秒) です。

36.2.4. クライアントサイドの検出グループ

接続できるサーバーのリストを検出するために検出を使用するよう HornetQ クライアントを設定する方法について説明します。これを行う方法は、JMS を使用しているか、コア API を使用しているかによって異なります。

36.2.4.1. JMS を使用したクライアント検出の設定

JMS を使用しており、JMS 接続ファクトリーインスタンスを JNDI にロードするためにサーバー上で JMS サービスを使用している場合は、サーバーサイド XML 設定 JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で JMS 接続に使用する検出グループを指定できます。以下に例を示します。
<connection-factory name="ConnectionFactory">
   <discovery-group-ref discovery-group-name="my-discovery-group"/>
    <entries>
       <entry name="/ConnectionFactory"/>
    </entries>
</connection-factory>
要素 discovery-group-ref は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義された検出グループの名前を指定します。
この接続ファクトリーがクライアントアプリケーションによって JNDI からダウンロードされ、JMS 接続が接続ファクトリーから作成された場合、これらの接続は、検出グループ設定で指定されたマルチキャストアドレスでリッスンすることによって検出グループが保持するサーバーのリスト全体で、負荷分散されます。
JMS を使用しているが、接続ファクトリーをルックアップするために JNDI を使用していない場合 (JMS 接続ファクトリーを直接インスタンス化する場合) は、JMS 接続ファクトリーの作成時に検出グループパラメータを直接指定できます。以下に例を示します。
final String groupAddress = "231.7.7.7";

final int groupPort = 9876;

ConnectionFactory jmsConnectionFactory = 
   HornetQJMSClient.createConnectionFactory(groupAddress, groupPort);

Connection jmsConnection1 = jmsConnectionFactory.createConnection();

Connection jmsConnection2 = jmsConnectionFactory.createConnection();
refresh-timeout は、setter メソッド setDiscoveryRefreshTimeout() を使用して接続ファクトリーで直接設定できます (デフォルト値を変更する場合)。
また、setter メソッド setDiscoveryInitialWaitTimeout() を使用して接続ファクトリーで設定できる他のパラメータもあります。作成後にすぐに接続ファクトリーを使用する場合は、クラスター内のすべてのノードからブロードキャストを受け取るのに十分な時間がないことがあります。最初に使用する場合、接続ファクトリーによって、最初の接続を作成する前に十分に長い時間を待つようになります。このパラメータのデフォルト値は、10000 ミリ秒です。

36.2.4.2. コアを使用したクライアント検出の設定

コア API を使用して直接ClientSessionFactory インスタンスをインスタンス化する場合は、セッションファクトリーの作成時に検出グループパラメータを直接指定できます。以下に例を示します。
final String groupAddress = "231.7.7.7"; 
final int groupPort = 9876;
SessionFactory factory = HornetQClient.createClientSessionFactory
  (groupAddress, groupPort);
ClientSession session1 = factory.createClientSession(...); 
ClientSession session2 = factory.createClientSession(...);
refresh-timeout は、setter メソッド setDiscoveryRefreshTimeout() を使用してセッションファクトリーで直接設定できます (デフォルト値を変更する場合)。
また、setter メソッド setDiscoveryInitialWaitTimeout() を使用してセッションファクトリーで設定できる他のパラメータもあります。作成後にすぐにセッションファクトリーを使用する場合は、クラスター内のすべてのノードからブロードキャストを受け取るのに十分な時間がないことがあります。最初に使用する場合、セッションファクトリーによって、最初のセッションを作成する前に十分に長い時間を待つようになります。このパラメータのデフォルト値は、10000 ミリ秒です。

36.3. サーバーサイドメッセージロードバランシング

クラスターのノード間でクラスター接続が定義された場合は、HornetQ が特定のノードに到着するメッセージをクライアントから負荷分散します。
シンメトリッククラスター (「シンメトリッククラスター」 で説明) で配置された 4 つのノード A、B、C、および D の単純な例を見てみましょう。OrderQueue と呼ばれるキューがクラスターの各ノードにデプロイされます。
クライアント Ca はノード A に接続され、サーバーに順序を送信します。また、順序プロセッサークライアント Pa、Pb、Pc、および Pd は各ノード A、B、C、D に接続されます。クラスター接続がノード A で定義されない場合、順序メッセージはノード A に到着したときにノード A の OrderQueue にすべて格納され、ノード A、Pa に接続された順序プロセッサークライアントによって消費されます。
ノード A 上のクラスター接続が定義されている場合、順序が決定されたメッセージはノード A に到着したときに、すべてがローカルの OrderQueue インスタンスに格納される代わりに、クラスターのすべてのノード間でラウンドロビン形式で分散されます。メッセージは受け取り側のノードからクラスターの他のノードに転送されます。これは、サーバーサイドで行われ、クライアントはノード A に対する単一の接続を保持します。
たとえば、ノード A に到着したメッセージは、ノード間で B、D、C、A、B、D、C、A、B、D という順序で分散できます。正確な順序は、ノードが起動された順序に基づきますが、使用されるアルゴリズムはラウンドロビンです。

36.3.1. クラスター接続の設定

クラスター接続は、クラスターのノード間でメッセージを負荷分散できるようサーバーをクラスターにグループ分けします。一般的なクラスター接続は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlcluster-connection 要素内で定義されます。1 つの HornetQ サーバーごとにゼロ以上のクラスター接続を定義できます。
<cluster-connections>
   <cluster-connection name="my-cluster">
      <address>jms</address>
      <retry-interval>500</retry-interval>
      <use-duplicate-detection>true</use-duplicate-detection>
      <forward-when-no-consumers>false</forward-when-no-consumers>
      <max-hops>1</max-hops>
      <discovery-group-ref discovery-group-name="my-discovery-group"/>
   </cluster-connection>
</cluster-connections>
上記のクラスター接続では、すべてのパラメータが明示的に指定されています。実際には、一部についてデフォルト値を使用できます。
  • address。各クラスター接続は、この値で始まるアドレスに送信されたメッセージにのみ適用されます。
    この場合、このクラスター接続は jms で始まるアドレスに送信されたメッセージを負荷分散します。このクラスター接続は、サブ文字列 "jms" で始まるコアキューにマップされるため、すべての JMS キューとトピックサブスクリプションに適用されます。
    アドレスとして任意の値を指定でき、address のさまざまな値を持つ多くのクラスター接続を持つことができます (同時にこれらのアドレスに対するメッセージがサーバーのさまざまなクラスターに分散されます)。さまざまなアドレスで複数のクラスター接続を持つことにより、単一の HornetQ サーバーは効果的に複数のクラスターに同時に参加できます。
    address の重複する値 (たとえば、"europe" と "europe.news") を持つ複数のクラスター接続を作成しないよう注意してください。このようなクラスター接続を作成すると、同じメッセージが複数のクラスター接続間で分散され、配信が重複することがあります。
    このパラメータは必須です。
  • discovery-group-ref。このパラメータは、このクラスター接続が接続を確立するクラスターの他のサーバーのリストを取得するために使用する検出グループを決定します。
  • forward-when-no-consumers。このパラメータは、一致が存在するか、他のノードにコンシューマーが存在するかどうかに関係なく、クラスターの他のノード間でメッセージをラウンドロビン形式で分散するかどうかを決定します。
    これが true に設定されたとき、クラスターの他のノードの同じキューがコンシューマーをまったく持つことができない場合や、一致するメッセージフィルター (セレクター) を持たないコンシューマーを持つことができる場合であっても、各受信メッセージはラウンドロビン形式で処理されます。他のノードに同じ名前のキューが存在しない場合は、このパラメータが true に設定された場合であっても、HornetQ はメッセージを他のノードに転送しません。
    これが false に設定された場合、HornetQ はクラスターの他のノードにのみメッセージを転送します (メッセージが転送されるアドレスがコンシューマーを持つキューを持っている場合)。これらのコンシューマーがメッセージフィルター (セレクター) を持っている場合は、これらのセレクターの少なくとも 1 つがメッセージに一致する必要があります。
    このパラメータはオプションであり、デフォルト値は false です。
  • max-hops。クラスター接続がメッセージを 負荷分散できるノードのセットを決定する場合、これらのノードはクラスター接続を介して直接接続する必要はありません。HornetQ は、チェーンの中間として他の HornetQ サーバーと間接的にのみ接続できるノードに対してメッセージを負荷分散するよう設定することもできます。
    これにより、HornetQ をより複雑なトポロジーで設定し、メッセージの負荷分散を提供できます。これについては、この章の後半で説明します。
    このパラメータのデフォルト値は 1 であり、メッセージは、このサーバーに直接接続された他の HornetQ サーバーに対してのみ負荷分散されます。このパラメータはオプションです。
  • min-large-message-size。このパラメータは、サイズのしきい値を決定します。この値よりも上になると、クラスターを介して送信するときに、メッセージが複数のパッケージに分割されます。このパラメータはオプションであり、デフォルト値は100 KiB です。
  • reconnect-attempts。このパラメータは、システムがクラスター上のノードに接続しようとする回数を決定します。最大再試行回数に到達すると、このノードが永久的にダウンしていると見なされ、メッセージのルーティングが停止されます。このパラメータはオプションであり、デフォルト値は -1 (無限再試行回数) です。
  • retry-interval。内部的に、クラスター接続により、クラスターのノード間でブリッジが作成されます。クラスター接続が作成され、ターゲットノードが起動しない場合 (またはリブートされる場合)、他のノードからのクラスター接続が、ターゲットノードが再び起動されるまでブリッジと同じ方法でターゲットノードへの接続を再試行します。
    このパラメータは、再試行の間の時間 ( ミリ秒単位) を決定します。これはブリッジでの retry-interval と同じ意味を持ちます (34章コアブリッジ で説明)。
    このパラメータはオプションであり、デフォルト値は 500 ミリ秒です。
  • use-duplicate-detection。内部的に、クラスター接続はブリッジを使用してノードをリンクし、ブリッジは転送される各メッセージの重複する ID プロパティを追加するよう設定できます。ブリッジのターゲットノードがクラッシュし、回復すると、メッセージは 2 つ目のノードから再送信できます。重複検出を有効にすることにより、すべての重複メッセージはターゲットノードでの受信時にフィルタリングされ、無視されます。
    このパラメータは、ブリッジでの use-duplicate-detection と同じ意味を持ちます。重複検出の詳細については、35章重複メッセージ検出 を参照してください。
    このパラメータはオプションであり、デフォルト値は true です。

36.3.2. クラスターユーザークレデンシャル

クラスター接続を形成するためにクラスターのノード間で接続を作成する場合、HornetQ は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されたクラスターユーザーとクラスターパスワードを使用します。
                <cluster-user>HORNETQ.CLUSTER.ADMIN.USER</cluster-user>
                <cluster-password>CHANGE ME!!</cluster-password>

警告

これらの値はデフォルト値から変更する必要があります。または、リモートクライアントはデフォルト値を使用してサーバーに接続できる必要があります。デフォルト値から変更されないと、HornetQ はこれを検出し、起動するたびに警告が表示されます。

36.4. クライアントサイドロードバランシング

HornetQ のクライアントサイドロードバランシングにより、単一のセッションファクトリーを使用して作成された後続のセッションはクラスターのさまざまなノードに接続できます。これにより、セッションはクラスターのノード間で円滑に分散でき、特定のノードに「集中する」ことがなくなります。
クライアントファクトリーにより使用されるロードバランシングポリシーは設定可能です。HornetQ には 2 つのすぐに使用できるロードバランシングポリシーが用意されており、独自のポリシーを実装し、使用することもできます。
すぐに使用できるポリシーは以下のとおりです。
  • ラウンドロビン。このポリシーを使用すると、最初のノードがランダムに選択され、後続の各ノードが同じ順序で順番に選択されます。
    たとえば、ノードは B、C、D、A、B、C、D、A、B または D、A、B、C、A、B、C、D、A、または C、D、A、B、C、D、A、B、C、D、A の順序で選択できます。
  • ラインダム。このポリシーでは、各ノードがランダムに選択されます。
インターフェース org.hornetq.api.core.client.loadbalance.ConnectionLoadBalancingPolicy を実装することにより、独自のポリシーを実装できます。
使用するロードバランシングポリシーの指定は、JMS を使用するか、コア API を使用するかによって異なります。ポリシーを指定しない場合は、デフォルト値 org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy が使用されます。
JMS を使用し、サーバーで JNDI を使用して JMS 接続ファクトリーを JNDI に格納する場合は、以下のようにサーバーの JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml 設定ファイルでロードバランシングポリシーを直接指定できます。
<connection-factory name="ConnectionFactory">
   <discovery-group-ref discovery-group-name="my-discovery-group"/>
   <entries>
      <entry name="/ConnectionFactory"/>
   </entries>
   <ha>true</ha>
   <connection-load-balancing-policy-class-name>
    org.hornetq.api.core.client.loadbalance.RandomConnectionLoadBalancingPolicy
   </connection-load-balancing-policy-class-name>
</connection-factory>
上記の例では、ランダムな接続ロードバランシングポリシーを使用する JMS 接続ファクトリーがデプロイされます。
JMS を使用し、クライアントサイドで接続ファクトリーを直接インスタンス化する場合は、使用前に HornetQConnectionFactory で setter を使用してロードバランシングポリシーを設定できます。
ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactory(...);
jmsConnectionFactory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
コア API を使用する場合は、使用している ClientSessionFactory インスタンスで直接ロードバランシングポリシーを設定できます。
ClientSessionFactory factory = HornetQClient.createClientSessionFactory(...);
factory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
ファクトリーが負荷分散するサーバーのセットは以下の 2 つのいずれかの方法で決定できます。
  • サーバーを明示的に指定
  • 検出の使用。

36.5. クラスターのメンバーを明示的に指定

場合によっては、UDP がネットワークで有効にならず、クライアントがクラスター内のサーバーのリストを検出する、またはサーバーがクラスター内の他のサーバーを検出するために、UDP サーバー検出を使用できないことがあります。
この場合、クラスター内のサーバーのいるとは各ノードとクライアントサイドで明示的に指定できます。これは以下のように行います。

36.5.1. クライアントサイドでのサーバーのリストの指定

これは、JMS を使用するかコア API を使用するかによって異なります。

36.5.1.1. JMS を使用してサーバーのリストを指定

JMS と JMS サービスを使用して JMS 接続ファクトリーインスタンスをサーバーの JNDI に直接ロードする場合は、サーバーサイドの設定ファイル JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml でサーバーのリストを指定できます。以下に例を示します。
<connection-factory name="ConnectionFactory">
   <connectors>
      <connector-ref connector-name="my-connector1" 
       backup-connector-name="my-backup-connector1"/>
      <connector-ref connector-name="my-connector2" 
       backup-connector-name="my-backup-connector2"/>
      <connector-ref connector-name="my-connector3" 
       backup-connector-name="my-backup-connector3"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>
   </entries>
</connection-factory>
connection-factory 要素には、ゼロ個以上の connector-ref 要素を含めることができます。これらの各要素はconnector-name 属性とオプションの backup-connector-name 属性を指定します。connector-name 属性はライブコネクターとして使用される JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で定義されたコネクターを参照します。backup-connector-name はオプションであり、指定された場合は、hornetq-configuration.xml で定義されたコネクターも参照します。コネクターの詳細については、14章トランスポートの設定 を参照してください。
接続ファクトリーは [コネクター, バックアップコネクター] のペアのリストを保持します。これらのペアは、クラスターへの接続の作成時にクライアントサイドでクライアント接続ロードバランシングポリシーによって使用されます。
JMS を使用し、JNDI を使用していない場合は、HornetQConnectionFactory をインスタンス化するときに [コネクター, バックアップコネクター] ペアのリストを直接指定することもできます。
List<Pair<TransportConfiguration, TransportConfiguration>> serverList = 
        new ArrayList<Pair<TransportConfiguration, TransportConfiguration>>();

serverList.add(new Pair<TransportConfiguration, 
        TransportConfiguration>(liveTC0, backupTC0));
serverList.add(new Pair<TransportConfiguration, 
        TransportConfiguration>(liveTC1, backupTC1));
serverList.add(new Pair<TransportConfiguration, 
        TransportConfiguration>(liveTC2, backupTC2));

ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactory(serverList);

Connection jmsConnection1 = jmsConnectionFactory.createConnection();

Connection jmsConnection2 = jmsConnectionFactory.createConnection();
上記のコード例により、TransportConfiguration オブジェクトのペアのリストが作成されます。各 TransportConfiguration オブジェクトには、特定のサーバーと接続を確立する方法に関する情報が含まれます。
HornetQConnectionFactory インスタンスを作成してコンストラクターのサーバーのリストを渡します。このファクトリーにより作成されたすべてのコネクターは、サーバーのリストに適用されたクライアント接続のロードバランシングポリシーに従って、接続を作成します。

36.5.1.2. コア API を使用したサーバーのリストの指定

以下の例のように、ClientSessionFactory インスタンスの作成時にサーバーのリストを直接指定します。
List<Pair<TransportConfiguration, TransportConfiguration>> serverList = 
        new ArrayList<Pair<TransportConfiguration, TransportConfiguration>>();

serverList.add(new Pair<TransportConfiguration, 
        TransportConfiguration>(liveTC0, backupTC0));
serverList.add(new Pair<TransportConfiguration, 
        TransportConfiguration>(liveTC1, backupTC1));
serverList.add(new Pair<TransportConfiguration, 
        TransportConfiguration>(liveTC2, backupTC2));

ClientSessionFactory factory = HornetQClient.createClientSessionFactory(serverList);

ClientSession session1 = factory.createClientSession(...);

ClientSession session2 = factory.createClientSession(...);
上記のコード例により、TransportConfiguration オブジェクトのペアのリストが作成されます。各 TransportConfiguration オブジェクトには、特定のサーバーと接続を確立する方法に関する情報が含まれます。この詳細については、14章トランスポートの設定 を参照してください。
ClientSessionFactoryImpl インスタンスが作成され、コンストラクターでサーバーのリストが渡されます。このファクトリーにより作成されたすべてのセッションは、サーバーのリストに適用されたクライアント接続のロードバランシングポリシーに従ってセッションを作成します。

36.5.2. 静的なクラスターサーバーリストの指定

各ノードが順番に利用可能なノードを検出できるように、シンメトリッククラスターを定義し、静的なサーバー検出を使用しないようにすることができます。各クラスター接続がクラスター内の他のすべてのノードを明示的に認識するよう設定することが必要です。

重要

静的なクラスターサーバーリストを使用して定義されたクラスターではフェイルオーバーがサポートされません。クラスターノード間でのフェイルオーバーをサポートするには、ノードが検出グループを使用するよう設定する必要があります。

タスク: 自動検出なしでクラスターサーバーリストを指定する

このタスクを完了して、サーバー自動検出を使用する代わりに静的なクラスターサーバーリストを指定します。

前提条件

  • JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルがオープンであり、ディレクティブを追加できる。
  • hornetq-configuration.xml 設定ディレクティブ (「hornetq-configuration.xml」 で詳細に説明)。
  1. コネクターの定義

    hornetq-configuraton.xml ファイルで、リモートコネクターファクトリーを定義する <connectors> ディレクトリブロック、コネクターの名前、および各コネクターが使用するポートを挿入します。
    各コネクターは一意のポートを使用する必要があります。
    <connectors>
      <connector name="netty-connector">
        <factory-class>
         org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
        </factory-class>
      <param key="port" value="5445"/>
    </connector>
    <!-- connector to the server1 -->
      <connector name="server1-connector">
        <factory-class>
         org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
        </factory-class>
        <param key="port" value="5446"/>
      </connector>
    <!-- connector to the server2 -->
      <connector name="server2-connector">
        <factory-class>
         org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
        </factory-class>
        <param key="port" value="5447"/>
      </connector>
    </connectors>
  2. クラスター接続の定義

    <cluster-connection> ディレクティブブロックを挿入します。このブロックには、必須のクラスタリングディレクティブ、前の手順で設定した <connector-ref> ディレクティブが含まれている必要があります。<connector-ref> ディレクティブは、<connector> ディレクティブで設定された名前属性を使用します。
    <cluster-connections>
      <cluster-connection name="my-cluster">
        <address>jms</address>
        <connector-ref>netty-connector</connector-ref>
        <retry-interval>500</retry-interval>
        <use-duplicate-detection>true</use-duplicate-detection>
        <forward-when-no-consumers>true</forward-when-no-consumers>
        <max-hops>1</max-hops>
        <static-connectors>
          <connector-ref>server1-connector</connector-ref>
          <connector-ref>server2-connector</connector-ref>
        </static-connectors>
      </cluster-connection>
    </cluster-connections>
  3. 結果

    クラスターは、明示的なサーバー名を使用してサーバー検出に必要なディレクティブで定義されます。

36.6. メッセージ再分散

クラスタリングの別の重要な部分はメッセージ再分散です。以前に、サーバーサイドのメッセージロードバランシングがどのようにラウンドロビンで処理されるか、またはメッセージをどのようにクラスター全体のすべてのノードに送信するかが示されました。forward-when-no-consumers が false の場合、メッセージは一致するコンシューマーを持たないノードに転送されません。これによって、メッセージを消費するコンシューマーを持たないキューにメッセージが到着しないようになりますが、解決されない状況が発生します。メッセージがノードに送信された後にキューのコンシューマーがクローズした場合は何が起こりますか? キューにコンシューマーがない場合は、メッセージが消費されず、枯渇の状況が発生します。
メッセージ再分散はこの問題を解決し、HornetQ を設定して、一致するコンシューマーを持つクラスター内の他のノードに戻すコンシューマーがないキューからメッセージを自動的に再分散できます。
メッセージ再分散がキューの最後のコンシューマーがクローズされた直後に実行されるよう設定したり、メッセージ再分散が、キューの最後のコンシューマーが再分散の前にクローズされた後に設定可能な遅延を待つよう設定したりできます。デフォルトでは、メッセージ再分散が 60000 ミリ秒 (1 分) の遅延で有効になります。
メッセージ再分散は、アドレス設定で再分散遅延を指定することにより、アドレスごとに設定できます。アドレス設定の詳細については、23章キュー属性 を参照してください。
キューのセットに対してメッセージ再分散がどのように有効になるかを示す JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml のアドレス設定のコード例を以下に示します。
<address-settings>     
   <address-setting match="jms.#">
      <redistribution-delay>0</redistribution-delay>
   </address-setting>
</address-settings>
上記の address-settings ブロックは、"jms" で始まるアドレスにバインドされるキューに対して 0redistribution-delay を設定します。すべての JMS キュートトピックサブスクリプションは "jms" で始まるアドレスにバインドされるため、上記のコード例により、すべての JMS キューとトピックサブスクリプションがすぐに再分散されます (遅延なし)。
属性 match は完全一致、または HornetQ ワイルドカード構文に準拠する文字列になります (11章HornetQ ワイルドカード構文について で説明)。
要素 redistribution-delay は、メッセージがキューから、一致するコンシューマーを持たないクラスターの他のノードに再分散する前に、最後のコンシューマーがキューでクローズされるまでの遅延 (ミリ秒単位) を定義します。ゼロの遅延は、メッセージがすぐに再分散されることを意味します。値が -1 の場合は、メッセージが再分散されません。
再分散の前に遅延を発生させることが適切なことがよくあります。これは、コンシューマーがクローズしても、別のコンシューマーが同じキューにすぐに作成されるからです。この場合は、新しいコンシューマーが到着した直後に再分散したくないことが考えられます。

36.7. クラスタートポロジー

HornetQ クラスターはさまざまなトポロジーでお互いに接続できます。以下に最も一般的な 2 つのトポロジーを示します。

36.7.1. シンメトリッククラスター

シンメトリッククラスターはおそらく最も一般的なクラスタートポロジーであり、JBoss Application Server クラスタリングの経験がある場合は、すでに使用したはずです。
シンメトリッククラスターでは、クラスター内の各ノードがクラスター内の他の各ノードに接続されます。クラスター内の各ノードは他の各ノードから 1 ホップを超えません。
シンメトリッククラスターを形成するために、クラスター内の各ノードは属性 max-hops1 に設定されたクラスター接続を定義します。通常、クラスター接続は、接続すべきクラスター内の他のサーバーを認識するためにサーバー検出を使用します。ただし、たとえば、UDP がネットワークで利用できない場合に、クラスター接続で各ターゲットサーバーを明示的に定義することができます。
シンメトリッククラスターでは、各ノードは、他のすべてのノードに存在するすべてのキューとキューにあるコンシューマーについて認識します。これにより、各ノードは、ノードでメッセージを負荷分散および再分散する方法を決定できます。

36.7.2. チェーンクラスター

チェーンクラスターでは、クラスター内の各ノードは、クラスター内の各ノードに直接接続されません。代わりに、ノードは、チェーンを形成します (チェーンの各エンドのノードと他のすべてのノードがチェーンの前と次のノードに接続します)。
この例では、ノード A、B、および C から構成される 3 つのノードチェーンになります。ノード A は 1 つのネットワークでホストされ、多くのプロデューサークライアントが接続され、順序メッセージを送信します。企業のポリシーのため、順序コンシューマークライアントは異なるネットワークでホストする必要があり、そのネットワークには 3 番目のネットワークからのみアクセスできます。このセットアップでは、 B は、プロデューサーまたはコンシューマーが仲介者として機能します。ノード A に到着するすべてのメッセージはノード B に転送されます。ノード B はそれらのメッセージをノード C に転送し、ノード C でメッセージが消費されます。ノード A は直接 C に接続する必要はありませんが、すべてのノードはクラスターの一部として機能できます。
このようにクラスターを設定するために、ノード A がノード B に接続するクラスター接続を定義し、ノード B がノード C に接続するクラスター接続を定義します。この場合、クラスター接続は一方向のみ設定されることが期待されます。これは、メッセージがノード A->B->C でのみ移動し、C->B->A で移動しないためです。
このトポロジーの場合は、max-hops2 に設定します。値が 2 の場合は、ノード C に存在するキューとコンシューマーに関する情報が、ノード C からノード B、そしてノード A に伝播されます。ノード A は、メッセージが到着したときにノード B にメッセージ分散することを認識しています。ノード B にコンシューマー自体がない場合であっても、1 ホップ離れたところにコンシューマーを持つノード C があることを認識しています。

第37章 高可用性およびフェイルオーバー

高可用性は、1 つまたは複数のサーバーで障害が発生した後にシステムが稼動し続けることができる機能として定義されます。
高可用性の一部は、サーバーで障害が発生したときにあるサーバーから別のサーバーにクライアント接続が移行し、クライアントアプリケーションが稼動し続けることができる機能として定義されるフェイルオーバーです。

警告

HornetQ は、ジャーナルが存在するファイルシステムに対して安定し、信頼できる接続を必要とします。HornetQ とジャーナル間の接続が失われ、後で再確立されると、メッセージングの I/O エラーが発生します。このエラーは、「主要なイベント」と見なされ、復元するためにメッセージングシステムで手動で作業する必要があります (つまり、メッセージングシステムは再起動する必要があります)。これがクラスターノードで発生すると、他のノードが障害が発生したノードの負荷を引き継ぎます (このように設定されている場合)。

37.1. ライブ - バックアップペア

HornetQ では、サーバーのペアをライブ - バックアップ ペアとしてリンクできます。このリリースでは、各ライブサーバーに対して単一のバックアップサーバーがあります。バックアップサーバーは唯一のライブサーバーにより所有されます。バックアップサーバーは、フェイルオーバーが発生するまで動作しません。
フェイルオーバーの前に、ライブサーバーのみが HornetQ クライアントにサービスを提供し、バックアップサーバーはパッシブのままになるか、バックアップサーバーになるまで待機します。ライブサーバーがクラッシュするか、適切なモードで停止された場合、現在パッシブモードにあるバックアップサーバーはライブになり、別のバックアップサーバーはパッシブになります。フェイルオーバー後にライブサーバーが再起動されると、ライブサーバーは優先され、現在のライブサーバーがダウンしたときにライブになる次のサーバーになります。現在のライブサーバーで自動フェイルバックが許可されるよう設定されている場合は、バックアップとなるライブサーバーが検出され、自動的に停止します。

37.1.1. HA モード

HornetQ は、このリリースで共有ストアのみを提供します。レプリケーションは、今後のリリースに利用可能になる予定です。

注記

永続メッセージデータのみがフェイルオーバー後も保持されます。非永続メッセージデータはフェイルオーバー後に失われます。

37.1.1.1. データレプリケーション

レプリケーションは、今後の HornetQ リリースで利用可能にある予定です。

37.1.2. 共有ストア

共有ストアを使用する場合は、ライブおよびバックアップサーバーの両方が、共有ファイルシステムを使用して同じ全体データディレクトリ (ページングディレクトリ、ジャーナルディレクトリ、大きいメッセージ、バインディングジャーナルなど) を共有します。
フェイルオーバーが実行され、バックアップサーバーが引き継がれると、共有ファイルシステムから 永続ストレージがロードされ、クライアントは永続ストレージに接続できます。
このスタイルの高可用性は、ライブおよびバックアップノードの両方がアクセスできる共有ファイルシステムを必要とするため、データレプリケーションとは異なります。通常、この場合、Storage Area Network (SAN) のパフォーマンスは向上します。共有ジャーナルを保存するために NFS マウントなどの Network Attached Storage (NAS) を使用しないでください。この標準のデータ転送レートのため、NFS は理想的ではありません。
共有ストアの高可用性の利点は、ライブノードとバックアップノード間でレプリケーションが行われてないことです。つまり、通常の操作中にレプリケーションのオーバーヘッドのため、パフォーマンスが低下しません。
共有ストアのレプリケーションの欠点は、共有ファイルシステムが必要であり、バックアップサーバーがアクティベートされたときに、共有ストアからジャーナルをロードする (ストアのデータの量によってはしばらく時間がかかることがあります) 必要があることです。
通常の操作中に最大のパフォーマンスが必要であり、高速な SAN へのアクセスがあり、フェイルオーバーが若干低速でも許容できる (データの量に基づきます) 場合は、共有ストアの高可用性が推奨されます。

37.1.2.1. 設定

ライブおよびバックアップサーバーがストアを共有するよう設定する場合は、各ノードで両方の JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml ファイルを設定します。
<shared-store>true</shared-store>
また、バックアップサーバーは、バックアップとして明示的にフラグを付ける必要があります。
<backup>true</backup>
ライブ - バックアップ のペアが共有ストアと正常に機能するには、両方のサーバーで同じ共有場所 (「メッセージジャーナルの設定」 で説明) を参照するジャーナルディレクトリの場所を設定する必要があります。
ライブおよびバックアップのペアでは、ペアがクラスターの一部でない場合でも、クラスター接続を定義する必要があります。クラスター接続情報は、バックアップサーバーが、ライブサバーまたはクラスター内の他のずべてのノードに自身の存在をどのように通知するかを定義します。こお設定方法については、36章クラスター を参照してください。

37.1.2.2. ライブサーバーへのフェイルバック

ライブサーバーで障害が発生し、バックアップが引き継いだ後、ライブサーバーを再起動し、クライアントをフェイルバックしたい場合があります。これを行うには、元のライブサーバーを再起動し、新しいライブサーバーを停止します。これは、プロセス自体を終了するか、サーバーがシャットダウンするのを待つことにより、実行できます。
通常のサーバーシャットダウンでフェイルオーバーを実行することもできます。これを行うには、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で以下のプロパティーを true に設定します。
<failover-on-shutdown>true</failover-on-shutdown>
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で以下のプロパティーを設定することにより、古いライブサーバーが再び稼動し、元のライブサーバーが自動的に引き継ぐことができる場合に新しいライブサーバーを強制的にシャットダウンできます。
<allow-failback>true</allow-failback>

37.2. フェイルオーバーモード

HornetQ は以下の 2 つの種類のクライアントフェイルオーバーを定義します。
  • 自動クライアントフェイルオーバー
  • アプリケーションレベルのクライアントフェイルオーバー
HornetQ は、同じサーバーに対する透過的な自動再接続を提供します (たとえば、一時的なネットワーク障害の場合)。これは、接続が同じサーバーに対して最実行される点を除いてフェイルオーバーと似ています。このトピックの詳細については、32章クライアントの再接続とセッションの再割り当て を参照してください。
フェイルオーバー中に、クライアントでコンシューマーが非永続的または一時的なキューにある場合、これらのキューはバックアップノードでのフェイルオーバー中に自動的に再作成されます。これは、バックアップノードが非永続キューを認識しないためです。

37.2.1. 自動クライアントフェイルオーバー

HornetQ クライアントは、ライブおよびバックアップサーバーの認識で設定できるため、クライアントで接続 (ライブサーバー接続) が失敗した場合に、クライアントがこれを検出し、バックアップサーバーに再接続します。次に、バックアップサーバーは、フェイルオーバーの実行前に各接続で存在したセッションとコンシューマーを自動的に再作成し、ユーザーは再接続ロジックを手動でコーディングする必要がなくなります。
15章使用済みの接続の検出 で説明されたように、HornetQ クライアントは、client-failure-check-period で指定された時間内にサーバーからパケットを受信しない場合に接続失敗を検出します。クライアントが適切な時間内にデータを受け取らない場合は、接続が失敗したと見なされ、フェイルオーバーが試行されます。
HornetQ クライアントは、ライブおよびバックアップサーバーのペアのリストを使用してさまざまな方法で設定できます。これらは、明示的に設定できます。これを行う最も一般的な方法は、クライアントがリストを自動的に検出するために server discovery を使用することです。サーバー検出の設定方法については、「サーバー検出」 を参照してください。また、「静的なクラスターサーバーリストの指定」 で説明されたように、クライアントはライブおよびバックアップサーバーのペアを明示的に指定できます。
自動クライアントフェイルオーバーを有効にするには、非ゼロ再接続試行を許可するようクライアントを設定する必要があります (32章クライアントの再接続とセッションの再割り当て を参照)。
場合によっては、ライブサーバーがクラッシュや接続の失敗ではなく正常にシャットダウンされた場合であっても、クライアントがバックアップサーバーにフェイルオーバーすることが適切であることがあります。これを設定するには、HornetQConnectionFactory (JMS を使用している場合)、 JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml ファイル (接続ファクトリーを定義する場合)、または ClientSessionFactoryImpl (プロパティーを直接設定してコアを使用する場合) でプロパティー FailoverOnServerShutdown を true に設定します。このプロパティーのデフォルト値は false です。つまり、デフォルトでは、ライブサーバーが正常にシャットダウンされた場合に、HornetQ クライアントはバックアップサーバーにフェイルオーバーされません。

注記

サーバーを正常にシャットダウンした場合はデフォルトでクライアントでのフェイルオーバーがトリガーされません。サーバーが正常にシャットダウンされたときにクライアントがフェイルオーバーするためには、FailoverOnServerShutdowntrue に設定します。
Ctrl+C (Linux ターミナルで) を使用すると、サーバーが正常にシャットダウンされ、このプロパティーが正常に設定されている限り、クライアントフェイルオーバーがトリガーされません。
デフォルトでは、フェイルオーバーは少なくとも 1 つの接続がライブサーバーに対して確立された後にのみ実行されます。このロジックを適用すると、クライアントがライブサーバーに対して最初の接続を確立するのに失敗した場合に、フェイルオーバーは実行されません。クライアントは、再接続試行プロパティーに基づいてライブサーバーへの接続を再試行し、この試行回数後に失敗します。
場合によっては、クライアントで、失敗したバックアップサーバーを自動的に試してライブサーバーに対する最初の接続を確立したいことがあります。この場合は、XML、ClientSessionFactoryImpl、または HornetQConnectionFactory でプロパティー FailoverOnInitialConnection、またはfailover-on-initial-connection を設定します。このパラメーターのデフォルト値は false です。

注記

HornetQ は、ライブサーバーとバックアップサーバー間で完全なサーバーステータスをレプリケートしません。新しいセッションがバックアップで自動的に作成された場合は、そのセッションですでに送信または承認されたメッセージが認識されません。また、フェイルオーバー時のすべての in-flight 送信または承認が失われることがあります。

37.2.1.1. フェイルオーバー中のブロッキングコールの処理

クライアントコードがサーバーに対するブロッキングコールにある場合は、応答が実行を続行するまで待機します。フェイルオーバーが実行された場合、新しいセッションは処理中のコールを認識しません。認識する場合、このコールは永久的にハングし、到着しない応答を待つことがあります。
これを回避するために、コールで javax.jms.JMSException (JMS を使用している場合) または HornetQException (エラーコード HornetQException.UNBLOCKED) をスローすることにより、HornetQ はフェイルオーバー時に処理中のすべてのブロッキングコールをブロック解除します。クライアントコードに応じて、この例外がキャッチされ、必要に応じて任意の操作を再試行されます。
ブロック解除されるメソッドが commit() または prepare() へのコールの場合、トランザクションは自動的にロールバックされ、HornetQ が javax.jms.TransactionRolledBackException (JMS を使用している場合) またはエラーコード HornetQException.TRANSACTION_ROLLED_BACK を持つ HornetQException (コア API を使用している場合) をスローします。

37.2.1.2. トランザクションのフェイルオーバーの処理

セッションがトランザクション対応であり、メッセージがすでに現在のトランザクションで送信または承認された場合、サーバーは、送信されたメッセージまたは承認がフェイルオーバー中に失われないことを保証できません。
結果的に、トランザクションはロールバック専用としてマークされ、以降のコミットで javax.jms.TransactionRolledBackException (JMS を使用している場合) またはエラーコードHornetQException.TRANSACTION_ROLLED_BACK を持つ HornetQException (コア API を使用している場合) がスローされます。
ユーザーは例外をキャッチし、必要に応じてクライアントサイドのローカルロールバックコードを実行できます。セッションを手動でロールバックする必要はありません (すでにロールバックされています)。ユーザーは同じセッションでトランザクション操作を再試行できます。
コミットコールが実行されるときにフェイルオーバーが行われる場合、応答が送り返されないため、以前に説明したように、ハングを回避するためにサーバーがコールをブロック解除します。この場合は、障害が発生する前にライブサーバーで実際にトランザクションコミットが処理されたかどうかをクライアントが判断することは簡単ではありません。
これに対処するために、クライアントはトランザクションで重複検出 (35章重複メッセージ検出) を有効にし、コールのブロック解除後にトランザクション操作を再試行できます。フェイルオーバー前にトランザクションが実際にライブサーバーで正常にコミットされた場合は、トランザクションが再試行されたときに、重複検出により、トランザクションで再送信されたすべての耐性メッセージが、複数回送信されることを防ぐためにサーバーで無視されます。

注記

ロールバック例外をキャッチし、ブロック解除されたコールを再試行およびキャッチし、重複検出を有効にすることにより、障害発生時にメッセージに対する 1 度だけの配信保証を提供し、メッセージの損失や重複がないことを 100% 保証できます。

37.2.1.3. 非トランザクションセッションでのフェイルオーバーの処理

セッションが非トランザクションである場合は、フェイルオーバーの実行時に、メッセージがまたは承認が失われることがあります。
非トランザクションセッションに対して1 度だけ配信保証を提供するには、「フェイルオーバー中のブロッキングコールの処理」 で説明されたように、重複検出を有効にし、ブロック解除例外をキャッチします。

37.2.2. 接続障害の検出

JMS は、接続障害 (java.jms.ExceptionListener) を非同期的に検出する標準的なメカニズムを提供します。ExceptionListener の詳細については、Oracle javax.jms Javadoc を参照してください。
HornetQ コア API は、類似の機能をクラス org.hornet.core.client.SessionFailureListener という形で提供します。
JMS ExceptionListener またはコア SessionFailureListener インスタンスは、接続が正常にフェイルオーバーされたか、最接続されたかに関係なく、接続障害の発生時に常に HornetQ によって呼び出されます。

37.2.3. アプリケーションレベルフェイルオーバー

場合によっては、自動クライアントフェイルオーバーが適切でなく、自分で接続障害を処理し、独自の障害ハンドラーで独自の再接続ロジックを手動でコーディングした方が良いことがあります。フェイルオーバーはユーザーアプリケーションレベルで処理されるため、これは、アプリケーションレベルと定義されます。
アプリケーションレベルフェイルオーバーを実装するには、JMS を使用している場合は、JMS 接続で ExceptionListener クラスを設定します。ExceptionListener は、接続障害が検出されたときに HornetQ により呼び出されます。ExceptionListener で、古い JMS 接続を閉じ、新しい接続ファクトリーインスタンスを JNDI からルックアップし、新しい接続を作成します。この場合は、新しい接続ファクトリーが異なるサーバーからルックアップされるよう HA-JNDI を使用できます。
コア API を使用する場合、手順は非常に似ています。コア ClientSession インスタンスで SessionFailureListener を設定します。

37.3. フェンシング

クラスター内のフェンシングノードは、クラスターの残りから不良ノードを隔離するために実装されます。これは、不良ノードがクラスターの残りで障害が発生していると見なし、クラスターを介して不良ノードにフェイルオーバーしようするシナリオを回避するために重要です。このシナリオでは、競合状態が発生し、データが大量に破損することがあります。
HornetQ は、フェンシング環境で稼働できる一方で、設定は、選択するフェンシングエージェントやフェンシングエージェントの設定方法によって異なります。
サーバークラスターが Red Hat Enterprise Linux で実行されている場合、Red Hat は高可用性アドオンを介してフェンシングサポートを提供します。この製品を使用するには、カスタマーサポートポータルでエンタイトルメントが必要です。
高可用性アドオンを使用したフェンシングの設定の詳細については、クラスターインフラストラクチャーにインストールされた Red Hat Enterprise Linux のバージョンに応じた Red Hat Enterprise Linux Cluster Administration Guide (クラスター管理ガイド) を参照してください。フェンシングを適切に設定するには、「Configuring Fence Devices (フェンスデバイスの設定)」と「Configuring Fencing for Cluster Members (クラスターメンバーに対するフェンシングの設定)」を参照してください。

第38章 共存および専用の対称クラスター設定

この章では、JBoss Enterprise Application Platform 内で HornetQ ライブバックアップグループを設定します。HornetQ はライブバックアップノードに対して共有ストアのみをサポートします。したがって、この章では、ライブバックアップグループをこのように設定します。
ライブバックアップグループ

HornetQ インスタンスの指定されたグループにフェイルオーバーするよう設定された、JBoss Enterprise Application Platform で実行されている HornetQ のインスタンス。

HornetQ ライブバックアップグループは、以下のいずれかのトポロジーを使用して設定されます。
共存
同時に実行されている 1 つのライブと少なくとも 1 つのバックアップサーバーが含まれているトポロジー。各バックアップノードは、別の JBoss Enterprise Application Platform インスタンスのライブノードに属します。
専用
1 つのライブと、少なくとも 1 つのバックアップサーバーが含まれるトポロジー。一度に 1 つのサーバーだけを実行できます。

38.1. 共存対称ライブおよびバックアップクラスター

注記

JBoss Enterprise Application Platform は、このトポロジーのサンプル設定とともに出荷されます (サンプル設定は $JBOSS_HOME/extras/hornetq/resources/examples/symmetric-cluster-with-backups-colocated にあります)。このディレクトリ内の readme は、サンプルを実行するのに必要な基本的な設定を提供します。
共存対称トポロジーには、稼働するライブノードと 1 つまたは複数のバックアップノードが含まれます。各バックアップノードは、別の JBoss Enterprise Application Platform インスタンスのライブノードに属します。
2 つの JBoss Enterprise Application Platform インスタンスの単純なクラスターでは、各 JBoss Enterprise Application Platform インスタンスは、1 つのライブサーバーと 1 つのバックアップサーバーを持ちます (例38.1「2 つのインスタンス設定」 を参照)。

例38.1 2 つのインスタンス設定

例38.1「2 つのインスタンス設定」 の連続する行は、フェイルオーバーが発生する前のクラスターの状態を示しています。点線は、フェイルオーバーが発生した後のクラスターの状態を示しています。
フェイルオーバーが発生する前に、2 つのライブサーバーは接続され 1 つのクラスターを形成します。各ライブサーバーは J2EE Connector Architecture (JCA) を介してローカルアプリケーションに接続されます。存在するリモートクライアントは各ライブサーバーに接続されます。
フェイルオーバーが発生すると、HornetQ Backup は、利用可能なライブサーバー (同じ仮想マシン内にあります) に接続し、クラスター内のライブサーバーとして引き継ぎます。すべてのリモートクライアントもフェイルオーバーします。
各ノードで利用可能なコンシューマーおよびプロデューサーと、 Message Driven Bean (MDB) に応じて、メッセージは Java Message Service (JMS) の要件を満たすようノード間で分散されます。たとえば、プロデューサーが、コンシューマがないバックアップサーバーのキューにメッセージを送信する場合、メッセージは必要なコンシューマーをアドバタイズするライブノードに配信されます。
例38.2「3 インスタンス設定」 は、若干より複雑です。これは、例38.1「2 つのインスタンス設定」 の同じ設定を拡張し、3 番目のライブおよびバックアップ HornetQ インスタンスを追加します。

注記

各サーバー間のライブクラスター接続は、図をわかりやすくするために削除されました。例ではすべてのライブサーバーが 1 つのクラスターを形成します。

例38.2 3 インスタンス設定

この例では、インスタンスに 3 つの個別の JBoss Enterprise Application Platform サーバーが含まれます (各サーバーにはライブおよびバックアップ HornetQ インスタンスが含まれます)。
3 ノードトポロジーでは、各サーバーに対して、フェイルオーバーの発生時にライブバックアップグループの 3 つのいずれかのサーバーで共有される 2 つのバックアップインスタンスを設定できます。
1 つのサーバーに対して複数のライブバックアップグループを設定できますが、ほとんどのデプロイメントでは、1 つのライブインスタンスに対して 1 つのバックアップで十分であると見なされます。

38.1.1. 共存ライブサーバー

重要

ノードがお互いを検出できない場合は、ファイアウォールと UDP ポートが正常に設定されていることを確認してください。ネットワーク設定では、クラスターのノードがお互いに通信できる必要があります。
共存ライブサーバーインスタンスを設定するには、以下の手順に従いします。

手順38.1 ライブサーバープロファイルの作成

production プロファイルのコピー作成して、ライブサーバー設定をカスタマイズする必要があります。

重要

カスタムプロファイルのために直接編集するのではなく、含まれたプロファイルを常にコピーします。設定時に重大な間違いを犯した場合は、いつでも基本設定に戻ることができます。
  1. $JBOSS_HOME/server/ に移動します。
  2. production プロファイルをコピーして、HornetQ_Colocated に名前を変更します。

手順38.2 共有ストアとジャーナリングの設定

以下の手順に従って、フェイルオーバーのために共有ストアを使用する HornetQ を指定し、ライブバックアップグループ内の各 HornetQ インスタンスが使用するジャーナルファイルの場所を定義します。
  1. $JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq/ に移動します。
  2. オープンします。
  3. <shared-store> element 要素を <configuration> 要素の子として追加します。
    <shared-store>true</shared-store>
  4. バインディング、ジャーナル、および大きなメッセージパスの場所がライブバックアップグループがアクセスできる場所に設定されていることを確認します。
    例で示されたように絶対パスを設定したり、設定ファイルに存在する JBoss パラメーターを使用したりできます。
    パラメーターオプションを選択し、これらのパラメーターが解決されるデフォルトのパスを使用しない場合は、サーバーを起動する度にバインディング、ジャーナル、および大きなメッセージが存在するパスを指定する必要があります。
    <large-messages-directory>/media/shared/data/serverA/large-messages</large-messages-directory>
    
    <bindings-directory>/media/shared/data/serverA/bindings</bindings-directory>
    
    <journal-directory>/media/shared/data/serverA/journal</journal-directory>
    
    <paging-directory>/media/shared/data/ServerA/paging</paging-directory>

    注記

    ネットワークのライブバックアップグループにアクセス可能なパスを指定してください。

    注記

    ServerA をサーバーインスタンスに適切な名前に変更します。
デフォルトでは、ライブサーバーが正常にシャットダウンされた場合、JMS クライアントはフェイルオーバーしません。接続ファクトリーの設定に応じて、クライアントは失敗するか、ライブサーバーに再接続しようとします。
通常のサーバーシャットダウン時にクライアントがフェイルオーバーする必要がある場合は、手順38.3「JMS クライアントの正常シャットダウンの設定」 での記述に従ってファイルを変更する必要があります。

手順38.3 JMS クライアントの正常シャットダウンの設定

以下の手順に従って、サーバーが正常にシャットダウンした場合に JMS クライアントがどのように接続を再確立するかを設定します。
  1. $JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq/ に移動します。
  2. hornetq-configuration.xml を開きます。
  3. 手順38.2「共有ストアとジャーナリングの設定」 で記述されたようにジャーナルディレクトリ設定付近の領域に <fail-over-on-shutdown> 要素を指定します。
    <failover-on-shutdown>true</failover-on-shutdown>

    注記

    hornetq-configuration.xml ファイルに要素を置く場所の制限はありません。ただし、ファイルの上部に詳細レベルが低い設定があると、見つけやすくなります。
  4. ファイルを保存し、閉じます。

注記

<fail-over-on-shutdown> を false (デフォルト設定) に設定し、フェイルオーバーを実行したい場合は、サーバープロセスを直接終了するか、JMX コンソールまたはコアサーバーオブジェクトの管理コンソールから forceFailover を呼び出します。
クライアントにより使用された接続ファクトリーは高可用性に設定する必要があります。これは、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml で接続ファクトリー属性を設定することにより行われます。

手順38.4 HA 接続ファクトリーの設定

  1. $JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq/ に移動します。
  2. hornetq-jms.xml を開きます。
  3. 以下で示されたように以下の属性と値を追加します。
    <ha>true</ha>
    クライアントが高可用性をサポートし、フェイルオーバーを実行するために常に true になるように指定します。
    <retry-interval>1000</retry-interval>
    クライアントがサーバーに再接続するまでクライアントが待機する時間 (ミリ秒単位) を指定します。
    <retry-interval-multiplier>1.0</retry-interval-multiplier>
    以降の各再接続の一時停止に対して使用される乗数 <retry-interval> を指定します。この値を 1.0 に設定すると、再試行間隔が各クライアント再接続要求で同じになります。
    <reconnect-attempts>-1</reconnect-attempts>
    クライアントが失敗する前に行う再接続試行の回数を指定します。-1 と設定すると、再接続が無制限で試行されます。
    <?xml version='1.0' encoding='UTF-8'?>
    <configuration xmlns="urn:hornetq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">
    
       <connection-factory name="NettyConnectionFactory">
          <xa>true</xa>
          <connectors>
             <connector-ref connector-name="netty"/>
          </connectors>
          <entries>
             <entry name="/ConnectionFactory"/>
             <entry name="/XAConnectionFactory"/>
          </entries>
          <ha>true</ha>
    
          <!-- Pause 1 second between connect attempts -->
    
          <retry-interval>1000</retry-interval>
    
          <!-- Multiply subsequent reconnect pauses by this multiplier. This can be used 
           to implement an exponential back-off. For our purposes we just set to 1.0 so 
           each reconnect pause is the same length -->
    
          <retry-interval-multiplier>1.0</retry-interval-multiplier>
    
          <!-- Try reconnecting an unlimited number of times (-1 means unlimited) -->
    
          <reconnect-attempts>-1</reconnect-attempts>
       </connection-factory>
    
    </configuration>
    
  4. 指定されたファイルに以下のいずれかの設定ブロックを追加することにより、マスターノードとバックアップノードの両方で新しいキューを定義します。
    production/deploy/hornetq/hornetq-jms.xml の場合
    <queue name="testQueue">
       <entry name="/queue/testQueue"/>
       <durable>true</durable>
    </queue>
    production/deploy/customName-hornetq-jms.xml の場合

    注記

    XML ネームスペースが存在し、指定されたようにファイルで正しいことを確認して、XML 検証の観点からファイルの形式が適切であることを確認します。
    <configuration xmlns="urn:hornetq"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">
    
       <queue name="testQueue">
          <entry name="/queue/testQueue"/>
          <durable>true</durable>
       </queue>
    
    </configuration>

38.1.2. 共存バックアップサーバー

この項を読み、記載された手順に従って、共存バックアップ HornetQ サーバーを設定します。
バックアップサーバーは、「共存ライブサーバー」 で設定されたライブサーバーと同じ JBoss Enterprise Application Platform インスタンスで実行されます。理解すべき重要なことは、バックアップサーバーが、異なる JBoss Enterprise Application Platform インスタンスで実行されているライブサーバーに対してフェイルオーバーのポイントであることです。
同様に、バックアップサーバーインスタンスは、共存する JBoss Enterprise Application Platform インスタンスで Java EE コンポーネントを提供しません。ライブサーバーがフェイルオーバーする場合、既存のすべてのメッセージがライブバックアップグループ内で再分散され、ライブサーバが利用できなくなったときに、ライブサーバーに接続されたリモートクライアントにサービスを提供します。
バックアップ HornetQ インスタンスは hornetq-jboss-beans.xmlhornetq-configuration.xml 設定ファイルのみ必要です。JMS コンポーネントは、バックアップサーバーがライブになったときに共有ジャーナルから作成されます (手順38.2「共有ストアとジャーナリングの設定」 で設定されます)。

手順38.5 バックアップサーバーの作成

重要

ノードがお互いを検出できない場合は、ファイアウォールと UDP ポートが正常に設定されていることを確認してください。ネットワーク設定では、クラスターのノードがお互いに通信できる必要があります。
「共存ライブサーバー」 で示されたように、ライブサーバを最初に設定する必要があります。ライブサーバーを設定したら、この手順を続行します。
  1. $JBOSS_HOME/server/HornetQ_Colocated/deploy/ に移動します。
  2. hornetq-backup1 という名前の新しいディレクトリを作成します。このディレクトリに移動します。
  3. テキストエディターを開き、hornetq-jboss-beans.xml という名前の新しいファイルを hornetq-backup1 ディレクトリに作成します。
  4. 以下の設定を hornetq-jboss-beans.xml にコピーします。
    <?xml version="1.0" encoding="UTF-8"?>
       <deployment xmlns="urn:jboss:bean-deployer:2.0">
          <!-- The core configuration -->
          <bean name="BackupConfiguration" class="org.hornetq.core.config.impl.FileConfiguration">
             <property name="configurationUrl">${jboss.server.home.url}/deploy/hornetq-backup1/hornetq-configuration.xml</property>
          </bean>
          <!-- The core server -->
          <bean name="BackupHornetQServer" class="org.hornetq.core.server.impl.HornetQServerImpl">
             <constructor>
                <parameter>
                   <inject bean="BackupConfiguration"/>
                </parameter>
                <parameter>
                   <inject bean="MBeanServer"/>
                </parameter>
                <parameter>
                   <inject bean="HornetQSecurityManager"/>
                </parameter>
             </constructor>
             <start ignored="true"/>
             <stop ignored="true"/>
          </bean>
    
          <!-- The JMS server -->
          <bean name="BackupJMSServerManager" class="org.hornetq.jms.server.impl.JMSServerManagerImpl">
             <constructor>
                <parameter>
                   <inject bean="BackupHornetQServer"/>
                </parameter>
             </constructor>
          </bean>
    
    </deployment>
    
  5. ファイルを保存し、閉じます。
手順38.5「バックアップサーバーの作成」 内の hornetq-jboss-beans.xml ファイルには、詳細に調べる価値のある設定が含まれます。BackupConfiguration Bean は、hornetq-configuration.xml の設定を取得するよう設定されます。このファイルは、手順38.6「バックアップサーバー設定ファイルの作成」 の手順で作成されます。
HornetQ Server および JMS サーバー Bean は、BackupConfiguration 後に追加されます。

注記

バックアップインスタンス Bean の名前は、ライブサーバー設定のものから変更されました。これは、Bean が同じ名前を共有する問題を回避するためです。バックアップサーバーを追加する場合は、これらのインスタンスの名前を一意になるよう変更する必要があります (例: backup1、backup2)。
次のタスクでは、手順38.6「バックアップサーバー設定ファイルの作成」 に従ってバックアップサーバー設定を作成します。

手順38.6 バックアップサーバー設定ファイルの作成

  1. $JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq-backup1 に移動します。
  2. テキストエディターを開き、hornetq-configuration.xml という名前の新しいファイルを hornetq-backup1 ディレクトリに作成します。
  3. 以下の設定を hornetq-configuration.xml にコピーします。
    <?xml version="1.0" encoding="UTF-8"?>
    <configuration xmlns="urn:hornetq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hornetq /schema/hornetq-configuration.xsd">
    
       <jmx-domain>org.hornetq.backup1</jmx-domain>
    
       <clustered>true</clustered>
    
       <backup>true</backup>
    
       <shared-store>true</shared-store>
    
       <allow-failback>true</allow-failback>
    
       <file-deployment-enabled>true</file-deployment-enabled>
    
       <log-delegate-factory-class-name>
        org.hornetq.integration.logging.Log4jLogDelegateFactory
       </log-delegate-factory-class-name>
    
       <bindings-directory>
        /media/shared/data/hornetq-backup/bindings
       </bindings-directory>
    
       <journal-directory>/media/shared/data/hornetq-backup/journal</journal-directory>
    
       <journal-min-files>10</journal-min-files>
    
       <large-messages-directory>
        /media/shared/data/hornetq-backup/largemessages
       </large-messages-directory>
    
       <paging-directory>/media/shared/data/hornetq-backup/paging</paging-directory>
    
       <connectors>
          <connector name="netty-connector">
             <factory-class>
              org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
             </factory-class>
             <param key="host" value="${jboss.bind.address:localhost}"/>
             <param key="port" value="${hornetq.remoting.netty.backup.port:5446}"/>
          </connector>
    
          <connector name="in-vm">
             <factory-class>
              org.hornetq.core.remoting.impl.invm.InVMConnectorFactory
             </factory-class>
             <param key="server-id" value="${hornetq.server-id:0}"/>
          </connector>
       </connectors>
    
       <acceptors>
          <acceptor name="netty">
             <factory-class>
              org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory
             </factory-class>
             <param key="host" value="${jboss.bind.address:localhost}"/>
             <param key="port" value="${hornetq.remoting.netty.backup.port:5446}"/>
          </acceptor>
       </acceptors>
    
       <broadcast-groups>
          <broadcast-group name="bg-group1">
             <group-address>231.7.7.7</group-address>
             <group-port>9876</group-port>
             <broadcast-period>1000</broadcast-period>
             <connector-ref>netty-connector</connector-ref>
          </broadcast-group>
       </broadcast-groups>
    
       <discovery-groups>
          <discovery-group name="dg-group1">
             <group-address>231.7.7.7</group-address>
             <group-port>9876</group-port>
             <refresh-timeout>60000</refresh-timeout>
          </discovery-group>
       </discovery-groups>
    
       <cluster-connections>
          <cluster-connection name="my-cluster">
             <address>jms</address>
             <connector-ref>netty-connector</connector-ref>
             <discovery-group-ref discovery-group-name="dg-group1"/>
          </cluster-connection>
       </cluster-connections>
    
       <security-settings>
          <security-setting match="#">
             <permission type="createNonDurableQueue" roles="guest"/>
             <permission type="deleteNonDurableQueue" roles="guest"/>
             <permission type="consume" roles="guest"/>
             <permission type="send" roles="guest"/>
          </security-setting>
       </security-settings>
    
       <address-settings>
       <!--default for catch all-->
          <address-setting match="#">
             <dead-letter-address>jms.queue.DLQ</dead-letter-address>
             <expiry-address>jms.queue.ExpiryQueue</expiry-address>
             <redelivery-delay>0</redelivery-delay>
             <max-size-bytes>10485760</max-size-bytes>
             <message-counter-history-day-limit>10</message-counter-history-day-limit>
             <address-full-policy>BLOCK</address-full-policy>
          </address-setting>
       </address-settings>
    
    </configuration>
    
  4. ファイルを保存し、閉じます。
手順38.6「バックアップサーバー設定ファイルの作成」 内の hornetq-configuration.xml ファイルには、hornetq-configuration.xml 設定ポイント で説明された特定の設定が含まれます。

hornetq-configuration.xml 設定ポイント

<jmx-domain>org.hornetq.backup1</jmx-domain>
Java Management Extensions (JMX) サービスのオブジェクト名 (この場合はバックアップサーバー) を指定します。デフォルト値は org.hornetq ですが、この名前は HornetQ の他の部分ですでに使用されています。ライブサーバーとの名前の重複を回避するために、この名前を一意のシステム全体の名前に変更する必要があります。
<clustered>true</clustered>
サーバーがクラスターに参加するかどうかを指定します。この設定はライブサーバーと同じです。
<backup>true</backup>
サーバーをライブサーバーではなくバックアップサーバーとして起動するかどうかを指定します。true を指定すると、サーバーがバックアップサーバーとして起動するよう設定されます。
<shared-store>true</shared-store>
サーバーがジャーナリングのために共有ストアを参照するかどうかを指定します。この設定はライブサーバーと同じです。
<allow-failback>true</allow-failback>
バックアップサーバーが自動的に停止し、ライブサーバーが再び利用可能になったときにスタンバイモードに戻るかどうかを指定します。false に設定された場合は、サーバーを手動で停止してスタンバイモードに戻る必要があります。
<bindings-directory>, <journal-directory>, <large-messages-directory>, <paging-directory>
これらの要素のパスはすべて、ライブサーバーが参照するのと同じパスに解決する必要があります。これにより、バックアップサーバーがライブサーバーと同じジャーナリングファイルを使用するようになります。
<connectors>
ライブになった場合にバックアップサーバーにクラスターが接続できるよう 2 つのコネクターが定義されます (netty コネクターファクトリーに対するコネクター (さまざまな仮想マシン間でクライアントおよびサーバー接続を許可します) とサーバーが VM 内で接続を受け入れることを許可するコネクター)。
<acceptors>
VM のコンパクト化のためにここでは NettyAcceptorFactory が選択されます。
<broadcast-groups>, <discovery-groups>, <cluster-connections>, <security-settings>, <address-settings>
これらの設定ブロックの設定は標準的な設定です。

タスク: 2 番目のサーバーインスタンスに対して設定を作成

このタスクを完了して、最初のサーバーとクラスターを形成する 2 番目のサーバーインスタンスを設定します。
  1. JBOSS_HOME /server/ に移動します。
  2. HornetQ_Colocated ディレクトリをコピーし、HornetQ_Colocated_Second に名前を変更します。
  3. JBOSS_HOME/server/HornetQ_Colocated_Second/hornetq-backup1/ の名前を JBOSS_HOME/server/HornetQ_Colocated_Second/hornetq-backup-serverA/ に変更します。
  4. JBOSS_HOME/server/HornetQ_Colocated_Second/hornetq/hornetq-configuration.xml を開きます。
  5. hornetq-configuration.xml で指定されたデータディレクトリがあるすべてのパラメーターで、データパスを /media/shared/data/hornetq-backup に変更します。
    たとえば、
    <bindings-directory> /media/shared/data/serverA/bindings </bindings-directory>
    を <bindings-directory> /media/shared/data/hornetq-backup/bindings </bindings-directory> に変更します。
  6. JBOSS_HOME/server/HornetQ_Colocated_Second/hornetq-backup-serverA/hornetq-configuration.xml を開きます。
  7. hornetq-configuration.xml で指定されたデータディレクトリがあるすべてのパラメーターで、データパスを /media/shared/data/serverA に変更します。
    たとえば、
    <bindings-directory> /media/shared/data/hornetq-backup/bindings </bindings-directory>
    を <bindings-directory> /media/shared/data/serverA/bindings </bindings-directory> に変更します。

38.2. 専用対称ライブおよびバックアップクラスター

注記

JBoss Enterprise Application Platform には、このトポロジーのサンプル設定が含まれ、$JBOSS_HOME/extras/hornetq/resources/examples/cluster-with-dedicated-backup に存在します。
専用対称トポロジーでは、バックアップサーバーが別のライブサーバーと共存するのではなく別の JBoss Enterprise Application Platform に存在します。
つまり、JBoss Enterprise Application Platform インスタンスはパッシブであり、バックアップがライブになるまで使用されません。したがって、パッシブインスタンスは純粋な JMS アプリケーションの場合にのみ役に立ちます。
以下の図は、これに関する設定を示しています。

例38.3 単一インスタンス、純粋な JMS、専用対称設定

EAP1 ノード上の HornetQ ライブサーバーが応答を停止した場合、 EAP1(B) ノード上の HornetQ バックアップインスタンスはアクティベートされ、ライブサーバーになります。リモート JMS クラスターは、HornetQ ライブノード向けのすべてのメッセージを HornetQ バックアップノードにルーティングします。
例38.3「単一インスタンス、純粋な JMS、専用対称設定」 は、専用対称トポロジーが、純粋の JMS であり、JMS コンポーネント (たとえば、Message Driven Bean) を持たないアプリケーションとどう動作するかを示しています。
JMS コンポーネントを含むトポロジーの場合は、JMS コンポーネントを含む専用対称クラスターに対して使用できる 2 つの方法が存在します。
  1. 専用 JCA サーバー (例38.4「専用 JCA サーバー」 を参照)
  2. リモート JCA サーバー (例38.5「リモート JCA サーバー」 を参照)。

38.2.1. 専用 JCA ライブサーバー

例38.4 専用 JCA サーバー

EAP1(B) および EAP2(B) インスタンスは、バックアップ HornetQ インスタンスのみ実行しているため、これらのインスタンスで任意のアプリケーションをホストすることは適切ではありません。アプリケーションは、代わりに EAP1 と EAP2 でホストされ、ライブ HornetQ インスタンスと近接します。
ライブ HornetQ サーバーが EAP1 で失敗すると、トラフィックはバックアップ HornetQ サーバー EAP1(B) にフェイルオーバーします。リモート JMS クライアントは、HornetQ クラスター接続を使用して、ライブサーバーの Java EE コンポーネントが送信元または送信先のメッセージをバックアップサーバーに再ルーティングします。
ライブサーバー設定は、実際には 「共存ライブサーバー」 と同じです。唯一の違いは、ライブ HornetQ インスタンスを実行している同じ JBoss Enterprise Application Platform ノードにバックアップがないことです。このトポロジーには、複数の JBoss Enterprise Application Platform インスタンスが必要です。

手順38.7 専用ライブサーバープロファイルの作成

重要

ノードがお互いを検出できない場合は、ファイアウォールと UDP ポートが正常に設定されていることを確認してください。ネットワーク設定では、クラスターのノードがお互いに通信できる必要があります。
production プロファイルのコピー作成して、ライブサーバー設定をカスタマイズする必要があります。

重要

カスタムプロファイルのために直接編集するのではなく、含まれたプロファイルを常にコピーします。設定時に重大な間違いを犯した場合は、いつでも基本設定に戻ることができます。
  1. $JBOSS_HOME/server/ に移動します。
  2. production プロファイルをコピーして、HornetQ_Dedicated に名前を変更します。

手順38.8 共有ストアとジャーナリングの設定

以下の手順に従って、フェイルオーバーのために共有ストアを使用する HornetQ を指定し、ライブバックアップグループ内の各 HornetQ インスタンスが使用するジャーナルファイルの場所を定義します。
  1. $JBOSS_HOME/server/HornetQ_Dedicated/deploy/hornetq/ に移動します。
  2. hornetq-configuration.xml を開きます。
  3. <shared-store> element 要素を <configuration> 要素の子として追加します。
    <shared-store>true</shared-store>
  4. バインディング、ジャーナル、および大きなメッセージパスの場所がライブバックアップグループがアクセスできる場所に設定されていることを確認します。
    例で示されたように絶対パスを設定したり、設定ファイルに存在する JBoss パラメーターを使用したりできます。
    パラメーターオプションを選択し、これらのパラメーターが解決されるデフォルトのパスを使用しない場合は、サーバーを起動する度にバインディング、ジャーナル、および大きなメッセージが存在するパスを指定する必要があります。
    <large-messages-directory>/media/shared/data/large-messages</large-messages-directory>
    
    <bindings-directory>/media/shared/data/bindings</bindings-directory>
    
    <journal-directory>/media/shared/data/journal</journal-directory>
    
    <paging-directory>/media/shared/data/paging</paging-directory>

    注記

    ネットワークのライブバックアップグループにアクセス可能なパスを指定してください。

手順38.9 JMS クライアントの正常シャットダウンの設定

以下の手順に従って、サーバーが正常にシャットダウンした場合に JMS クライアントがどのように接続を再確立するかを設定します。
  1. $JBOSS_HOME/server/HornetQ_Dedicated/deploy/hornetq/ に移動します。
  2. hornetq-configuration.xml を開きます。
  3. 手順38.2「共有ストアとジャーナリングの設定」 で記述されたようにジャーナルディレクトリ設定付近の領域に <fail over-on-shutdown> 要素を指定します。
    <failover-on-shutdown>true</failover-on-shutdown>

    注記

    hornetq-configuration.xml ファイルに要素を置く場所の制限はありません。ただし、ファイルの上部に詳細レベルが低い設定があると、見つけやすくなります。
  4. ファイルを保存し、閉じます。

手順38.10 HA 接続ファクトリーの設定

  1. $JBOSS_HOME/server/HornetQ_Dedicated/deploy/hornetq/ に移動します。
  2. hornetq-jms.xml を開きます。
  3. 以下で示されたように以下の属性と値を追加します。
    <ha>true</ha>
    クライアントが高可用性をサポートし、フェイルオーバーを実行するために常に true になるように指定します。
    <retry-interval>1000</retry-interval>
    クライアントがサーバーに再接続するまでクライアントが待機する時間 (ミリ秒単位) を指定します。
    <retry-interval-multiplier>1.0</retry-interval-multiplier>
    以降の各再接続の一時停止に対して使用される乗数 <retry-interval> を指定します。この値を 1.0 に設定すると、再試行間隔が各クライアント再接続要求で同じになります。
    <reconnect-attempts>-1</reconnect-attempts>
    クライアントが失敗する前に行う再接続試行の回数を指定します。-1 と設定すると、再接続が無制限で試行されます。
    <?xml version='1.0' encoding='UTF-8'?>
    <configuration xmlns="urn:hornetq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">
    
       <connection-factory name="NettyConnectionFactory">
          <xa>true</xa>
          <connectors>
             <connector-ref connector-name="netty"/>
          </connectors>
          <entries>
             <entry name="/ConnectionFactory"/>
             <entry name="/XAConnectionFactory"/>
          </entries>
          <ha>true</ha>
    
          <!-- Pause 1 second between connect attempts -->
    
          <retry-interval>1000</retry-interval>
    
          <!-- Multiply subsequent reconnect pauses by this multiplier. This can be used 
           to implement an exponential back-off. For our purposes we just set to 1.0 so 
           each reconnect pause is the same length -->
    
          <retry-interval-multiplier>1.0</retry-interval-multiplier>
    
          <!-- Try reconnecting an unlimited number of times (-1 means unlimited) -->
    
          <reconnect-attempts>-1</reconnect-attempts>
       </connection-factory>
    
    </configuration>
    
  4. 指定されたファイルに以下のいずれかの設定ブロックを追加することにより、マスターノードとバックアップノードの両方で新しいキューを定義します。
    production/deploy/hornetq/hornetq-jms.xml の場合
    <queue name="testQueue">
       <entry name="/queue/testQueue"/>
       <durable>true</durable>
    </queue>
    production/deploy/customName-hornetq-jms.xml の場合

    注記

    XML ネームスペースが存在し、指定されたようにファイルで正しいことを確認して、XML 検証の観点からファイルの形式が適切であることを確認します。
    <configuration xmlns="urn:hornetq"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:schemaLocation="urn:hornetq /schema/hornetq-jms.xsd">
    
       <queue name="testQueue">
          <entry name="/queue/testQueue"/>
          <durable>true</durable>
       </queue>
    
    </configuration>

38.2.2. 専用 JCA バックアップサーバー

バックアップサーバーの場合は、hornetq-configuration.xml が変更されません。ライブサーバーがないため、hornetq-jboss-beans.xml が必要なすべての Bean をインスタンス化するようにします。ライブサーバーの場合と同じ設定 (Configuration Bean に対する hornetq-configuration.xml パラメーターの場所の変更を除く) を使用してこれを設定します。

手順38.11 専用バックアップサーバーの設定

次の手順に従い、個別の JBoss Enterprise Application Platform サーバーにある専用 HornetQ バックアップインスタンスを設定します。
前提条件

  • HornetQ ライブサーバー (「専用 JCA ライブサーバー」 で記載された手順に従って設定)
  • ライブサーバーに対する個別のサーバーインスタンスにインストールされた、適切に設定された JBoss Enterprise Application Platform インスタンス。
  • プラットフォームインスタンスにインストールされた HornetQ。

  1. バックアップサーバーで、コマンドラインを使用して /extras/hornetq/ に移動します。
  2. sh ./switch.sh -Dbackup=true を実行します。
    スクリプトが実行され、production-backup サーバープロファイルが $JBOSS_HOME/server/ に作成されます。
  3. production-backup サーバープロファイルをコピーして、HornetQ_Dedicated_Backup に名前を変更します。
  4. $JBOSS_HOME/server/HornetQ_Dedicated_Backup/hornetq/hornetq-configuration.xml を開きます。
  5. <shared-store>true</shared-store> 要素を子要素として <configuration> 要素に追加します。
  6. 以下の値に一致するようデータディレクトリの場所を変更します。
    • <large-messages-directory>/media/shared/data/large-messages</large-messages-directory>
    • <bindings-directory>/media/shared/data/bindings</bindings-directory>
    • <journal-directory>/media/shared/data/journal</journal-directory>
    • <paging-directory>/media/shared/data/paging</paging-directory>
  7. 更新されたすべてのファイルを保存し、閉じます。

38.2.3. 専用リモートサーバー

例38.5 リモート JCA サーバー

この例では、HornetQ ライブインスタンスがリモートサーバー EAP1 に保存されます。バックアップ HornetQ インスタンスは EAP1(B) に保存されます。JCA とアプリケーションは個別の EAP2 インスタンスに保存されます。
フェイルオーバーが発生した場合は、アプリケーション (JCA 経由) が独自の JBoss Enterprise Application Platform インスタンスの HornetQ サーバーにより処理されます。
両方の HornetQ インスタンスがリモートサーバーに存在するため、JCA 接続ファクトリーを EAP2 サーバーで設定して、アプリケーションをライブ HornetQ サーバーとバックアップ HornetQ サーバーに適切に提供する必要があります。

手順38.12 JCA 接続ファクトリーの設定

以下の手順に従い、さまざまな設定ファイルで Outbound および Inbound JCA コネクター要素を設定します。ステップタイトルで識別された主要なステップをコピーします。
  1. production サーバープロファイルをコピーして、EAP2 に名前を変更します。
  2. EAP2 インスタンスで、$JBOSS_HOME/server/EAP2/deploy/hornetq/jms-ds.xml に移動します。
  3. デフォルトの jms-ds.xml では、次の <config-property> 設定が <tx-connection-factory> に存在します。
    <?xml version="1.0" encoding="UTF-8"?>
    <connection-factories>
       <!-- JMS Stuff -->
    
       <mbean code="org.jboss.jms.jndi.JMSProviderLoader" 
        name="hornetq:service=JMSProviderLoader,name=JMSProvider">
          <attribute name="ProviderName">DefaultJMSProvider</attribute>
          <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
          <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
          <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
          <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
       </mbean>
       
       <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
    
       <tx-connection-factory>
          <jndi-name>JmsXA</jndi-name>
          <xa-transaction/>
          <rar-name>jms-ra.rar</rar-name>
          <connection-definition>org.hornetq.ra.HornetQRAConnectionFactory</connection-definition>
          <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
          <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
          <max-pool-size>20</max-pool-size>
          <security-domain-and-application>JmsXARealm</security-domain-and-application>
       </tx-connection-factory>
    </connection-factories>
    
  4. Outbound JCA コネクターの設定

    以下のコード例で示されたように <config-property> 要素を追加します。

    重要

    [live_server_IP_address] と [live_server_port_number] をライブサーバーのネットワークアドレスの場所と置き換えます。
    IP アドレス/ポートの組み合わせを設定するために検出を使用している場合は、設定されたブロードキャストグループに一致するように、<DiscoveryAddress><DiscoveryPort> に適切なパラメーターを設定します。
    <?xml version="1.0" encoding="UTF-8"?>
    <connection-factories>
       <!-- JMS Stuff -->
    
       <mbean code="org.jboss.jms.jndi.JMSProviderLoader" 
        name="hornetq:service=JMSProviderLoader,name=JMSProvider">
          <attribute name="ProviderName">DefaultJMSProvider</attribute>
          <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
          <attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
          <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
          <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
       </mbean>
       
       <!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
    
       <tx-connection-factory>
          <jndi-name>JmsXA</jndi-name>
          <xa-transaction/>
          <rar-name>jms-ra.rar</rar-name>
          <connection-definition>org.hornetq.ra.HornetQRAConnectionFactory</connection-definition>
          <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
          <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
          <config-property name="ConnectorClassName" type="java.lang.String">org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</config-property>
          <config-property name="ConnectionParameters" type="java.lang.String">host=[live_server_IP_address];port=[live_server_port_number]</config-property>
          <max-pool-size>20</max-pool-size>
          <security-domain-and-application>JmsXARealm</security-domain-and-application>
       </tx-connection-factory>
    </connection-factories>
    
  5. テキストエディターで $JBOSS_HOME/server/EAP2/deploy/jms-ra.rar/META-INF/ra.xml を開きます。
  6. ra.xml で、<resourceadapter> を検索します。
  7. Inbound コネクターの設定

    "The transport type" および "The transport configuration..." <config-property> 要素と、その子要素を以下の設定と置き換えます。

    重要

    [live_server_IP_address] と [live_server_port_number] をライブサーバーのネットワークアドレスの場所と置き換えます。
    IP アドレス/ポートの組み合わせを設定するために検出を使用している場合は、設定されたブロードキャストグループに一致するように、<DiscoveryAddress><DiscoveryPort> に適切なパラメーターを設定します。
    自動検出を使用している場合は、ConnectorClassName ディレクティブと ConnectionParameters ディレクティブをコメントアウトします。
    <?xml version="1.0" encoding="UTF-8"?>
    
    <!-- Preceeding parts of config file removed for readability -->
    
    <resourceadapter>
       <resourceadapter-class>org.hornetq.ra.HornetQResourceAdapter</resourceadapter-class>
       <config-property>
          <description>The transport type</description>
          <config-property-name>ConnectorClassName</config-property-name>
          <config-property-type>java.lang.String</config-property-type>
          <config-property-value>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</config-property-value>
       </config-property>
       <config-property>
          <description>The transport configuration. These values must be in the form of key=val;key=val;</description>
          <config-property-name>ConnectionParameters</config-property-name>
          <config-property-type>java.lang.String</config-property-type>
          <config-property-value>host=[live_server_IP_address];port=[live_server_port_number]</config-property-value>
       </config-property>
       <config-property>
          <description>Do we support HA</description>
          <config-property-name>HA</config-property-name>
          <config-property-type>java.lang.Boolean</config-property-type>
          <config-property-value>true</config-property-value>
       </config-property>
    
    <!-- Rest of config file removed for readability -->
    
    <resourceadapter>
    

第39章 Libaio ネイティブライブラリー

HornetQ は、HornetQ と Linux libaio 間のブリッジとして使用されるネイティブライブラリーを配布します。
libaio は、Linux カーネルプロジェクトの一部として開発されたライブラリーです。libaio では、書き込みが、非同期で処理されるオペレーティングシステムに送信されます。書き込みが処理されたときに、オペレーティングシステムはコードをコールバックします。
これは、高パフォーマンスジャーナルで使用されます (このように設定されている場合)。13章永続化 を参照してください。
以下は、HornetQ により配布されるネイティブライブラリーです。
  • libHornetQAIO32.so - x86 32 ビット
  • libHornetQAIO64.so - x86 64 ビット
libaio を使用する場合、HornetQ は常にこれらのファイルをロードしようとします (これらのファイルがライブラリーパスにある場合)。「ライブラリーパス」 を参照してください。

第40章 スレッド管理

本章では、HornetQ がスレッドを使用およびプールする方法と、これらの管理方法について説明します。
最初に、サーバサイドでスレッドがどのように管理および使用されるかについて説明し、次に、クライアントサイドを見てみます。

40.1. サーバーサイドスレッド管理

各 HornetQ サーバーは、一般的な使用のために単一スレッドプールを維持し、スケジュール使用のためにスケジュールスレッドプールを維持します。Java のスケジュールスレッドプールは、標準的なスレッドプールを使用するよう設定できません。設定できる場合は、スケジュールおよび非スケジュールアクティビティの両方に対して単一スレッドプールを使用できます。
古い (ブロッキング) IO を使用する場合は、接続を処理するために別のスレッドプールが使用されます。古い IO では、1 つの接続に対して 1 つのスレッドが必要なため、標準的なプールから接続を取得することは適切ではありません。これは、非常に多くの接続が確立された場合にプールが簡単に枯渇し、処理を行うスレッドが残っていないため、サーバーが「ハングする」ことがあるためです。サーバーで多くの同時接続を処理する場合は、古い IO ではなく NIO を使用してください。
新しい IO (NIO) を使用する場合、HornetQ はデフォルトでコア, by default, use a number of threads equal to three times the number of cores (or hyper-threads) as reported by 受信パケットを処理するために Runtime.getRuntime().availableProcessors() により報告されたコア (またはハイパースレッド) の数を 3 倍した数に等しいスレッド数を使用します。この値を上書きするには、トランスポート設定でパラメーター nio-remoting-threads を指定してスレッド数を設定します。この詳細については、14章トランスポートの設定 を参照してください。
また、スレッドが直接使用される他の場所も少数存在します。

40.1.1. サーバースケジュールスレッドプール

定期的に実行する必要がある、または遅延で実行する必要があるサーバーサイドのほとんどのアクティビティに対してはサーバースケジュールスレッドプールが使用されます。これは、内部的に java.util.concurrent.ScheduledThreadPoolExecutor インスタンスに対してマッピングされます。
このプールで使用されるスレッドの最大数は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlscheduled-thread-pool-max-size パラメーターを使用して設定されます。デフォルト値は 5 個のスレッドです。通常、このプールには少数のスレッドで十分です。

40.1.2. 汎用サーバースレッドプール

この汎用スレッドプールは、サーバーサイドのほとんどの非同期アクションに対して使用されます。これは、内部的に java.util.concurrent.ThreadPoolExecutor インスタンスに対してマッピングされます。
このプールで使用されるスレッドの最大数は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlthread-pool-max-size パラメーターを使用して設定されます。
-1 の値が指定された場合、スレッドプールには上限がなく、要求を満たすのに十分なスレッドがないときに新しいスレッドが要求に応じて作成されます。後でアクティビティがなくなると、スレッドはタイムアウトになり、閉じられます。
n の値 (n はゼロ以外の正の整数) が使用された場合は、スレッドプールがバインドされることを意味します。さらに要求を受け取り、プールに空きスレッドがなく、プールがいっぱいの場合は、スレッドが利用可能になるまで要求がブロックされます。バインドされたスレッドプールは、上限が低く設定された場合にデッドロックの状況になることがあるため、注意して使用することが推奨されます。
thread-pool-max-size のデフォルト値は 30 です。
バインドされない (キャッシュ) スレッドプールとバインドされる (固定) スレッドプールの詳細については、J2SE Javadoc を参照してください。

40.1.3. 期限切れリーパースレッド

単一のスレッドは、キュー内の期限切れメッセージをスキャンするためにサーバーサイドでも使用されます。このスレッドは独自の設定優先度で実行する必要があるため、これに対するいずれかのスレッドプールを使用できません。
リーパーの設定の詳細については、20章メッセージの期限切れ を参照してください。

40.1.4. 非同期 IO

非同期 IO はイベントを受け取り、ネイティブレイヤーからディスパッチするスレッドプールを持ちます。これは接頭辞HornetQ-AIO-poller-pool のスレッドダンプにあります。HornetQ は、ジャーナルでオープン状態のファイルごとに 1 つのスレッドを使用します (通常は 1 つ存在します)。
また、libaio に対する書き込みを行うために使用する単一のスレッドも存在します。これにより、コンテキストの切り替えで発生するパフォーマンスの問題が回避されます。このスレッドは、接頭辞が HornetQ-AIO-writer-pool のスレッドダンプにあります。

40.2. クライアントサイドスレッド管理

クライアントサイドで、HornetQ は、単一のスタティックスケジュールスレッドプールと、JVM インスタンスの同じクラスローダーを使用してすべてのクライアントが使用する単一のスタティック汎用スレッドプールを維持します。
スタティックスケジュールスレッドプールの最大サイズは 5 スレッドであり、汎用スレッドプールはバインドされない最大サイズを持ちます。
また、必要な場合は、各 ClientSessionFactory インスタンスがこれらのスタティックプールを使用せず、独自のスケジュールおよび汎用プールを維持するよう HornetQ を設定できます。ClientSessionFactory から作成されたすべてのセッションは代わりにこれらのプールを使用します。
ClientSessionFactory インスタンスが独自のプールを使用するよう設定するには、作成後すぐに適切なセッターメソッドを使用します。以下に例を示します。
ClientSessionFactory myFactory = HornetQClient.createClientSessionFactory(...);
myFactory.setUseGlobalPools(false);
myFactory.setScheduledThreadPoolMaxSize(10);
myFactory.setThreadPoolMaxSize(-1);
JMS API の使用時に、ClientSessionFactory で同じパラメーターを設定し、ConnectionFactory インスタンスを作成します。以下に例を示します。
ConnectionFactory myConnectionFactory = HornetQJMSClient.createConnectionFactory(myFactory);
JNDI を使用して HornetQConnectionFactory インスタンスをインスタンス化する場合は、接続ファクトリーを定義する JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml ファイルでこれらのパラメーターを設定することもできます。以下に、例を示します。
<connection-factory name="NettyConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>
      <entry name="/XAConnectionFactory"/>
   </entries>
   <use-global-pools>false</use-global-pools>
   <scheduled-thread-pool-max-size>10</scheduled-thread-pool-max-size>
   <thread-pool-max-size>-1</thread-pool-max-size>
</connection-factory>

第41章 ロギング

デフォルトでは、HornetQ は log4j を使用して JBoss Enterprise Application Platform 内のイベントのロギングを管理します。デフォルトのデリゲートは、すべてのログ要求を標準的な JDK ロギング (Java-Util-Logging (JUL) とも呼ばれます) に送信します。

注記

JUL の設定の詳細については、Oracle Web サイトの Java Logging Overview ページを参照してください。
HornetQ は、特定のロギングフレームワークに依存しない独自のロギングデリゲートを持ちます。
デフォルトでは、サーバーは JUL 設定を、設定ディレクトリにある logging.properties ファイルから取得します。これは、HornetQ ロギングフォーマッター (HornetQLoggerFormatter.java) を使用するよう設定され、ログファイルと同様にコンソールにもログを出力します。
プログラムを記述したり、システムプロパティーを使用したりすることにより、異なるロギングデリゲートを設定できます。
プログラムを記述してこれを行う場合は、以下のようになります。ここで、Log4jLogDelegateFactory は使用したい org.hornetq.spi.core.logging.LogDelegateFactory の実装です。
org.hornetq.core.logging.Logger.setDelegateFactory(new Log4jLogDelegateFactory())
システムプロパティーを使用してこれを行うには、プロパティー org.hornetq.logger-delegate-factory-class-name を、使用されるデリゲートファクトリーに設定します。たとえば、以下のようになります。
-Dorg.hornetq.logger-delegate-factory-class-name=org.hornetq.integration.logging.Log4jLogDelegateFactory
上記の例では、利便性のため、HornetQ は、以下のようないくつかのデリゲートファクトリーを提供します。
  1. org.hornetq.core.logging.impl.JULLogDelegateFactory - JUL を使用するデフォルト値。
  2. org.hornetq.integration.logging.Log4jLogDelegateFactory - Log4J を使用します。
クライアントのロギングが JUL デリゲートを使用するよう設定するには、logging.properties ファイルが提供され、java.util.logging.config.file プロパティーがクライアントの起動時に設定されるようにします。

第42章 インターセプト操作

HornetQ は、サーバーに到着するパケットをインターセプトするインターセプターをサポートします。提供されたインターセプターは、サーバーに到着する各パケットに対して呼び出されます。この場合は、パケットの監査やフィルタリングに対してカスタムコードを実行できます。インターセプターはインターセプトされたパケットを変更できます。

42.1. インターセプターの実装

インターセプターは、Interceptor interface を実装する必要があります。
package org.hornetq.api.core.interceptor;

public interface Interceptor
{   
   boolean intercept(Packet packet, RemotingConnection connection) 
                throws HornetQException;
}
返さえたブール値は重要です。
  • true が返された場合、プロセスは通常どおり動作し続けます。
  • false が返された場合は、プロセスが異常終了し、他のインターセプターは呼び出されず、パケットはサーバーによりまったく処理されません。

42.2. インターセプターの設定

インターセプターは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml で設定されます。
<remoting-interceptors>
   <class-name>org.hornetq.jms.example.LoginInterceptor</class-name>
   <class-name>org.hornetq.jms.example.AdditionalPropertyInterceptor</class-name>
</remoting-interceptors>
インターセプタークラス (およびその依存関係) は、適切にインスタンス化し、呼び出すために、サーバークラスパスに追加する必要があります。

42.3. クライアントサイドのインターセプター

また、addInterceptor() メソッドを使用して ClientSessionFactory にインターセプターを追加することにより、インターセプターはサーバーにより送信されたパケットをインターセプトするためにクライアントサイドで実行できます。
インターセプタークラス (およびその依存関係) は、適切にインスタンス化し、クライアントサイドから呼び出すために、クライアントクラスパスに追加する必要があります。

第43章 パフォーマンスチューニング

本章では、パフォーマンスを最適化するために HornetQ をチューニングする方法について説明します。

43.1. 永続化のチューニング

  • メッセージジャーナルを独自の物理ボリュームに置きます。たとえば、ディスクがトランザクションコーディネーター、データベース、またはディスクに対して読み書きを行う他のジャーナルと共有された場合は、これらにより、パフォーマンスが大幅に低下します。これは、ディスクヘッドが異なるファイル間でスキップすることがあるためです。1 つのジャーナルだけを追加する 1 つの利点は、ディスクヘッドの移動が最小化されることです (ディスクが共有される場合、この利点は失われます)。ページングまたは大きいメッセージを使用する場合は、これらが別のボリュームに配置されるようにします。
  • ジャーナルファイルの最小数。journal-min-files を、平均持続レートを満たすファイルの数に設定します。たとえば、ジャーナルデータディレクトリで新しいファイルが頻繁に作成され、たくさんのデータが永続化される場合は、ファイルの最小数を増やします。これにより、ジャーナルは新しいデータファイルを作成する代わりにより多くのファイルを再使用します。
  • ジャーナルファイルサイズ。ジャーナルファイルサイズは、ディスクのシリンダーの容量に調整する必要があります。ほとんどのシステムでは、デフォルト値 10MiB で十分なはずです。
  • AIO ジャーナルを使用します。Linux を使用している場合は、ジャーナルタイプを AIO に保ってください。AIO は Java NIO よりスケーリングが優れています。
  • journal-buffer-timeout をチューニングします。レイテンシーを犠牲にする代わりにスループットを向上させたい場合は、タイムアウトを増加します。
  • AIO を実行している場合は、journal-max-io を増加させることによりパフォーマンスを向上させることができます。NIO を実行している場合は、このパラメーターを変更しないでください。

43.2. JMS のチューニング

JMS API を使用している場合は、以下の領域で最適化を行えます。
  • メッセージ ID を無効にします。MessageProducer クラスの setDisableMessageID() メソッドを使用してメッセージを無効にします (必要ない場合)。これにより、メッセージのサイズが削減され、一意の ID を作成するオーバーヘッドが回避されます。
  • メッセージタイムスタンプを無効にします。MessageProducer クラスの setDisableMessageTimeStamp() メソッドを使用して必要でないメッセージタイムスタンプを無効にします。
  • ObjectMessage を回避します。ObjectMessage は便利ですが、コストがかかります。ObjectMessage のボディーは Java シリアル化を使用してバイトにシリアル化します。小さいオブジェクトの Java シリアル化形式であっても冗長になり、サーバートラフィックが増加します。また、Java シリアル化はカスタムマーシャリングテクニックと比較して低速です。他のいずれかのメッセージタイプが適切でない場合 (たとえば、ペイロードのタイプが実行時まで不明な場合) のみ、ObjectMessage を使用します。
  • AUTO_ACKNOWLEDGE を回避します。AUTO_ACKNOWLEDGE モードは、クライアントで受け取る各メッセージに対してサーバーから送信される承認を必要とします。つまり、ネットワークでトラフィックが増加します。可能な場合は、DUPS_OK_ACKNOWLEDGECLIENT_ACKNOWLEDGE、またはトランザクションセッションを使用して、1 つの承認/コミットで多くの承認をバッチ処理します。
  • 耐性メッセージを回避します。デフォルトでは、JMS メッセージは耐性です。実際には耐性メッセージが必要ない場合は、メッセージを非耐性に設定します。耐性メッセージの場合は、メッセージをストレージに永続化するオーバーヘッドが大幅に増加します。
  • 1 つのトランザクションで多くの送信または承認をバッチ処理します。HornetQ は各送信時または承認時ではなくコミット時にネットワークラウンドトリップのみを必要とします。

43.3. 他のチューニング

HornetQ では、チューニングを実行できるさまざまな場所があります。
  • 非同期送信承認を使用します。耐性メッセージをトランザクションで送信せず、send() へのコールが返されるまでにメッセージがサーバーに到達する保証が必要な場合は、耐性メッセージを送信してブロックするよう設定せずに、非同期送信承認を使用して別のストリームで送り返す承認を取得します。この詳細については、18章送信およびコミットの保証 を参照してください。
  • 事前承認モードを使用します。事前承認モードでは、メッセージがクライアントに送信される前に承認されます。これにより、送信される承認トラフィックの量が削減されます。この詳細については、27章事前承認モード を参照してください。
  • 永続化を無効にします。メッセージ永続化が必要ない場合は、JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xmlpersistence-enabled を false に設定してメッセージ永続化を一括して無効にします。
  • トランザクションをレイジー状態で同期します。hornetq-configuration.xml で、journal-sync-transactionalfalse に設定すると、障害発生時にトランザクションが失われることがありますが、トランザクション永続化のパフォーマンスが向上します。詳細については、18章送信およびコミットの保証 を参照してください。
  • レイジー状態でトランザクションを使用せずに同期します。hornetq-configuration.xml で、journal-sync-non-transactionalfalse に設定すると、障害発生時に耐性メッセージが失われることがありますが、非トランザクション永続化のパフォーマンスが向上します。詳細については、18章送信およびコミットの保証 を参照してください。
  • メッセージをブロックせずに送信します。JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml (JMS と JNDI を使用している場合) または直接 ClientSessionFactory で block-on-durable-sendblock-on-non-durable-sendfalse に設定します。したがって、メッセージを送信するごとにネットワーク全体のラウンドトリップを待つ必要がありません。詳細については、18章送信およびコミットの保証 を参照してください。
  • 非常に高速なコンシューマーの場合は、consumer-window-size を増加させます。これにより、効果的にコンシューマーフロー制御が無効になります。
  • ソケット NIO と古いソケット IO。デフォルトでは、HornetQ はサーバーおよびクライアントサイドで古い方 (ブロッキング) を使用します (詳細については、14章トランスポートの設定 を参照してください)。NIO は非常にスケーラブルですが、古いブロッキング IO と比較してレイテンシーが発生することがあります。サーバーで数千の接続を処理できるように、サーバーでは NIO を使用します。ただし、サーバーでの接続が少ない場合は、サーバーアクセプターに対して古い IO を保持することにより、パフォーマンス上の小さな利点を得ることができます。
  • JMS ではなくコア API を使用します。JMS API を使用すると、コア API を使用する場合よりもパフォーマンスが若干低下します。これは、サーバーが処理する前にすべての JMS 操作をコア操作に変換する必要があります。コア API を使用する場合は、SimpleString をできるだけ多く取得するメソッドを使用するようにしてください。java.lang.String とは異なり、 SimpleString は送信前にコピーを必要としません。したがって、コール間で SimpleString インスタンスを再使用する場合は、不必要なコピーを回避できません。

43.4. トランスポート設定のチューニング

  • TCP バッファーサイズ。高速なネットワークと高速なマシンでは、TCP 送信および受信バッファーサイズを増加させてパフォーマンスを向上させることができます。詳細については、14章トランスポートの設定 を参照してください。

    注記

    Linux の最近のバージョンなどの一部のオペレーティングシステムには TCP 自動チューニングが含まれ、TCP バッファーサイズを手動で設定することにより、自動チューニングが動作することを回避できますが、実際にはパフォーマンスが低下します。
  • サーバーでファイルハンドルの制限を増加します。サーバーでたくさんの同時接続が期待される場合、またはクライアントが接続を素早く開いたり、閉じたりする場合は、サーバーを実行しているユーザーが、十分なファイルハンドルを作成するパーミッションを持つようにしてください。
    これは、オペレーティングシステムによって異なります。Linux システムの場合は、ファイル /etc/security/limits.conf で、オープン可能なファイルハンドルの数を増やします。たとえば、以下の行を追加します。
    serveruser     soft    nofile  20000
    serveruser     hard    nofile  20000
    
    これにより、ユーザー serveruser が最大 20 000 個のファイルハンドルを開くことができるようになります。
  • 非常に小さいメッセージでスループットが最大になるように batch-delay を使用し、direct-deliver を false に設定します。HornetQ では、事前定義されたコネクターとアクセプターのペア (netty-throughput) が JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml に含まれ、JMS 接続ファクトリー (ThroughputConnectionFactory) が JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml に含まれます。これは、特に小さいメッセージの場合にスループットを最大化するために使用できます。詳細については、14章トランスポートの設定 を参照してください。

43.5. アンチパターンの回避

  • 接続、セッション、コンシューマー、およびプロデューサーを再使用します。最も一般的なメッセージングアンチパターンは、送信された各メッセージ、または消費された各メッセージに対して新しい接続、セッション、またはプロデューサーを作成するユーザーです。これは、リソースの適切でない使い方です。これらのオブジェクトは、作成するのに時間がかかり、複数のネットワークラウンドトリップが関係することがあるため、常に再使用します。

    注記

    Spring JMS Template などの一部の人気があるライブラリーは、これらのアンチパターンを使用することが知られています。Spring JMS Template を使用する場合、HornetQ ではなくこれが低いパフォーマンスの原因となることがあります。Spring JMS Template は JMS セッション (JCA の使用など) をキャッシュするアプリケーションサーバーでメッセージを送信するために安全に使用できます。これは、アプリケーションサーバーであっても、メッセージの非同期な消費には安全に使用できません。
  • 大きいメッセージを回避します。XML などの冗長な形式を使用すると、サーバー伝送負荷が増加し、パフォーマンスが低下します。可能な場合は、メッセージボディーで XML を使用しないでください。
  • 各要求に対して一時的なキューを作成しないでください。この一般的なアンチパターンは、一時的なキューの request-response パターンに関係します。一時的なキューの request-response パターンでは、メッセージがターゲットに送信され、返信先ヘッダーがローカルの一時キューのアドレスで設定されます。受信者はメッセージを受信すると、メッセージを処理し、返信先で指定されたアドレスに応答を送り返します。このパターンで行われる一般的な間違いは、送信された各メッセージで新しい一時キューを作成することです。これにより、パフォーマンスは大幅に低下します。代わりに、多くの要求に対して一時キューを再使用する必要があります。
  • Message-Driven Bean は不必要に使用しないでください。MDB を使用すると、単純なメッセージコンシューマーと比較して、受信された各メッセージに対するコードパスが大幅に増加します。これは、たくさんの追加のアプリケーションサーバーコードが実行されるためです。MDB を使用する前に、通常のメッセージコンシューマーの使用を調査してタスクを完了してください。

付録A 設定リファレンス

この項では設定値を検索するクイックインデックスを提供します。要素名をクリックすると、特定の章に移動します。

A.1. サーバー設定

A.1.1. hornetq-configuration.xml

hornetq-configuration.xml ファイルには、コアサーバー設定が含まれます。このファイルは JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml に存在します。

表A.1 サーバー設定

要素名 タイプ 説明 デフォルト
バックアップ ブール値 true の場合は、このサーバーがクラスター内の別のノードに対するバックアップになります。 false
allow-failback ブール値 ライブサーバーが再び利用可能になったときにバックアップサーバーが自動的に停止し、スタンバイモードに戻るかどうかを指定します。false に設定された場合は、サーバーを手動で停止し、スタンバイモードに戻す必要があります。 true
fail-over-on-shutdown ブール値 ライブサーバーが正常にシャットダウンされたときにフェイルオーバーをどのように動作させるかを指定します。true に設定された場合は、ライブサーバーが正常にシャットダウンされたときにバックアップ HornetQ インスタンスが引き継ぎます。 false
shared-store サーバーがジャーナリングのために共有ストアを参照するかどうかを指定します。 false
grouping-handler 親要素 LOCAL および REMOTE グルーピングハンドラーを指定するために使用されます。
remoting-interceptors 親要素 <class-name> を使用してクラス名を指定するために使用されます。この要素の詳細については、42章インターセプト操作 を参照してください。
address-full-policy 文字列 PAGE、DROP、および BLOCK の 3 つの値をサポートします。「ページングモード」 を参照してください。 PAGE
send-to-dla-on-no-route ブール値 サーバーがメッセージをキューにルーティングしないときにどのようにメッセージを処理するかを指定します。true に設定された場合は、メッセージが、ルーティングされたアドレスとして Dead Letter Address (DLA) に送信されます (DLA が存在する場合)。DLA が存在しない場合は、メッセージが最後の手段としてドロップされます。アドレス設定要素の詳細については、「アドレス設定を介してキューを設定」 を参照してください。 false
backup-connector-ref 文字列 バックアップノードに接続するリモートコネクターの名前。
bindings-directory 文字列 保持されたバインディングを格納するディレクトリ。 data/bindings
clustered ブール値 true の場合は、サーバーがクラスタリングされます。 false
connection-ttl-override Long 設定された場合は、ping を受け入れずに接続を保持する時間 (ミリ秒単位) を上書きします。 -1
create-bindings-dir ブール値 true の場合は、サーバーが起動時にバインディングディレクトリを作成します。 true
create-journal-dir ブール値 true の場合は、journal ディレクトリが作成されます。 true
file-deployment-enabled ブール値 true の場合は、サーバーが設定ファイルから設定をロードします。 true
id-cache-size Integer メッセージ ID を事前に作成するためのキャッシュのサイズ。 2000
journal-buffer-size Long ジャーナルの内部バッファーのサイズ。 128 キロバイト
journal-buffer-timeout Long ジャーナルの内部バッファーをフラッシュするために使用されるタイムアウト (ナノ秒単位)。 20000
journal-compact-min-files Integer コンパクト化が行われる前のデータファイルの最小数。 10
journal-compact-percentage Integer ジャーナルのコンパクト化を考慮するライブデータの割合。 30
journal-directory 文字列 ジャーナルファイルを格納するディレクトリ。 data/journal
journal-file-size Long 各ジャーナルファイルのサイズ (バイト単位)。 128 * 1024
journal-max-io Integer 任意の時点で AIO キューに格納できる書き込み要求の最大数。 500
journal-min-files Integer 事前に作成するジャーナルファイルの数。 2
journal-sync-transactional ブール値 true の場合は、応答をクライアントに返す前に、トランザクションデータがジャーナルと同期されるまで待機します。 true
journal-sync-non-transactional ブール値 true の場合は、応答をクライアントに返す前に、非トランザクションデータがジャーナルと同期されるまで待機します。 true
journal-type 文字列 使用するジャーナルのタイプ。 ASYNCIO
jmx-management-enabled ブール値 true の場合は、管理 API が JMX 経由で利用可能になります。 true
jmx-domain 文字列 MBeanServer で HornetQ MBean を登録するために使用する JMX ドメイン。 org.hornetq
large-messages-directory 文字列 大規模なメッセージを格納するディレクトリ。デフォルトの場所は、data/largemessages です。
management-address 文字列 管理メッセージを送信する管理アドレスの名前。デフォルト値は jms.queue.hornetq. management です。
cluster-user 文字列 クラスタリングされたノード間で通信するためにクラスター接続により使用されるユーザー。デフォルト値は HORNETQ.CLUSTER.ADMIN. USER です。 See Description
cluster-password 文字列 クラスタリングされたノード間で通信するためにクラスター接続により使用されるパスワード。 CHANGE ME!!
management-notification-address 文字列 管理通知を受け取るためにコンシューマーがバインドするアドレスの名前。デフォルト値は hornetq.notifications です。 See Description
message-counter-enabled ブール値 true の場合は、メッセージカウンターが有効になります。 false
message-counter-max-day-history Integer メッセージカウンターの履歴を保持する日数。 10
message-counter-sample-period Long メッセージカウンターに使用する期間の例 (ミリ秒単位)。 10000
message-expiry-scan-period Long 期限が切れたメッセージをスキャンする頻度 (ミリ秒単位)。 30000
message-expiry-thread-priority Integer 期限が切れるスレッドメッセージの優先度。 3
paging-directory 文字列 ページメッセージを格納するディレクトリ。 data/paging
persist-delivery-count-before-delivery ブール値 true の場合は、配信前に配信数が保持されます。false の場合、これは、メッセージがキャンセルされた後にのみ実行されます。 false
persistence-enabled ブール値 true の場合は、サーバーが永続化のためにファイルベースのジャーナルを使用します。 true
persist-id-cache ブール値 true の場合は、 ID がジャーナルに保持されます。 true
scheduled-thread-pool-max-size Integer スケジュールされた主要なスレッドプールが持つスレッドの数。 5
security-enabled ブール値 true の場合は、セキュリティーが有効になります。 true
security-invalidation-interval Long セキュリティーキャッシュを無効にするまで待機する時間 (ミリ秒単位)。 10000
thread-pool-max-size Integer 主要なスレッドプールが持つスレッドの数。-1 の場合は、無制限のスレッドが設定されます。 30
async-connection-execution-enabled ブール値 サーバーの受信パケットを、処理のためにスレッドプールからスレッドにハンドオフする必要がありますか、またはこれらのパケットをリモートスレッドで処理する必要がありますか? true
transaction-timeout Long 作成後にトランザクションをリソースマネージャーから削除できるまでの時間 (ミリ秒単位)。 60000
transaction-timeout-scan-period Long タイムアウトトランザクションをスキャンする頻度 (ミリ秒単位)。 1000
wild-card-routing-enabled ブール値 true の場合は、サーバーがワイルドカードルーティングをサポートします。 true
memory-measure-interval Long JVM メモリーをサンプリングする頻度 (ミリ秒単位) (または、メモリーサンプリングを無効にする場合は -1)。 -1
memory-warning-threshold Integer 警告ログをしきい値化する利用可能なメモリーの割合。 25
コネクター 文字列 作成するリモートコネクター設定のリスト。
connector.name (attribute) 文字列 コネクターの名前 (必須)。
connector.factory-class 文字列 ConnectorFactory 実装の名前 (必須)。
connector.param 文字列 コネクターを設定するために使用されるキーと値のペア。コネクターは多くのパラメーターを持つことができます。
connector.param.key (attribute) 文字列 設定パラメーターのキー (必須)。
connector.param.value (attribute) 文字列 設定パラメーターの値 (必須)。
acceptors 文字列 作成するリモートアクセプターのリスト。
acceptor.name (attribute) 文字列 アクセプターの名前 (オプション)。
acceptor.factory-class 文字列 AcceptorFactory 実装の名前 (必須)。
acceptor.param 文字列 アクセプターを設定するために使用されるキーと値のペア。アクセプターは多くのパラメーターを持つことができます。
acceptor.param.key (attribute) 文字列 設定パラメーターのキー (必須)。
acceptor.param.value (attribute) 文字列 設定パラメーターの値 (必須)。
broadcast-groups 作成するブロードキャストグループのリスト。
broadcast-group.name (attribute) 文字列 ブロードキャストグループの一意の名前 (必須)。
broadcast-group.local-bind-address 文字列 データグラムソケットがバインドされるローカルバインドアドレス。デフォルト値は、カーネルにより選択されたワイルドカード IP アドレスです。 See Description
broadcast-group.local-bind-port Integer データグラムソケットがバインドされるローカルポート。 -1 (匿名ポート)
broadcast-group.group-address 文字列 データがブロードキャストされるマルチキャストアドレス (必須)。
broadcast-group.group-port Integer ブロードキャストに使用される UDP ポート番号 (必須)。
broadcast-group.broadcast-period Long 連続するブロードキャスト間の時間 (ミリ秒単位)。 2000 (ミリ秒単位)
broadcast-group.connector-ref Integer ブロードキャストされるペアコネクターとオプションのバックアップコネクター。broadcast-group は複数の connector-ref を持つことができます。
broadcast-group.connector-ref.connector-name (attribute) 文字列 ライブコネクターの名前 (必須)。
broadcast-group.connector-ref.backup-connector-name (attribute) 文字列 バックアップコネクターの名前 (オプション)。
discovery-groups 文字列 作成する検出グループのリスト。
discovery-group.name (attribute) 文字列 検出グループの一意の名前 (必須)。
discovery-group.local-bind-address 文字列 検出グループはこのローカルアドレスにのみバインドされます。
discovery-group.group-address 文字列 リッスンするグループのマルチキャスト IP アドレス (必須)。
discovery-group.group-port Integer マルチキャストグループの UDP ポート (必須)。
discovery-group.refresh-timeout Integer 特定のサーバーから最後のブロードキャストを受け取った後に配信グループが待機する期間 (リストからサーバーコネクターのペアエントリを削除する前)。 5000 (ミリ秒単位)
diverts 文字列 使用する divert のリスト。
divert.name (attribute) 文字列 divert の一意の名前 (必須)。
divert.routing-name 文字列 divert のルーティング名 (必須)。
divert.address 文字列 この divert の元になるアドレス (必須)。
divert.forwarding-address 文字列 divert の転送アドレス (必須)。
divert.exclusive ブール値 この divert は特別ですか? false
divert.filter 文字列 オプションのコアフィルター式。 null
divert.transformer-class-name 文字列 トランスフォーマーのオプションのクラス名。
queues 文字列 作成する事前設定キューのリスト。
queues.name (attribute) 文字列 このキューの一意の名前。
queues.address 文字列 このキューのアドレス (必須)。
queues.filter 文字列 このキューのオプションのコアフィルター式。 null
queues.durable ブール値 このキューは耐久ですか? true
bridges 文字列 作成するブリッジのリスト。
bridges.name (attribute) 文字列 このブリッジの一意の名前。
bridges.queue-name 文字列 このブリッジが消費するキューの名前 (必須)。
bridges.forwarding-address 文字列 転送先アドレス。省略されると、元のアドレスが使用されます。 null
bridges.filter 文字列 オプションのコアフィルター式。 null
bridges.transformer-class-name 文字列 トランスフォーマークラスのオプションの名前。 null
bridges.retry-interval Long 連続する再試行間の時間 (ミリ秒単位)。 2000 (ミリ秒単位)
bridges.retry-interval-multiplier Double 連続する再試行間隔に適用する乗数。 1.0
bridges.reconnect-attempts Integer 再試行の最大数。-1 は無限を示します。 -1
bridges.fail-over-on-server-shutdown ブール値 ターゲットサーバーが正常にシャットダウンした場合に、フェイルオーバーを提示する必要がありますか? false
bridges.use-duplicate-detection ブール値 転送されるメッセージに重複する検出ヘッダーを挿入する必要がありますか? true
bridges.discovery-group-ref 文字列 このブリッジで使用される検出グループの名前。 null
bridges.connector-ref.connector-name (attribute) 文字列 ライブ接続に使用するコネクターの名前。
bridges.connector-ref.backup-connector-name (attribute) 文字列 バックアップ接続に使用するコネクターのオプションの名前。 null
cluster-connections 文字列 クラスター接続のリスト
cluster-connections.name (attribute) 文字列 このクラスター接続の一意の名前。
cluster-connections.address 文字列 このクラスター接続が適用されるアドレスの名前。
cluster-connections.forward-when-no-consumers ブール値 ターゲットの一致するコンシューマーがない場合に、メッセージを負荷分散する必要がありますか? false
cluster-connections.min-large-message-size Integer メッセージサイズしきい値。この値を超えると、クラスターでの送信時にメッセージが複数のパッケージに分割されます。 100 KiB
cluster-connections.reconnect-attempts Integer システムがクラスター上のノードに接続しようとする回数。この回数を超えると (max-retry に到達すると)、ノードは永久的にダウンしたと見なされ、システムはこのノードへのメッセージのルーティングを停止します。 -1 (無限の再試行)
cluster-connections.max-hops Integer ホップクラスタートポロジーの最大数が伝播されます。 1
cluster-connections.retry-interval Long 連続する再試行間の時間 (ミリ秒単位)。 2000
cluster-connections.use-duplicate-detection ブール値 転送されるメッセージに重複する検出ヘッダーを挿入する必要がありますか? true
cluster-connections.discovery-group-ref 文字列 このブリッジで使用される検出グループの名前。 null
cluster-connections.connector-ref.connector-name (attribute) 文字列 ライブ接続に使用するコネクターの名前。
cluster-connections.connector-ref.backup-connector-name (attribute) 文字列 バックアップ接続に使用するコネクターのオプションの名前。 null
cluster-connections.min-large-message-size Integer メッセージサイズの最大しきい値。この値を超えると、クラスターでの送信時にメッセージが複数のパッケージに分割されます。 100 KiB
security-settings 文字列 セキュリティー設定のリスト。
security-settings.match (attribute) 文字列 アドレスとセキュリティーを照合するために使用する文字列。
security-settings.permission 文字列 アドレスに追加するパーミッション。
security-settings.permission.type (attribute) 文字列 パーミッションのタイプ。
security-settings.permission.roles (attribute) 文字列 パーミッションを適用するロールのカンマ区切りのリスト。
address-settings 文字列 アドレス設定のリスト。
address-settings.dead-letter-address 文字列 無効なメッセージを送信するアドレス。
address-settings.max-delivery-attempts Integer 無効なレターアドレスに送信する前にメッセージの配信を試行する回数。 10
address-settings.expiry-address 文字列 期限が切れたメッセージを送信するアドレス。
address-settings.redelivery-delay Long キャンセルされたメッセージを再配信するまでの時間 (ミリ秒単位)。 60000 (ミリ秒単位)
address-settings.last-value-queue boolean キューを最後の値キューとして処理するかどうか。 false
address-settings.page-size-bytes Long アドレスに使用するページサイズ (バイト単位)。 10 * 1024 * 1024
address-settings.max-size-bytes Long アドレスに対するページングで使用する最大サイズ (バイト単位)。 -1
address-settings.redistribution-delay Long 最後のコンシューマーがキューでクローズされるまで待機する時間 (ミリ秒単位) (メッセージを再配信する前)。 60000 (1 分)

A.1.2. hornetq-jms.xml

これは、JMS キュー、トピック、および接続ファクトリーをロードするためにサーバーサイド JMS サービスにより使用される設定ファイルです。これは、デフォルトでJBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml に存在します。

表A.2 JMS サーバー設定

要素名 タイプ 説明 デフォルト
connection-factory JNDI を作成および追加する接続ファクトリーのリスト。
connection-factory.auto-group ブール値 メッセージグルーピングが自動的に使用されるか、されないか。 false
connection-factory.connectors 文字列 接続ファクトリーにより使用されるコネクターのリスト。
connection-factory.connectors.connector-ref.connector-name (attribute) 文字列 ライブサーバー に接続するコネクターの名前。
connection-factory.connectors.connector-ref. backup-connector-name (attribute) 文字列 バックアップサーバー に接続するコネクターの名前。
connection-factory.discovery-group-ref.discovery-group-name (attribute) 文字列 この接続ファクトリーにより使用される検出グループの名前。
connection-factory.discovery-initial-wait-timeout Long ブロードキャストを待機するために検出グループを待機する初期時間 (ミリ秒単位)。 10000
connection-factory.block-on-acknowledge ブール値 メッセージが同期的に承認されるかどうか。 false
connection-factory.block-on-non-durable-send ブール値 非耐性メッセージが同期的に送信されるかどうか。 false
connection-factory.block-on-durable-send ブール値 耐性メッセージが同期的に送信されるかどうか。 true
connection-factory.call-timeout Long リモートコールのタイムアウト (ミリ秒単位)。 30000
connection-factory.client-failure-check-period Long ミリ秒単位の時間。この時間の経過後、クライアントはサーバーからパケットを受け取らない場合に接続が失敗したと見なします。 5000
connection-factory.client-id 文字列 接続ファクトリーに対して事前に設定されたクライアント ID。 null
connection-factory.connection-load-balancing-policy-class-name 文字列 ロードバランシングクラスの名前。デフォルト値は org.hornetq.api.core. client.loadbalance. roundRobinConnection LoadBalancingPolicy です。 See description
connection-factory.connection-ttl Long 接続の存続時間 (ミリ秒単位) 1 * 60000
connection-factory.consumer-max-rate Integer コンシューマーが 1 秒ごとにメッセージを消費できる最速レート。 -1
connection-factory.consumer-window-size Integer コンシューマーフロー制御のウィンドウサイズ (バイト単位)。 1024 * 1024
connection-factory.dups-ok-batch-size Integer DUPS_OK_ACKNOWLEDGE モードを使用する場合の、承認間のバッチサイズ (バイト単位)。 1024 * 1024
connection-factory.fail-over-on-initial-connection ブール値 ライブサーバーへの初期接続に失敗した場合にバックアップにフェイルオーバーするかどうか。 false
connection-factory.fail-over-on-server-shutdown ブール値 サーバーのシャットダウン時にフェイルオーバーするかどうか。 false
connection-factory.min-large-message-size Integer バイト単位のサイズ。これよりも大きいと、メッセージが大きいと見なされます。 100 * 1024
connection-factory.cache-large-message-client ブール値 true の場合は、この接続ファクトリーを使用するクライアントが一時ファイルで大きいメッセージボディを保持します。 false
connection-factory.pre-acknowledge ブール値 送信前にメッセージをサーバーが事前に承認するかどうか。 false
connection-factory.producer-max-rate Integer 1 秒ごとに送信できるメッセージの最大レート。 -1
connection-factory.producer-window-size Integer プロデューサーが送信するメッセージのウィンドウサイズ (バイト単位)。 1024 * 1024
connection-factory.confirmation-window-size Integer 再添付の確認のためのウィンドウサイズ (バイト単位)。 1024 * 1024
connection-factory.reconnect-attempts Integer 再試行の最大数。-1 は無限を示します。 0
connection-factory.retry-interval Long 失敗後に接続を再試行する時間 (ミリ秒単位)。 2000
connection-factory.retry-interval-multiplier Double 連続する再試行間隔に適用する乗数。 1.0
connection-factory.max-retry-interval Integer retry-interval-multiplier が指定された場合の最大試行間隔。 2000
connection-factory.scheduled-thread-pool-max-size Integer スケジュールされたスレッドプールのサイズ。 5
connection-factory.thread-pool-max-size Integer スレッドプールのサイズ。 -1
connection-factory.transaction-batch-size Integer トランザクションセッションの使用時の、承認間のバッチサイズ (バイト単位)。 1024 * 1024
connection-factory.use-global-pools ブール値 スレッドにグローバルスレッドプールを使用するかどうか。 true
queue Queue JNDI を作成および追加するためのキュー。
queue.name (attribute) 文字列 キューの一意の名前。
queue.entry 文字列 JNDI でキューがバインドされるコンテキスト (たくさんある場合があります)。
queue.durable ブール値 キューは耐性ですか? true
queue.filter 文字列 キューのオプションのフィルター式。
topic Topic JNDI を作成および追加するためのトピック。
topic.name (attribute) 文字列 トピックの一意の名前。
topic.entry 文字列 JNDI でトピックがバインドされるコンテキスト (たくさんある場合があります)。

付録B ra.xml HornetQ リソースアダプターファイル

<?xml version="1.0" encoding="UTF-8"?>

<!-- $Id: ra.xml 76819 2008-08-08 11:04:20Z jesper.pedersen $ -->

<connector xmlns="http://java.sun.com/xml/ns/j2ee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
           http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd"
           version="1.5">

   <description>HornetQ 2.0 Resource Adapter</description>
   <display-name>HornetQ 2.0 Resource Adapter</display-name>

   <vendor-name>Red Hat Middleware LLC</vendor-name>
   <eis-type>JMS 1.1 Server</eis-type>
   <resourceadapter-version>1.0</resourceadapter-version>

   <license>
      <description>
Copyright 2009 Red Hat, Inc.
 Red Hat licenses this file to you under the Apache License, version
 2.0 (the "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
   http://www.apache.org/licenses/LICENSE-2.0
 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
 implied.  See the License for the specific language governing
 permissions and limitations under the License.  
      </description>
      <license-required>true</license-required>
   </license>

   <resourceadapter>
      <resourceadapter-class>org.hornetq.ra.HornetQResourceAdapter</resourceadapter-class>
      <config-property>
         <description>
            The transport type. Multiple connectors can be configured by using a comma separated list,
            i.e. org.hornetq.core.remoting.impl.invm.InVMConnectorFactory,org.hornetq.core.remoting.impl.invm.InVMConnectorFactory.
         </description>
         <config-property-name>ConnectorClassName</config-property-name>
         <config-property-type>java.lang.String</config-property-type>
         <config-property-value>org.hornetq.core.remoting.impl.invm.InVMConnectorFactory</config-property-value>
      </config-property>
      <config-property>
         <description>The transport configuration. These values must be in the form of key=val;key=val;,
            if multiple connectors are used then each set must be separated by a comma i.e. host=host1;port=5445,host=host2;port=5446.
            Each set of params maps to the connector classname specified.
         </description>
         <config-property-name>ConnectionParameters</config-property-name>
         <config-property-type>java.lang.String</config-property-type>
         <config-property-value>server-id=0</config-property-value>
      </config-property>
      <!--
      <config-property>
        <description>Does we support HA</description>
        <config-property-name>HA</config-property-name>
        <config-property-type>java.lang.Boolean</config-property-type>
        <config-property-value>false</config-property-value>
      </config-property>
      <config-property>
        <description>The method to use for locating the transactionmanager</description>
        <config-property-name>TransactionManagerLocatorMethod</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value>getTm</config-property-value>
      </config-property>
      <config-property>
        <description>Use A local Transaction instead of XA?</description>
        <config-property-name>UseLocalTx</config-property-name>
        <config-property-type>java.lang.Boolean</config-property-type>
        <config-property-value>false</config-property-value>
      </config-property>
      <config-property>
        <description>The user name used to login to the JMS server</description>
        <config-property-name>UserName</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The password used to login to the JMS server</description>
        <config-property-name>Password</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The jndi params to use to look up the jms resources if local jndi is not to be used</description>
        <config-property-name>JndiParams</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value>java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory;java.naming.provider.url=jnp://localhost:1199;java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces</config-property-value>
      </config-property>
      <config-property>
        <description>The discovery group address</description>
        <config-property-name>DiscoveryAddress</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The discovery group port</description>
        <config-property-name>DiscoveryPort</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The discovery refresh timeout</description>
        <config-property-name>DiscoveryRefreshTimeout</config-property-name>
        <config-property-type>java.lang.Long</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The discovery initial wait timeout</description>
        <config-property-name>DiscoveryInitialWaitTimeout</config-property-name>
        <config-property-type>java.lang.Long</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The load balancing policy class name</description>
        <config-property-name>LoadBalancingPolicyClassName</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The client failure check period</description>
        <config-property-name>ClientFailureCheckPeriod</config-property-name>
        <config-property-type>java.lang.Long</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The connection TTL</description>
        <config-property-name>ConnectionTTL</config-property-name>
        <config-property-type>java.lang.Long</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The call timeout</description>
        <config-property-name>CallTimeout</config-property-name>
        <config-property-type>java.lang.Long</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The dups ok batch size</description>
        <config-property-name>DupsOKBatchSize</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The transaction batch size</description>
        <config-property-name>TransactionBatchSize</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The consumer window size</description>
        <config-property-name>ConsumerWindowSize</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The consumer max rate</description>
        <config-property-name>ConsumerMaxRate</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The confirmation window size</description>
        <config-property-name>ConfirmationWindowSize</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The producer max rate</description>
        <config-property-name>ProducerMaxRate</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The min large message size</description>
        <config-property-name>MinLargeMessageSize</config-property-name>
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The block on acknowledge</description>
        <config-property-name>BlockOnAcknowledge</config-property-name>
        <config-property-type>java.lang.Boolean</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The block on non durable send</description>
        <config-property-name>BlockOnNonDurableSend</config-property-name>
        <config-property-type>java.lang.Boolean</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The block on durable send</description>
        <config-property-name>BlockOnDurableSend</config-property-name>
        <config-property-type>java.lang.Boolean</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The auto group</description>
        <config-property-name>AutoGroup</config-property-name>
        <config-property-type>java.lang.Boolean</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The max connections</description>        
        <config-property-type>java.lang.Integer</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The pre acknowledge</description>
        <config-property-name>PreAcknowledge</config-property-name>
        <config-property-type>java.lang.Boolean</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The retry interval</description>
        <config-property-name>RetryInterval</config-property-name>
        <config-property-type>java.lang.Long</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The retry interval multiplier</description>
        <config-property-name>RetryIntervalMultiplier</config-property-name>
        <config-property-type>java.lang.Double</config-property-type>
        <config-property-value></config-property-value>
      </config-property>
      <config-property>
        <description>The client id</description>
        <config-property-name>ClientID</config-property-name>
        <config-property-type>java.lang.String</config-property-type>
        <config-property-value></config-property-value>
      </config-property>-->

      <outbound-resourceadapter>
         <connection-definition>
            <managedconnectionfactory-class>org.hornetq.ra.HornetQRAManagedConnectionFactory</managedconnectionfactory-class>

            <config-property>
               <description>The default session type</description>
               <config-property-name>SessionDefaultType</config-property-name>
               <config-property-type>java.lang.String</config-property-type>
               <config-property-value>javax.jms.Queue</config-property-value>
            </config-property>
            <config-property>
               <description>Try to obtain a lock within specified number of seconds; less than or equal to 0 disable this functionality</description>
               <config-property-name>UseTryLock</config-property-name>
               <config-property-type>java.lang.Integer</config-property-type>
               <config-property-value>0</config-property-value>
            </config-property>

            <connectionfactory-interface>org.hornetq.ra.HornetQRAConnectionFactory</connectionfactory-interface>
            <connectionfactory-impl-class>org.hornetq.ra.HornetQRAConnectionFactoryImpl</connectionfactory-impl-class>
            <connection-interface>javax.jms.Session</connection-interface>
            <connection-impl-class>org.hornetq.ra.HornetQRASession</connection-impl-class>
         </connection-definition>
         <transaction-support>XATransaction</transaction-support>
         <authentication-mechanism>
            <authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
            <credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface>
         </authentication-mechanism>
         <reauthentication-support>false</reauthentication-support>
      </outbound-resourceadapter>

      <inbound-resourceadapter>
         <messageadapter>
            <messagelistener>
               <messagelistener-type>javax.jms.MessageListener</messagelistener-type>
               <activationspec>
                  <activationspec-class>org.hornetq.ra.inflow.HornetQActivationSpec</activationspec-class>
                  <required-config-property>
                      <config-property-name>destination</config-property-name>
                  </required-config-property>
               </activationspec>
            </messagelistener>
         </messageadapter>
      </inbound-resourceadapter>

   </resourceadapter>
</connector>

		
		
		
		
		<resourceadapter>
  <resourceadapter-class>
    org.hornetq.ra.HornetQResourceAdapter
  </resourceadapter-class>
  <config-property>
     <description>The transport type</description>
     <config-property-name>ConnectorClassName</config-property-name>
     <config-property-type>java.lang.String</config-property-type>
     <config-property-value>
       org.hornetq.core.remoting.impl.invm.InVMConnectorFactory
     </config-property-value>
  </config-property>
  <config-property>
     <description>
       The transport configuration. These values must be in the form of key=val;key=val;
     </description>
     <config-property-name>ConnectionParameters</config-property-name>
     <config-property-type>java.lang.String</config-property-type>
     <config-property-value>server-id=0</config-property-value>
  </config-property>

  <outbound-resourceadapter>
     <connection-definition>
        <managedconnectionfactory-class>org.hornetq.ra.HornetQRAManagedConnection
        Factory</managedconnectionfactory-class>

        <config-property>
           <description>The default session type</description>
           <config-property-name>SessionDefaultType</config-property-name>
           <config-property-type>java.lang.String</config-property-type>
           <config-property-value>javax.jms.Queue</config-property-value>
        </config-property>
        <config-property>
           <description>Try to obtain a lock within specified number of seconds; less
           than or equal to 0 disable this functionality</description>
           <config-property-name>UseTryLock</config-property-name>
           <config-property-type>java.lang.Integer</config-property-type>
           <config-property-value>0</config-property-value>
        </config-property>

        <connectionfactory-interface>org.hornetq.ra.HornetQRAConnectionFactory
        </connectionfactory-interface>
        <connectionfactororg.hornetq.ra.HornetQConnectionFactoryImplonFactoryImpl
        </connectionfactory-impl-class>
        <connection-interface>javax.jms.Session</connection-interface>
        <connection-impl-class>org.hornetq.ra.HornetQRASession
        </connection-impl-class>
     </connection-definition>
     <transaction-support>XATransaction</transaction-support>
     <authentication-mechanism>
        <authentication-mechanism-type>BasicPassword
        </authentication-mechanism-type>
        <credential-interface>javax.resource.spi.security.PasswordCredential
        </credential-interface>
     </authentication-mechanism>
     <reauthentication-support>false</reauthentication-support>
  </outbound-resourceadapter>

  <inbound-resourceadapter>
     <messageadapter>
        <messagelistener>
           <messagelistener-type>javax.jms.MessageListener</messagelistener-type>
           <activationspec>
              <activationspec-class>org.hornetq.ra.inflow.HornetQActivationSpec
              </activationspec-class>
              <required-config-property>
                  <config-property-name>destination</config-property-name>
              </required-config-property>
           </activationspec>
        </messagelistener>
     </messageadapter>
  </inbound-resourceadapter>

  </resourceadapter>

付録C 改訂履歴

改訂履歴
改訂 5.1.2-2.4002013-10-30Rüdiger Landmann
Rebuild with publican 4.0.0
改訂 5.1.2-22012-07-18Anthony Towns
Rebuild for Publican 3.0
改訂 5.1.2-108Tue 28 Feb 2012Russell Dickenson
JBoss Enterprise Application Platform 5.1.2 GA の変更が含まれます。このガイドの内容の変更については、『『リリースノート 5.1.2 (Release Notes 5.1.2)』』を参照してください。

法律上の通知

Copyright © 2010 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.