HornetQ ユーザーガイド
JBoss Enterprise Application Platform 5 向け
エディッション 5.1.2
概要
第1章 はじめに
第2章 HornetQ への移行
2.1. 移行する前に
重要
注記
2.1.1. 重要なデータのバックアップ
2.1.1.1. 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
であることを前提とします)。アプリケーションはいくつかの設定ファイルをデプロイする他の場所を選択できます。
- 接続ファクトリーサービス設定ファイル
- JBoss Messaging サーバーでデプロイされた JMS 接続ファクトリーが含まれます。
- 宛先サービス設定ファイル
- JBoss Messaging サーバーでデプロイされた JMS キューおよびトピックが含まれます。
- ブリッジサービス設定ファイル
- JBoss Messaging サーバーでデプロイされたブリッジサービスが含まれます。
messaging-service.xml
やデータベース永続化設定ファイルなどの他の設定ファイルは、 JBoss Messaging MBean 設定です。HornetQ 実装は、Plain Old Java Object (POJO) のみから構成されるため、これらの設定ファイルは移行の対象となりません。
2.2. アプリケーションコア
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 |
注記
2.3. クライアントサイドの障害処理
producer.send(createMessage(session, i)); System.out.println("Message: " + i);
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 のインストール
2.5. サーバー設定の移行
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で設定されます。このファイルでサポートされるディレクティブの完全セットは、付録A 設定リファレンス で記載されています。
JBoss Messaging サーバー属性 (サーバーピア MBean) | 同等の HornetQ サーバー属性 |
---|---|
ServerPeerID | N/A - HornetQ は指定されたサーバー ID を必要としない |
DefaultQueueJNDIContext 、DefaultTopicJNDIContext | 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 |
Destinations 、MessageCounters 、MessageStatistics | 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 管理オブジェクトおよびブリッジの移行
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
で指定されます。付録A 設定リファレンス には、hornetq-jms.xml
に対するサポートされたすべてのディレクティブが含まれます。
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 |
DefaultTempQueueFullSize 、DefaultTempQueuePageSize 、DefaultTempQueueDownCacheSize | 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 |
EnableOrderingGroup 、DefaultOrderingGroup | N/A |
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
で指定されます。
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 | サポートされない |
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
で定義されます。
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 トピック属性 |
---|---|
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 の他の設定
2.8. 既存のメッセージの移行
2.9. 管理 API を使用するアプリケーション
- JMX
- JMX は、Java アプリケーションを移行する標準的な方法です。
- コア API
- 管理操作はコアメッセージを使用して HornetQ サーバーに送信されます。
- JMS API
- 管理操作は JMS メッセージを使用して HornetQ サーバーに送信されます。
org.jboss.jms.server. Class | org.hornetq.api.jms.management. Class |
---|---|
ServerPeer | JMSServerControl |
connectionfactory.ConnectionFactory | ConnectionFactoryControl |
destination.QueueService | JMSQueueControl |
destination.TopicService | TopicControl |
注記
JDBCPersistenceManagerService
に対する HornetQ の同等なものはありません。これは、HornetQ が JBoss Messaging とは異なりデータソースを必要としないためです。
第3章 メッセージングコンセプト
3.1. メッセージングコンセプト
3.2. メッセージングスタイル
3.2.1. ポイントツーポイントパターン
3.2.2. パブリッシュサブスクライブパターン
3.3. 配信の保証
3.4. トランザクション
XA: JTA
の Java マッピングを使用して大規模なグローバルトランザクションの一部としてメッセージを送信および承認することをサポートします。
3.5. 耐久性
3.6. メッセージング API とプロトコル
3.6.1. Java Message Service (JMS)
3.6.2. システム固有の API
3.7. 高可用性
3.8. クラスター
3.9. ブリッジおよびルーティング
第4章 コアアーキテクチャー
netty.jar
) を持ちます。これは、 いくつかの netty バッファクラスが内部で使用されているためです。
- コアクライアント API
- これは、JMS の複雑な点を除いてメッセージ機能の完全なセットを実現する単純で直感的な Java API です。
- JMS クライアント API
- 標準的な JMS API はクライアント側で利用できます。
図4.1 HornetQ アプリケーションの対話の概略図
第5章 サーバーの使用
5.1. ライブラリーパス
java.library.path
を指定する必要があります。これは、run.sh
スクリプトで自動的に実行されます。
java.library.path
を指定しない場合、JVM は環境変数 LD_LIBRARY_PATH
を使用します。
5.2. システムプロパティー
5.3. 設定ファイル
/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>
hornetq.remoting.netty.host
および hornetq.remoting.netty.port
と置き換えられたことを確認できます。これらの値は、システムプロパティーにある値によって置き換えられます (値が存在する場合)。値が存在しない場合は、デフォルトでそれぞれ localhost または 5445 に設定されます。デフォルト値を提供しないこともできます (つまり、${hornetq.remoting.netty.host}
)。ただし、この場合は、システムプロパティーを提供する必要があります。
5.4. 主要な設定ファイル
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
に含まれます。これは、メッセージングサーバーを設定するために FileConfiguration
Bean によって使用されます。
第6章 JMS の使用
6.1. 単純な注文システム - 設定例
OrderQueue
という名前の JMS キューが、そのキューに注文メッセージを送信する単一の MessageProducer
とともに使用されます。単一の MessageConsumer
は、キューからの注文メッセージを消費します。
durable
に設定されます (サーバーの再起動後やクラッシュ後も保持されます)。
6.1.1. JMS サーバー設定
hornetq-jms.xml
(標準設定 JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
内) には、作成し、JNDI を介してルックアップできる 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 の多くの場所でバインドできます (必要な場合)。
注記
netty
という名前の connector
を参照します。これは、サーバーに実際に接続するために使用されるトランスポートとパラメーターを定義する主要なコア設定ファイル JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
でデプロイされた connector オブジェクトの参照です。
6.1.2. 接続ファクトリータイプ
signature
属性と xa
パラメーターを持ち、これらの組み合わせによってファクトリーのタイプが決定されます。
signature
は 3 つの文字列値 (generic、queue、および topic) を持ちます。
xa
はブール値タイプのパラメーターです。以下の表は、さまざまな接続ファクトリーインターフェースに対する設定値を示しています。
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 |
<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. コード
InitialContect ic = new InitialContext();
ConnectionFactory cf = (ConnectionFactory)ic.lookup("/ConnectionFactory");
Queue orderQueue = (Queue)ic.lookup("/queues/OrderQueue");
Connection connection = cf.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(orderQueue);
MessageConsumer consumer = session.createConsumer(orderQueue);
connection.start();
TextMessage message = session.createTextMessage("This is an order"); producer.send(message);
TextMessage receivedMessage = (TextMessage)consumer.receive(); System.out.println("Got order: " + receivedMessage.getText());
警告
6.2. JNDI を使用せずに直接 JMS リソースをインスタンス化
TransportConfiguration transportConfiguration = new TransportConfiguration(NettyConnectorFactory.class.getName()); ConnectionFactory cf = HornetQJMSClient.createConnectionFactory(transportConfiguration);
Queue orderQueue = HornetQJMSClient.createQueue("OrderQueue");
Connection connection = cf.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(orderQueue);
MessageConsumer consumer = session.createConsumer(orderQueue);
connection.start();
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 の設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
の接続ファクトリーで設定し、<client-id> ディレクティブを使用して設定できます。この接続ファクトリーにより作成された接続では、これがクライアント ID として設定されます。
6.4. DUPS_OK に対してバッチサイズを設定
DUPS_OK
に設定された場合は、承認を一度に 1 つずつではなくバッチで送信するようコンシューマーを設定し、貴重な帯域幅を節約できます。これは、dups-ok-batch-size
要素を介した接続ファクトリーを使用して設定でき、バイト単位で設定されます。デフォルト値は 1024 * 1024 bytes = 1 MiB (メビバイト) です。
6.5. トランザクションバッチサイズの設定
transaction-batch-size
要素を介した接続ファクトリーで設定できます。デフォルト値は 1024 * 1024 (バイト) です。
第7章 コアの使用
7.1. コアメッセージングコンセプト
7.1.1. メッセージ
- メッセージは、クライアントとサーバー間で送信されるデータ単位です。
- メッセージは、データを読み書きする便利なメソッドを含むバッファであるボディを持ちます。
- メッセージは、キーと値のペアであるプロパティーセットを持ちます。各プロパティーキーは、文字列であり、プロパティー値のデータ型は整数、Long、Short、バイト、バイト[]、文字列、倍精度浮動小数点、浮動小数点、またはブールのいずれかになります。
- メッセージは送信先のアドレスを持ちます。メッセージはサーバーに到着すると、アドレスにバインドされたキューにルーティングされます。キューがフィルターにバインドされた場合は、フィルターが一致したときにのみ、メッセージがキューにルーティングされます。アドレスには多くのキューをバインドできます (または、アドレスにまったくキューをバインドしないことも可能です)。アドレスにバインドされた迂回のように、キュー以外のエンティティも存在することがあります。
- メッセージは durable または非 durable のいずれかになります。durable キューの durable メッセージは、サーバーがクラッシュしたり再起動したりした場合は保持されません。
- メッセージは、0 〜 9 の間の優先度値で指定できます。0 は最低の優先度を表し、9 は最大の優先度を表します。HornetQ は優先度が低いメッセージよりも優先度が高いメッセージを配信しようとします。
- メッセージは、オプションの失効期限で指定できます。HornetQ は、失効期限後にメッセージを配信しません。
- メッセージは、メッセージの送信時間を表すオプションのタイムスタンプを持ちます。
- また、HornetQ は非常に大きいメッセージ (ある時点で利用可能な RAM よりも大幅に大きいメッセージ) の送信または消費をサポートします。
7.1.2. アドレス
注記
7.1.3. キュー
7.1.4. ClientSessionFactory
ClientSessionFactory
インスタンスを使用して ClientSession
インスタンスを作成します。ClientSessionFactory
インスタンスは、サーバーに接続してセッションを作成する方法を認識し、多くの設定が可能です。
ClientSessionFactory
インスタンスは、HornetQClient
ファクトリークラスを使用して作成されます。
7.1.5. ClientSession
XAResource
インターフェースを提供できます。
SendAcknowledgementHandler
で登録できます。これにより、送信されたメッセージがサーバーに正常に到着したときにクライアントコードに非動的に通知できます。この機能により、応答を受け取るまで送信された各メッセージに対してブロックせずに、送信されたメッセージがサーバーに到着するようになります。
7.1.6. ClientConsumer
ClientConsumer
インスタンスを使用してキューからメッセージを消費します。コアメッセージングは同期および非同期メッセージ消費セマンティクスをサポートします。ClientConsumer
インスタンスは、オプションのフィルター式で設定でき、その式に一致するメッセージのみを消費します。
7.1.7. ClientProducer
ClientSession
インスタンス上で ClientProducer
インスタンスを作成します。ClientProducer インスタンスは、送信されたすべてのメッセージがルーティングされるアドレスを使用できます。また、このインスタンスが指定されたアドレスを持たないようにすることもできます。この場合、アドレスはメッセージの送信時に指定されます。
警告
7.2. 単純なコアの例
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.queue.
が付加されたコアキューに対してマッピングされます。たとえば、名前が "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章 クライアントクラスパス
警告
$JBOSS_HOME/client
ディレクトリ内に存在します。jar は正しいリリースのバージョンからのみ使用してください。異なる HornetQ バージョンの jar バージョンを混在させないでください。異なる jar バージョンを混在させると、エラーが発生することがあります。
9.1. HornetQ コアクライアント
hornetq-core-client.jar
と netty.jar
を指定する必要があります。
9.2. JMS クライアント
hornetq-jms-client.jar
と jboss-javaee.jar
も含める必要があります。
注記
jboss-javaee.jar
には、javax.jms.*
クラスに必要な Java EE API インターフェースクラスのみが含まれます。クラスパスにこれらのインターフェースクラスを持つ jar がすでに指定されている場合は、必要ありません。
9.3. JNDI を使用した JMS クライアント
jnp-client.jar
と以前に示された他の jar も必要です。
第10章 ワイルドカードを使用してメッセージをルーティング
queue.news.#
などのアドレスで作成された場合、キューはこれに一致するアドレスに送信されたすべてのメッセージを受け取ります。この例としては、queue.news.europe
、queue.news.usa
、queue.news.usa.sport
などがあります。このキューでコンシューマーを作成した場合、コンシューマーはアドレスの階層に送信されたメッセージを消費できます。
注記
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
ファイルのプロパティー wild-card-routing-enabled
を true
に設定します。この場合、デフォルト値は true
です。
第11章 HornetQ ワイルドカード構文について
.
' (ピリオド) で区切られた単語が含まれます。
#
' と '*
' は特別な意味を持ち、単語の代わりになることがあります。
#
' は、「任意の順序のゼロ以上の単語に一致する」ことを意味します。
*
' は、「単一の単語に一致する」ことを意味します。
第12章 フィルター表現
- 事前定義されたキュー。キューを
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章管理 で説明されたように、フィルターは、複数の場所でコンシューマー、キューを作成するときにプログラムで使用されます。
- HQPriority
- メッセージの優先度を参照します。メッセージの優先度は
0 〜 9
の有効な整数値です。0
は最小の優先度であり、9
は最大の優先度です。たとえば、HQPriority = 3 and department = 'payroll'
のようになります。これは、優先度が 3 であり、部門が 'payroll' のメッセージを参照します。 - HQExpiration
- メッセージの期限切れ時間を参照します。値は Long 型の整数値です。
- HQDurable
- メッセージが耐性であるかどうかを参照します。値は有効な値
DURABLE
またはNON_DURABLE
を持つ文字列です。 - HQTimestamp
- メッセージが作成されたタイムスタンプ。値は Long 型の整数値です。
- HQSize
- メッセージのサイズ (バイト単位)。値は整数です。
第13章 永続化
- Java 非ブロック IO (NIO)
- ファイルシステムと接続するために標準的な Java NIO を使用します。これにより、パフォーマンスが大幅に向上し、Java 6 以降のランタイムがあるプラットフォームで実行が可能になります。
- Linux 非同期 IO (AIO)
- Linux 非同期 IO ライブラリー (AIO) と対話するには、ネイティブコードラッパーを使用します。AIO では、データが永続化されたときに HornetQ がメッセージを受け取ります。これにより、明示的な同期の必要がなくなります。一般的に、AIO は Java NIO よりも高いパフォーマンスを提供しますが、Linux カーネル 2.6 以降と libaio が必要になります。また、AIO は
ext2
、ext3
、ext4
、jfs
、またはxfs
タイプファイルシステムを必要とします。NFS では、AIO は低速で同期の動作になります。注記
Red Hat Enterprise Linux の場合は、libaio を以下のコマンドでインストールします。yum install libaio
- バインディングジャーナル
- サーバーにデプロイされたキューと属性のセットを含むバインディング関連のデータを格納します。また、ID シーケンスカウンターなどのデータも格納します。バインディングジャーナルは常に NIO ジャーナルであり、通常は、メッセージジャーナルと比較して低いスループットを持ちます。このジャーナル上のファイルは、接頭辞
hornetq-bindings
で設定されます。各ファイルはbindings
拡張を持ちます。ファイルサイズは1048576
バイトであり、ファイルはバインディングフォルダーにあります。 - JMS ジャーナル
- JMS キュー、トピック、接続ファクトリーなどのすべての JMS 関連のデータと、これらのリソースに対する JNDI バインディングを格納します。管理 API で作成されたすべての JMS リソースはこのジャーナルに永続化されます。設定ファイルで設定されたすべてのリソースはこのジャーナルに永続化されません。このジャーナルは、JMS が使用中の場合のみ作成されます。
- メッセージジャーナル
- メッセージ自体と
duplicate-id
キャッシュを含むすべてのメッセージ関連のデータを格納します。デフォルトでは、HornetQ はこのジャーナルに AIO を使用します。AIO が利用不可の場合は、自動的にNIO が使用されます。
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 ジャーナルの設定
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
を満たす必要があります。
警告
disabled
になっていることを確認してください。これにより、パフォーマンスが低下することがありますが、データの整合性は保持されます。
13.4. HornetQ でのゼロ永続化の設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
の persistence-enabled
パラメーターを false
に設定します。
重要
false
に設定された場合、永続化は実行されません。バインディングデータ、メッセージデータ、大きなメッセージデータ、重複 ID キャッシュ、またはページングデータは永続化されません。
13.5. ジャーナルデータのインポート/エクスポート
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章 トランスポートの設定
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 つのサーバーに対するアクセプターの数に上限はありません。
5446
で接続をリッスンするために Netty を使用する acceptor
を定義します。
acceptor
要素には、アクセプターインスタンスを作成するために使用されるファクトリーを定義するサブ要素 factory-class
が含まれます。この場合、Netty は、接続をリッスンするために使用されるため、AcceptorFactory
の Netty 実装が使用されます。factory-class
要素は、どの接続可能なトランスポートをリッスンするかを決定します。
acceptor
要素は、ゼロ以上の param
サブ要素で設定することもできます。各 param
要素はキーと値のペアを定義します。これらのキーと値のペアは、特定のトランスポートを設定するために使用され、有効なキーと値のペアセットは使用される特定のトランスポートに依存し、基礎となるトランスポートに直接渡されます。
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>
- 場合によっては、サーバーは別のサーバーへの接続時 (あるサーバーが別のサーバーにブリッジ接続される場合やサーバーがクラスターに参加する場合) にクライアントとして動作します。この場合、サーバーは他のサーバーに接続する方法を認識する必要があります。これは、コネクターによって定義されます。
- 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(...);
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 トランスポートの設定
14.4.1. Netty TCP の設定
警告
重要
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-deliver
をtrue
(デフォルト値) に設定します。スループットを最大にするには、false
に設定します。 nio-remoting-threads
- NIO を使用するよう設定された場合、デフォルトで HornetQ は、
Runtime.getRuntime().availableProcessors()
により報告されたコア (またはハイパースレッド) としてスレッドの数の 3 倍の数を使用して受信パケットを処理します。nio-remoting-threads
はこれを上書きし、使用するスレッドの数を定義します。デフォルト値は-1
であり、Runtime.getRuntime().availableProcessors()
の値の 3 倍の数を表します。
14.4.2. Netty SSL の設定
ssl-enabled
true
に設定して SSL を有効にします。key-store-path
- クライアント証明書を保持するクライアントで SSL キーストアへのパスを定義します。
key-store-password
- クライアントでクライアント証明書キーストアのパスを定義します。
trust-store-path
- 信頼できるクライアント証明書ストアへのパスをサーバーで定義します。
trust-store-password
- 信頼できるクライアント証明書ストアのパスワードをサーバーで定義します。
14.4.3. Netty HTTP の設定
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 サーバートランスポートのためにサーブレットエンジンを設定
- サーブレットをデプロイします。サーブレットを使用する 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>
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>
- クライアントのコネクターを
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 アプリケーション (存在する場合) のアプリケーションコンテキストを使用してこれに照合する必要があります。
<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>
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" />
第15章 使用済みの接続の検出
15.1. サーバーで使用済みの接続リソースをクリーンアップ
finally
ブロックを使用してクローズする必要があります。
例15.1 正常に動作するコアクライアントアプリケーション
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 クライアントアプリケーション
Connection jmsConnection = null; try { ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactory(...); jmsConnection = jmsConnectionFactory.createConnection(); ... do some stuff with the connection... } finally { if (connection != null) { connection.close(); } }
connection TTL
は設定可能です。各 ClientSessionFactory
は定義された connection TTL
を持ちます。TTL は、クライアントから到着するデータが存在しない場合に、サーバーがe接続を保持する時間を決定します。
- クライアントサイドで、
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
の場合は、サーバーサイドでサーバーの接続がタイムアウトしません。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
ファイルで connection-ttl-override
属性を指定します。connection-ttl-override
のデフォルト値は、-1
であり、クライアントは接続 TTL に対して独自の値を設定できます。
15.1.1. クローズに失敗したコアセッションまたは 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)
15.2. クライアントサイドから障害を検出
client-failure-check-period
ミリ秒の間まったくパケットを受け取らない場合、クライアントは接続が失敗したと見なし、設定に応じてフェイルオーバーを開始するか、または任意の SessionFailureListener
インスタンス (JMS を使用している場合は ExceptionListener
インスタンス) を呼び出します。
HornetQConnectionFactory
インスタンス上の ClientFailureCheckPeriod
属性によって定義されます。JMS 接続ファクトリーインスタンスは、サーバーサイドの JNDI に直接デプロイされる場合にパラメーター client-failure-check-period
を使用して JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
設定ファイルで指定できます。
30000
ms (30 秒) です。値が -1
の場合は、データをサーバーから受け取らないときにクライアントサイドで接続が失敗します。通常、これは、一時的な障害発生時にクライアントが再接続できるよう接続 TTL 値よりも大幅に小さくなります。
15.3. 非同期接続実行の設定
注記
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
のパラメーター async-connection-execution-enabled
が true に設定されるようにしてください。
第16章 リソースマネージャーの設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
の transaction-timeout
プロパティを編集して変更できます (値はミリ秒単位である必要があります)。プロパティ transaction-timeout-scan-period
は、古いトランザクションをスキャンする頻度をミリ秒単位で設定します。
第17章 フロー制御
17.1. コンシューマーフロー制御
receive()
メソッドを使用してコンシューマーに配信するか、メッセージリスナーで非同期的にコンシューマーに配信する前にメッセージをバッファーします。メッセージは、メッセージが配信され、内部バッファーにインストールされたときにコンシューマーがメッセージをすぐに処理できない場合に構築できます。これにより、メッセージを時間内に処理できない場合にクライアントでメモリーが足りなくなることがあります。
17.1.1. ウィンドウベースフロー制御
consumer-window-size
パラメーターによって決定されます。
consumer-window-size
が 1 MiB (1024 * 1024 バイト) に設定されます。
- バインドされないバッファーの場合は
-1
- メッセージをバッファーしない場合は
0
- 該当する最大サイズ (バイト単位) のバッファーの場合は
>0
。
- 高速なコンシューマー
- 高速なコンシューマーは、メッセージを消費するとすぐにメッセージを処理できます。高速なコンシューマーを許可するには、
consumer-window-size
を -1 に設定します。これにより、クライアントサイドでバインドされないメッセージバッファリングが許可されます。この設定は注意して使用してください。これは、コンシューマーがメッセージを受信したときにすぐにメッセージを処理できない場合に、クライアントのメモリーをオーバーフローすることがあります。 - 低速なコンシューマー
- 低速なコンシューマーの場合は、各メッセージを処理するのに大幅な時間がかかります。したがって、クライアントサイドでメッセージのバッファリングを回避し、メッセージを別のコンシューマーに代わりに配信できることが望まれます。キューが 2 つのコンシューマーを持つ状況を考えます (このうちの 1 は非常に低速です)。メッセージは循環形式で両方のコンシューマーに配信されます。高速なコンシューマーは、バッファーが空になるまですべてのメッセージを非常に速く処理します。この時点で、低速なコンシューマーのバッファーには処理したいメッセージが引き続き存在し、高速なコンシューマーによってメッセージが処理されることが回避されます。したがって、高速なコンシューマーは、他のメッセージを処理できる場合にアイドル状態になります。低速なコンシューマーを許可するには、
consumer-window-size
を 0 (バッファーなし) に設定します。これにより、低速なコンシューマーがクライアントサイドでメッセージをバッファーすることが回避されます。メッセージは、サーバーサイドで保持され、他のコンシューマーが消費できる状態になります。これを 0 に設定すると、キューの複数のコンシューマー間で明確なディストリビューションが提供されます。
consumer-window-size
の値の設定は、メッセージング使用ケースに基づき、最適な値を見つけるためにベンチマークが必要です。ただし、ほとんどの場合は、1MiB の値で適切です。
17.1.1.1. コア API の使用
ClientSessionFactory.setConsumerWindowSize()
メソッドと ClientSession.createConsumer()
メソッドのいくつかによって指定されます。
17.1.1.2. JMS の使用
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
です。
17.1.2.1. コア API の使用
ClientSessionFactory.setConsumerMaxRate(int consumerMaxRate)
メソッドまたは ClientSession.createConsumer()
メソッドの一部によって設定できます。
17.1.2.2. JMS の使用
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)
メソッドで設定できます。
注記
17.2. プロデューサーフロー制御
17.2.1. ウィンドウベースフロー制御
17.2.1.1. コア API の使用
ClientSessionFactory.setProducerWindowSize(int producerWindowSize)
メソッドを使用して設定できます。
17.2.1.2. JMS の使用
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. ブロッキングプロデューサーウィンドウベースフロー制御
max-size-bytes
と address-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>
BLOCK
に設定する必要があることに注意してください。
17.2.2. レート制限フロー制御
-1
に設定すると、レート制限フロー制御が無効になります。デフォルト値は -1
です。
17.2.2.1. コア API の使用
ClientSessionFactory.setProducerMaxRate(int consumerMaxRate)
メソッド、または一部の ClientSession.createProducer()
メソッドで設定できます。
17.2.2.2. JMS の使用
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. トランザクション完了の保証
journal-sync-transactional
の値に応じて、サーバーで、応答がクライアントに送信し返される前に、コミットまたはロールバックがストレージに永続化されるようになります。このパラメーターの値が false
の場合、応答がクライアントに送信された後にしばらくたつまでコミットまたはロールバックは実際にはストレージに永続化されないことがあります。サーバーでの障害発生時に、これは、コミットまたはロールバックがストレージに永続化されないことを意味します。このパラメーターのデフォルト値は true
であり、クライアントで、コミットまたはロールバックのコールが返されるまですべてのトランザクションコミットまたはロールバックがストレージに永続化されるようになります。
false
に設定すると、トランザクション耐性がある程度失われる代わりにパフォーマンスが向上します。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で設定されます。
18.2. 非トランザクションメッセージ送信の保証
BlockOnDurableSend
- これが
true
に設定された場合、非トランザクションセッションの耐性メッセージに対するすべての送信コールは、メッセージがサーバーに到達し、応答が送り返されるまでブロックされます。デフォルト値はtrue
です。 BlockOnNonDurableSend
- これが
true
に設定された場合、非トランザクションセッションの非耐性メッセージに対するすべての送信コールは、メッセージがサーバーに到達し、応答が送り返されるまでブロックされます。デフォルト値はfalse
です。
true
に設定すると、次の送信が実行される前に各送信がネットワークラウンドトリップを必要とするため、パフォーマンスが低下することがあります。つまり、メッセージを送信するパフォーマンスは、ネットワークの帯域幅ではなくネットワークのネットワークラウンドトリップ時間 (RTT) によって制限されます。パフォーマンスを向上させるために、多くのメッセージ送信を 1 つのトランザクションでバッチ処理するか (トランザクションセッションでは、コミット/ロールバックのみが各送信をブロックしません)、「非同期送信承認」 で説明された 非同期送信承認機能を使用します。
block-on-durable-send
および block-on-non-durable-send
を使用してこれらのパラメーターを JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
で設定できます。JMS を使用し、JNDI を使用していない場合は、適切なセッターメソッドを使用して HornetQConnectionFactory
インスタンスで直接これらの値を設定できます。
ClientSessionFactory
インスタンスで直接これらの値を設定できます。
journal-sync-non-transactional
が true
に設定されている場合、サーバーは、メッセージが永続化され、データがディスクに永続化されたことがサーバーで保証されるまで応答をクライアントに送り返しません。このパラメーターのデフォルト値は true
です。
18.3. 非トランザクション承認の保証
BlockOnAcknowledge
で設定されます。これが true
に設定された場合、非トランザクションセッションのすべての承認コールは承認がサーバーに到達し、応答が送り返されるまでブロックされます。厳密な 1 度だけの配信ポリシーを実装する場合は、これを true
に設定します。デフォルト値は false
です。
18.4. 非同期送信承認
18.4.1. 非同期送信承認
org.hornetq.api.core.client.SendAcknowledgementHandler
を実装し、ClientSession
でハンドラーインスタンスを設定します。
ClientSession
を使用して通常どおりメッセージを送信します。メッセージがサーバーに到着すると、サーバーは送信の承認を非同期で送り返します。HornetQ はハンドラーの sendAcknowledged(ClientMessage message)
メソッドを呼び出し、送信されたメッセージへの参照を渡します。
confirmation-window-size
が正の整数値に設定されるようにします (バイト単位で指定)。たとえば、10485760 (10 メビバイト) になります。
第19章 メッセージ再配信と未配信メッセージ
- 遅延再配信
- メッセージ配信は、クライアント時間が一時的な失敗から回復し、ネットワークまたは CPU リソースをオーバーロードしないように遅延させることができます。
- 死亡したレターアドレス
- 配信できないと判断された後にメッセージを送信する死亡したレターアドレスを設定します。
19.1. 遅延再配信
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 分) に設定されます。
19.2. 死亡したレターアドレス
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
の失敗回数後に削除されます。
max-delivery-attempts
を -1
に設定します。
max-delivery-attempts
を-1
に設定します。
19.2.2. 死亡したレターのプロパティ
HQ_ORIG_ADDRESS
- 死亡したレターメッセージの元のアドレスを含む文字列プロパティ。
19.3. 配信数の永続化
redelivered
が false
に設定されたメッセージを配信できます (true
である必要がある場合)。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で persist-delivery-count-before-delivery
を true
に設定します。
<persist-delivery-count-before-delivery> true </persist-delivery-count-before-delivery>
第20章 メッセージの期限切れ
TimeToLive
) で設定できます。
20.1. メッセージの期限切れ
// message will expire in 5000ms from now message.setExpiration(System.currentTimeMillis() + 5000);
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. 期限切れアドレスの設定
<!-- 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>
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章 大きなメッセージ
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
により決定されます。
21.2.1. コア API の使用
ClientSessionFactory.setMinLargeMessageSize
により指定されます。
ClientSessionFactory factory = HornetQClient.createClientSessionFactory(new TransportConfiguration(NettyConnectorFactory.class.getName()), null); factory.setMinLargeMessageSize(25 * 1024);
21.2.2. 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> <min-large-message-size>250000</min-large-message-size> </connection-factory> ...
HornetQConnectionFactory.setMinLargeMessageSize
で指定されます。
21.3. 大きいメッセージのストリーミング
java.lang.io
)。
ClientMessage.saveOutputStream
、またはメッセージをストリームに非同期的に書きこむメソッド ClientMessage.setOutputstream
を使用して出力ストリームが復元されるときにブロックを選択できます。ClientMessage.setOutputstream
を選択した場合は、メッセージが完全に受信されるまでコンシューマーが存続している必要があります。
- JDBC BLOB
SocketInputStream
HTTPRequests
から復元されるものなど
java.io.InputStream
、またはメッセージを受信するために java.io.OutputStream
を実装するすべてのものを使用できます。
21.3.1. コア API を介したストリーミング
ClientMessage
で利用可能なメソッドのリストを示しています。
名前 | 説明 | 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 を介したストリーミング
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);
注記
StreamMessage
と BytesMessage
でだけサポートされます。
21.4. 別のストリーミング方法
InputStream
または OutputStream
機能を使用しない場合、データには別の方法で直接アクセスできます。
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 }
BytesMessage
とStreamMessage
は、これを透過的にサポートします。
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. クライアントでの大きいメッセージのキャッシュ
cache-large-message-client
を有効にできます。このプロパティーを有効にした場合、クライアントコンシューマーは大きいメッセージの内容を保持する一時ファイルを作成するため、大きいメッセージを再送信できます。
注記
第22章 ページング
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. ページングモード
注記
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>
プロパティー名 | 説明 | デフォルト |
---|---|---|
max-size-bytes | ページモードになる前にアドレスが持つことができる最大メモリー。 | -1 (無効) |
page-size-bytes | ページングシステムで使用される各ページファイルのサイズ | 10MiB (10 * 1024 * 1024 バイト) |
address-full-policy | ページングを有効にするには、これを PAGE に設定する必要があります。
| PAGE |
page-max-cache-size | ページングナビゲーション中に入力/出力サイクルを最適化するためにメモリーに保持されるページファイルの数を指定します。 | 5 |
22.4. メッセージのドロップ
address-full-policy
を DROP
に設定します。
22.5. プロデューサーのブロック
address-full-policy
を BLOCK
に設定します。
重要
22.6. 複数のキューを持つアドレスの注意
- アドレスが 10 個のキューを持ちます。
- キューの 1 つがメッセージを配信しません (おそらく、低速なコンシューマーが原因)。
- メッセージは、連続してアドレスに到着し、ページングが開始されます。
- メッセージが送信された場合であっても他の 9 個のキューは空になります。
重要
重要
page-size-bytes
(サーバー) を ack-batch-size
(クライアント) よりも小さい値に設定しないでください。設定すると、システムがハングしているように見えることがあります。
第23章 キュー属性
23.1. 事前定義されたキュー
以下は、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>
jms.queue.selectorQueue
になるようにします。
null
になります。
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 の命名規則がないキューに対して使用された実際の名前になります。
- アドレス要素は、メッセージをルーティングするために使用されるアドレスを定義します。
- エントリー要素はありません。
23.2. API の使用
org.hornetq.api.core.client.ClientSession
インターフェースを使用して作成できます。以前に記載されたすべての属性の設定をサポートする複数の createQueue
メソッドが存在します。この API を使用して temporary
である特別な属性を設定できます。これを true
に設定すると、セッションが切断されたときにキューが削除されます。
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 の場合、クライアントメッセージプロデューサーは追加のメッセージを送信しようとしたときにブロックされます。
第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();
第25章 Last-Value キュー
25.1. Last-Value キューの設定
<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) です。
// 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 を持つすべてのメッセージを受け取ります。
26.1. コア API の使用
"_HQ_GROUP_ID"
(または定数 MessageImpl.HDR_GROUP_ID
) です。または、ランダムで一意の ID を所得する SessionFactory
で autogroup
を設定できます。
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);
HornetQConnectionFactory
で autogroup
を 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>
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. クラスタリングされたグループ化
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>
注記
26.3.1. クラスタリングされたグループ化のベストプラクティス
- 可能な場合は、コンシューマーがさまざまなノードで均等に分散されるようにします。これは、コンシューマーを定期的に作成し、閉じる場合にのみ問題になります。メッセージは割り当てられた同じキュー常にルーティングされるため、このキューからコンシューマーを削除すると、コンシューマーがなくなり、キューがメッセージを受信し続けることになります。コンシューマーを閉じないようにするか、常にたくさんのコンシューマーがあるようにします。つまり、3 つのノードがある場合は、3 つのコンシューマーを用意します。
- 可能な場合は、耐性キューを使用します。グループがキューにバインドされたときにキューが削除された場合は、他のノードがメッセージをキューにルーティングすることを試行できます。これは、メッセージを送信するセッションでキューが削除されるようにすることにより回避できます。つまり、テキストメッセージが送信された場合、メッセージはキューが削除されたノードに送信され、新しい提示が適切に行わなわれるようになります。または、異なるグループ ID を使用して開始することもできます。
- 常に、ローカルグループ化ハンドラーを持つノードがレプリケートされるようにしてください。つまり、グループ化はフェイルオーバーで引き続き実行できます。
第27章 事前承認モード
AUTO_ACKNOWLEDGE
CLIENT_ACKNOWLEDGE
DUPS_OK_ACKNOWLEDGE
注記
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>
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
インストールで直接事前承認を設定できます。
ClientSessionFactory
インスタンスで直接これを設定できます。
第28章 管理
- サーバー設定の変更。
- 新しいリソースの作成 (たとえば、JMS キューやトピック)。
- これらのリソースの検査 (たとえば、キューに現在保持されているメッセージの数)。
- これらのリソースとの対話 (つまり、キューからのメッセージの削除)。
- JMX の使用。JMX は、Java アプリケーションを管理する標準的な方法です。
- コア API の使用。管理操作はコアメッセージを使用して HornetQ サーバーに送信されます。
- JMS API の使用。管理操作は JMS メッセージを使用して HornetQ サーバーに送信されます。
28.1. 管理 API
- コアリソースは、org.hornetq.api.core.management パッケージに含まれます。
- JMS リソースは org.hornetq.api.jms.management パッケージに含まれます。
注記
null
または空の文字列を渡すと、管理操作がすべてのメッセージで実行されます。
28.1.1. コア管理 API
28.1.1.1. コアサーバー管理
- キューのリスト、作成、デプロイ、および破棄
- デプロイされたコアキューのリストは、
getQueueNames()
メソッドを使用して取得できます。コアキューは、管理操作を使用して作成または破棄できます。createQueue()
deployQueue()
HornetQServerControl
のdestroyQueue()
(ObjectNameorg.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. コアキュー管理
QueueControl
クラスは、コアキュー管理操作を定義します (ObjectName org.hornetq:module=Core,type=Queue,address="<the bound address>",name="<the queue name>"
またはリソース名 core.queue.<the queue name>
と使用)。
- デッドレターアドレスの期限切れ、デッドレターアドレスへの送信、メッセージの移動
- メッセージは、
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. 他のコアリソース管理
- アクセプター
- アクセプターは、
AcceptorControl
クラスのstart()
またはstop()
メソッドを使用して開始または停止できます (org.hornetq:module=Core,type=Acceptor,name="<the acceptor name>"
またはリソース名core.acceptor.<the address name>
とともに使用)。アクセプターのパラメーターは、AcceptorControl
属性を使用して取得できます (「アクセプターについて」 を参照)。 - 迂回
- 迂回は
DivertControl
クラスのstart()
またはstop()
を使用して開始または停止できます (ObjectNameorg.hornetq:module=Core,type=Divert,name=<the divert name>
またはリソース名core.divert.<the divert name>
とともに使用)。迂回パラメーターは、DivertControl
属性を使用して取得できます (33章メッセージフローの迂回と分割 を参照)。 - ブリッジ
- これらは、
BridgeControl
クラスのstart()
(resp.stop()
) メソッドを使用して開始または停止できます (ObjectNameorg.hornetq:module=Core,type=Bridge,name="<the bridge name>"
またはリソース名core.bridge.<the bridge name>
とともに使用)。ブリッジパラメーターは、BridgeControl
属性を使用して取得できます (34章コアブリッジ を参照)。 - ブロードキャストグループ
- ブロードキャストグループは、
BroadcastGroupControl
クラスのstart()
またはstop()
を使用して開始または停止できます (ObjectNameorg.hornetq:module=Core,type=BroadcastGroup,name="<the broadcast group name>"
またはリソース名core.broadcastgroup.<the broadcast group name>
とともに使用)。ブロードキャストグループパラメーターは、BroadcastGroupControl
属性を使用して取得できます (「ブロードキャストグループ」 を参照)。 - 検出グループ
- これらは、
DiscoveryGroupControl
クラスのstart()
またはstop()
めそっどを使用して開始または停止できます (ObjectNameorg.hornetq:module=Core,type=DiscoveryGroup,name="<the discovery group name>"
またはリソース名core.discovery.<the discovery group name>
とともに使用)。検出グループパラメーターは、DiscoveryGroupControl
属性を使用して取得できます (「検出グループ」 を参照)。 - クラスター接続
- これらは、
ClusterConnectionControl
クラスのstart()
またはstop()
メソッドを使用して開始または停止できます (ObjectNameorg.hornetq:module=Core,type=ClusterConnection,name="<the cluster connection name>"
またはリソース名core.clusterconnection.<the cluster connection name>
とともに使用)。クラスター接続パラメーターは、ClusterConnectionControl
属性を使用して取得できます (「クラスター接続の設定」 を参照)。
28.1.2. JMS 管理 API
28.1.2.1. 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 管理
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 キュー管理
JMSQueueControl
クラスを使用して管理できます (ObjectName org.hornetq:module=JMS,type=Queue,name="<the queue name>"
またはリソース名 jms.queue.<the queue name>
とともに使用)。
- デッドレターアドレスの期限切れ、デッドレターアドレスへの送信、メッセージの移動
- メッセージは、
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 トピック管理
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 を介した管理の使用
org.hornetq
でリソースを登録します。
exampleQueue
を管理する ObjectName
は、以下のようになります。
org.hornetq:module=JMS,type=Queue,name="exampleQueue"
org.hornetq.api.jms.management.JMSQueueControl
ObjectName
は、ヘルパークラスorg.hornetq.api.core.management.ObjectNameBuilder
を使用して構築されます。また、jconsole
を使用して管理する MBean のObjectName
を見つけることもできます。
28.2.1. JMX の設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で jmx-management-enabled
を false
に設定することにより無効にできます。
<!-- false to disable JMX management for HornetQ --> <jmx-management-enabled>false</jmx-management-enabled>
jconsole
を使用してローカルで管理できます。
注記
run.sh
または run.bat
スクリプトで設定する必要があります。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で jmx-domain
を設定することにより、各 HornetQ サーバーに対して JMX ドメインを設定できます。
<!-- use a specific JMX domain for HornetQ MBeans --> <jmx-domain>my.org.hornetq</jmx-domain>
28.3. コア API を介した管理の使用
- 管理対象リソースの名前
- 管理操作の名前
- 管理操作のパラメーター
- 情報を抽出します。
- 管理対象リソースに対する操作を呼び出します。
- 管理メッセージの返信先アドレスに管理返信を送信します。
org.hornetq.core.client.impl.ClientMessageImpl.REPLYTO_HEADER_NAME
パラメーターにより制御されます。
ClientConsumer
は、管理返信を消費し、返信のボディーに保存された操作 (存在する場合) の結果を取得するために使用できます。移植性のために、結果は Java Serialization ではなく JSON 文字列で返されます。org.hornetq.api.core.management.ManagementHelper
は、JSON 文字列を Java オブジェクトに変換するために使用できます。
手順28.1 管理操作の呼び出し
手順 1
ClientRequestor
を作成して、メッセージを管理アドレスに送信し、返信を受け取ります。手順 2
ClientMessage
を作成します。手順 3
ヘルパークラスorg.hornetq.api.core.management.ManagementHelper
を使用してメッセージに管理プロパティーを満たします。手順 4
ClientRequestor
を使用してメッセージを送信します。手順 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 を介した管理の使用
Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management");
QueueRequestor
を作成して、管理アドレスにメッセージを送信し、返信を受け取ります。Message
を作成します。- ヘルパークラス
org.hornetq.api.jms.management.JMSManagementHelper
を使用してメッセージに管理プロパティーを満たします。 QueueRequestor
を使用してメッセージを送信します。- ヘルパークラス
org.hornetq.api.jms.management.JMSManagementHelper
を使用して管理返信から操作結果を取得します。
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 管理の設定
28.5. 管理通知
- JMX 通知
- コアメッセージ
- JMS メッセージ
28.5.1. JMX 通知
- コアリソースに関する通知の場合は
org.hornetq:module=Core,type=Server
- JMS リソースに関する通知の場合は
org.hornetq:module=JMS,type=Server
28.5.2. コアメッセージ通知
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 メッセージ通知
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. メッセージカウンター
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>
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>
// 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 リソースを管理
28.7.1. JMS キュー
28.7.2. JMS トピック
28.7.3. JMS 接続ファクトリー
第29章 セキュリティ
security-invalidation-interval
(ミリ秒単位) を設定します。デフォルト値は 10000
ms です。
警告
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
ファイルで、明示的に security-enabled
プロパティを false
に設定することによりセキュリティを完全に無効にできます。本番稼働環境にこの方法を使用することは強く推奨されません。
29.1. アドレスに対するロールベースセキュリティ
#
' と '*
' を使用してワイルドカード一致を使用したりできます。
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." で始まる任意のアドレスに適用されます。
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 ブロックからのみセキュリティ設定を取得します。
send
と consume
だけです。パーミッション createDurableQueue
、deleteDurableQueue
、createNonDurableQueue
、deleteNonDurableQueue
は他の security-setting ブロックから継承されません。
29.2. Secure Sockets Layer (SSL) トランスポート
29.3. 基本的なユーザークレデンシャル
hornetq-users.properties
および hornetq-users.roles
ファイルから読み取るセキュリティーマネージャー実装が同梱されます。これら両方のファイルは実行するプロファイル内の /conf/props/
ディレクトリに存在します。
例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
29.4. セキュリティーマネージャーの変更
hornetq-jboss-beans.xml
を編集し、HornetQSecurityManager
Bean のクラスを変更することによって別のセキュリティーマネージャーを指定できます。
org.hornetq.spi.core.security.HornetQSecurityManager
インターフェースを実装し、ファイル hornetq-jboss-beans.xml
で実装のクラス名を指定することにより、独自の実装を記述することもできます。
29.5. JAAS セキュリティーマネージャー
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>
- ConfigurationName
- JAAS が使用する必要がある
LoginModule
実装の名前 - Configuration
- JAAS により使用される
Configuration
実装 - CallbackHandler
- ユーザー対話が必要な場合に使用する
CallbackHandler
実装
29.6. HornetQ セキュリティーマネージャー
org.hornetq.integration.jboss.security.JBossASSecurityManager
です。
JBossASSecurityManager
の設定方法の例は JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jboss-beans.xml
で説明されています。
29.6.1. クライアントログインの設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jboss-beans.xml
で allowClientLogin プロパティーを true
(デフォルト値は false
) に変更することによりメッセージを送信または消費する場合に これらの設定を使用します。これにより、HornetQ 認証は省略され、提供されたセキュリティーコンテキストが伝播されます。
allowClientLogin
の他に、authoriseOnClientLogin
を true に設定します。
29.7. クラスタリングのためにユーザー名/パスワードを変更
第30章 アプリケーションサーバー統合と Java EE
30.1. Message-Driven Bean の設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar/META-INF/ra.xml
ファイルの JCA アダプターで設定されます。デフォルトでは、これは、アプリケーションサーバー内で実行されている HornetQ のインスタンスから InVM コネクターを使用してメッセージを消費するゆ設定されます。設定パラメーターを調整する必要がある場合、パラメーターの詳細は 「JCA アダプターの設定」 に記載されています。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/jms-ds.xml
データソースファイルは、<rar-name> ディレクティブを使用して ra.xml
ファイルの宛先および宛先タイプ設定情報をリンクします。
30.1.1. Container-Managed Transaction の使用
@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 トランザクションをサポートせず、トランザクションを作成すべきでないことをコンテナに伝えます。
MessageDrivenContext
の setRollbackOnly
を呼び出すことにより、トランザクションをロールバックする必要があることをコンテナに通知することができます。このコードは以下のようになります。
@Resource MessageDrivenContextContext ctx; public void onMessage(Message message) { try { //something here fails } catch (Exception e) { ctx.setRollbackOnly(); } }
@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 の使用
@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) }
acknowledgeMode
プロパティーで指定された承認モードを使用します。この Auto-acknowledge
と Dups-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 でのメッセージセレクターの使用
@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 の高可用性
重要
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で設定されていることを確認します。<clustered> ディレクティブが適切に指定されていない場合に、アクティベーションプロパティーにより、HornetQException
がスローされます。クラスタリングの詳細については、36章クラスター を参照してください。
activationConfig
ブロックに追加して MDB が HA 環境と互換性を持つようにします。
activationConfig = { @ActivationConfigProperty (propertyName = "hA", propertyValue = "true"), }
30.2. Java EE コンポーネント内からメッセージを送信
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/jms-ds.xml
ファイルで設定され、java:/JmsXA
に対してマッピングされます。
@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) { } } } } }
30.3. MDB およびコンシューマープールサイズ
ejb3-interceptors-aop.xml
ファイル内の MaxPoolSize
パラメーターが、作成されるセッションまたはコンシューマーの数に影響を持たないことを理解することが重要です。これは、リソースアダプター実装がアプリケーションサーバー 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 アダプターの設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar
アーカイブでデプロイされます。アダプターの設定は、META-INF/ra.xml
下のこのアーカイブにあります。
30.4.1. JCA グローバルプロパティー
resourceadapter-class
であり、変更しないでください。これは、HornetQ リソースアダプタークラスです。
注記
reconnectAttempts
を除いて、デフォルト値を使用します。これは、接続が接続障害時に再接続を無限に行うことを意味します。これは、InVM コネクターが失敗できない場合に、アダプターがリモートサーバーに接続するよう設定された場合のみ使用されます。
プロパティー名 | プロパティータイプ | プロパティーの説明 |
---|---|---|
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 アウトバウンド設定
*-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
設定ファイルでこれらをオーバーライドします。ここでは、接続ファクトリーに関係するいずれかの要素をオーバーライドできます。
プロパティー名 | プロパティータイプ | プロパティーの説明 |
---|---|---|
SessionDefaultType | 文字列 | デフォルトのセッションタイプ |
UseTryLock | 整数 | 指定された秒数の間、ロックを取得しようとします。0 以下の場合、この機能は無効になります。 |
30.4.3. JCA インバウンド設定
プロパティー名 | プロパティータイプ | プロパティーの説明 |
---|---|---|
定義 | 文字列 | 宛先の JNDI 名 |
DestinationType | 文字列 | 宛先のタイプ。javax.jms.Queue または javax.jms.Topic (デフォルト値は javax.jms.Queue) のいずれかになります。 |
AcknowledgeMode | 文字列 | 承認モード。Auto-acknowledge または Dups-ok-acknowledge (デフォルト値は Auto-acknowledge) のいずれかになります。AUTO_ACKNOWLEDGE と DUPS_OK_ACKNOWLEDGE は許容値です。 |
MaxSession | 整数 | このインバウンド設定により作成されたセッションの最大数 (デフォルト値は 15) |
MessageSelector | 文字列 | コンシューマーのメッセージセレクター |
SubscriptionDurability | 文字列 | サブスクリプションのタイプ。Durable または NonDurable のいずれかになります。 |
SubscriptionName | 文字列 | サブスクリプションの名前 |
TransactionTimeout | Long | トランザクションタイムアウト (ミリ秒単位。デフォルト値は 0 であり、トランザクションはタイムアウトしません) |
UseJNDI | ブール値 | 宛先をルックアップするために JNDI を使用するかどうか (デフォルト値は true) |
30.4.4. 高可用性 JNDI (HA-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);
30.4.5. XA 復元
30.4.5.1. XA 復元設定
JBOSS_DIST/jboss-as/server/PROFILE/conf/jbossts-properties.xml
の jta
セクションに追加する必要があります。
<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章トランスポートの設定 を参照してください)。
注記
JBOSS_DIST/jboss-as/server/PROFILE/conf/jbossts-properties.xml
で指定されたコネクターに対応する有効なアクセプターを持つ必要があります。
30.4.5.2. 設定
<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"/>
<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"/>
第31章 JMS ブリッジ
重要
JBOSS_DIST/jboss-as/server/PROFILE/deploy
にある Bean 設定ファイル (jms-bridge-jboss-beans.xml
) を使用して JBoss Microcontainer によってデプロイされます。
例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 ブリッジパラメーター
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. ソースおよびターゲット接続ファクトリー
org.hornetq.jms.bridge.ConnectionFactoryFactory
インターフェースを実装します。
31.3. ソースおよびターゲット宛先ファクトリー
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
XAConnectionFactory
実装である必要があります。
注記
DUPLICATES_OK
モードを設定し、宛先で重複メッセージを確認し、破棄することによって提供できます。この方法は、ONCE_AND_ONLY_ONCE
モードを使用した場合よりも信頼できませんが、代替手段として役に立ちます。
31.4.4. タイムアウトおよび JMS ブリッジ
Failure Retry Interval
ミリ秒ごとにMax Retries
の回数、再接続しようとします。
jnp.timeout
と jnp.sotimeout
を設定します。jnp.timeout
は初期接続のタイムアウトを設定し、jnp.sotimeout
はソケットの読み取りタイムアウトを設定します。
注記
第32章 クライアントの再接続とセッションの再割り当て
32.1. 100% の透過セッションの再割り当て
connection-ttl
の期限が切れない限りサーバーに存在します (connection-ttl
の詳細については、15章使用済みの接続の検出 を参照してください)。
ConfirmationWindowSize
パラメータ (通常は JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar/META-INF/ra.xml
ファイルで設定されます) によってバッファのサイズがバイト単位で定義されます。サーバーはコマンドの ConfirmationWindowSize
バイトを受信し、処理すると、コマンド情報をクライアントに送信し返します。次に、クライアントは確認されたコマンドをバッファから削除できます。
ConfirmationWindowSize
を -1
(デフォルト値) に設定すると、バッファリングが無効になり、再接続が行われなくなり、代わりに再割り当てが強制的に実行されます。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/jms-ra.rar/META-INF/ra.xml
ファイルの ConfirmationWindowSize
パラメータをコメント解除します。JNDI ではなく JMS を使用している場合は、適切な setter メソッドを使用して HornetQConnectionFactory
インスタンス上で直接これらの値を設定します。Core を使用している場合は、適切な setter メソッドを使用して ClientSessionFactory
インスタンスで直接これらの値を設定できます。
32.2. セッションの再接続
32.3. 再接続/再割り当て属性の設定
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
です。
HornetQConnectionFactory
で適切な setter メソッドを使用してパラメータを指定できます。
ClientSessionFactory
インスタンスを直接インスタンス化している場合は、作成直後に ClientSessionFactory
で適切な setter メソッドを使用してパラメータを指定することもできます。
ExceptionListener
または SessionFailureListener
インスタンスが呼び出されます。
注記
ExceptionListener
または Core SessionFailureListener
インスタンスは、クライアントの再接続または再割り当てが行われたときに呼び出されます。
第33章 メッセージフローの迂回と分割
Transformer
を適用するために設定することもできます。指定された場合、迂回されたすべてのメッセージをこの Transformer
により変換できます。
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'
を持つメッセージだけが迂回されるよう フィルター文字列
が指定されます。他のすべてのメッセージは通常のアドレスにルーティングされ続けます。フィルター文字列はオプションです。指定されない場合は、すべてのメッセージが迂回されます。
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章 コアブリッジ
注記
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
- これは、コンシューマーをブリッジするローカルキューの一意の名前であり、必須パラメーターです。キューは、起動時にブリッジがインスタンス化されるまでにすでに存在している必要があります。
注記
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-interval
が1000
ms に設定され、retry-interval-multiplier
が2.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
以下に指定し、メッセージのフローが消失しないようにすることが重要です。
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-shutdown
がtrue
に設定された場合は、ライブサーバーが正常にシャットダウンされたときにこのコネクターにフェイルオーバーしようとします。
user
- このオプションパラメーターは、リモートサーバーへのブリッジ接続を作成するときに使用するユーザー名を決定します。指定されない場合は、
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
のcluster-user
で指定されたデフォルトのクラスターユーザーが使用されます。 password
- このオプションパラメーターは、リモートサーバーへのブリッジ接続を作成するときに使用するパスワードを決定します。指定されない場合は、
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
のcluster-password
で指定されたデフォルトのクラスターパスワードが使用されます。
第35章 重複メッセージ検出
35.1. メッセージの送信に重複検出を使用
注記
org.hornetq.api.core.HDR_DUPLICATE_DETECTION_ID
の値 (_HQ_DUPL_ID
) です。
byte[]
または SimpleString
(コア API を使用する場合) のいずれかです。JMS を使用している場合は、String
である必要があり、その値は一意である必要があります。一意の ID を生成する簡単な方法は UUID を生成することです。
... 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); ...
... 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
です。
注記
35.3. 重複検出およびブリッジ
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
でブリッジを設定するときに use-duplicate-detection
を true
に設定します。
true
です。
35.4. 重複検出およびクラスター接続
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
でクラスター接続を設定するときに use-duplicate-detection
を true
に設定します。
true
です。
35.5. 重複検出およびページング
第36章 クラスター
36.1. クラスターの概要
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
の clustered
要素を true
(デフォルト値は false
) に設定する必要があります。
重要
/hornetq
ディレクトリにすでに含まれるプロファイルに対してクラスタリングを有効にする必要があります (Minimal
と Web
を除くすべてのプロファイル)。/hornetq
ディレクトリに含まれないプロファイルには、クラスターをサポートする適切なネイティブコンポーネントが含まれません。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で他のノードへのクラスター接続を宣言する各ノードによって形成されます。ノードが別のノードに対するクラスター接続を形成する場合は、内部的にそのノードと他のノード間のコアブリッジ (34章コアブリッジ を参照) 接続が作成され、この処理が背後で透過的に行われます。各ノードに対して明示的なブリッジを宣言する必要はありません。これらのクラスター接続を使用すると、負荷を分散するためにクラスターのノード間でメッセージを移動できます。
警告
36.2. サーバー検出
- メッセージングクライアント。メッセージングクライアントは、ある時点で稼動しているクラスター内のサーバーを認識せずにクラスターのサーバーに接続できます。
- 他のサーバー。クラスター内のサーバーは、クラスター内の他のすべてのサーバーについて事前に認識せずにお互いのクラスター接続を作成できます。
36.2.1. ブロードキャストグループ
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.0
〜239.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. 検出グループ
- クラスタ接続。接続を確立する必要があるクラスター内の他のサーバーについて認識できます。
- メッセージングクライアント。接続できるクラスター内のサーバーを検出できます。
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. クライアントサイドの検出グループ
36.2.4.1. JMS を使用したクライアント検出の設定
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
で定義された検出グループの名前を指定します。
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()
を使用して接続ファクトリーで直接設定できます (デフォルト値を変更する場合)。
setDiscoveryInitialWaitTimeout()
を使用して接続ファクトリーで設定できる他のパラメータもあります。作成後にすぐに接続ファクトリーを使用する場合は、クラスター内のすべてのノードからブロードキャストを受け取るのに十分な時間がないことがあります。最初に使用する場合、接続ファクトリーによって、最初の接続を作成する前に十分に長い時間を待つようになります。このパラメータのデフォルト値は、10000
ミリ秒です。
36.2.4.2. コアを使用したクライアント検出の設定
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()
を使用してセッションファクトリーで直接設定できます (デフォルト値を変更する場合)。
setDiscoveryInitialWaitTimeout()
を使用してセッションファクトリーで設定できる他のパラメータもあります。作成後にすぐにセッションファクトリーを使用する場合は、クラスター内のすべてのノードからブロードキャストを受け取るのに十分な時間がないことがあります。最初に使用する場合、セッションファクトリーによって、最初のセッションを作成する前に十分に長い時間を待つようになります。このパラメータのデフォルト値は、10000
ミリ秒です。
36.3. サーバーサイドメッセージロードバランシング
OrderQueue
と呼ばれるキューがクラスターの各ノードにデプロイされます。
OrderQueue
にすべて格納され、ノード A、Pa に接続された順序プロセッサークライアントによって消費されます。
OrderQueue
インスタンスに格納される代わりに、クラスターのすべてのノード間でラウンドロビン形式で分散されます。メッセージは受け取り側のノードからクラスターの他のノードに転送されます。これは、サーバーサイドで行われ、クライアントはノード A に対する単一の接続を保持します。
36.3.1. クラスター接続の設定
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
の cluster-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. クラスターユーザークレデンシャル
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>
警告
36.4. クライアントサイドロードバランシング
- ラウンドロビン。このポリシーを使用すると、最初のノードがランダムに選択され、後続の各ノードが同じ順序で順番に選択されます。たとえば、ノードは 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
を実装することにより、独自のポリシーを実装できます。
org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy
が使用されます。
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 接続ファクトリーがデプロイされます。
HornetQConnectionFactory
で setter を使用してロードバランシングポリシーを設定できます。
ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactory(...); jmsConnectionFactory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
ClientSessionFactory
インスタンスで直接ロードバランシングポリシーを設定できます。
ClientSessionFactory factory = HornetQClient.createClientSessionFactory(...); factory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
- サーバーを明示的に指定
- 検出の使用。
36.5. クラスターのメンバーを明示的に指定
36.5.1. クライアントサイドでのサーバーのリストの指定
36.5.1.1. JMS を使用してサーバーのリストを指定
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章トランスポートの設定 を参照してください。
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」 で詳細に説明)。
コネクターの定義
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>
クラスター接続の定義
<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>
結果
クラスターは、明示的なサーバー名を使用してサーバー検出に必要なディレクティブで定義されます。
36.6. メッセージ再分散
forward-when-no-consumers
が false の場合、メッセージは一致するコンシューマーを持たないノードに転送されません。これによって、メッセージを消費するコンシューマーを持たないキューにメッセージが到着しないようになりますが、解決されない状況が発生します。メッセージがノードに送信された後にキューのコンシューマーがクローズした場合は何が起こりますか? キューにコンシューマーがない場合は、メッセージが消費されず、枯渇の状況が発生します。
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" で始まるアドレスにバインドされるキューに対して 0
の redistribution-delay
を設定します。すべての JMS キュートトピックサブスクリプションは "jms" で始まるアドレスにバインドされるため、上記のコード例により、すべての JMS キューとトピックサブスクリプションがすぐに再分散されます (遅延なし)。
match
は完全一致、または HornetQ ワイルドカード構文に準拠する文字列になります (11章HornetQ ワイルドカード構文について で説明)。
redistribution-delay
は、メッセージがキューから、一致するコンシューマーを持たないクラスターの他のノードに再分散する前に、最後のコンシューマーがキューでクローズされるまでの遅延 (ミリ秒単位) を定義します。ゼロの遅延は、メッセージがすぐに再分散されることを意味します。値が -1
の場合は、メッセージが再分散されません。
36.7. クラスタートポロジー
36.7.1. シンメトリッククラスター
max-hops
が 1
に設定されたクラスター接続を定義します。通常、クラスター接続は、接続すべきクラスター内の他のサーバーを認識するためにサーバー検出を使用します。ただし、たとえば、UDP がネットワークで利用できない場合に、クラスター接続で各ターゲットサーバーを明示的に定義することができます。
36.7.2. チェーンクラスター
max-hops
を 2
に設定します。値が 2
の場合は、ノード C に存在するキューとコンシューマーに関する情報が、ノード C からノード B、そしてノード A に伝播されます。ノード A は、メッセージが到着したときにノード B にメッセージ分散することを認識しています。ノード B にコンシューマー自体がない場合であっても、1 ホップ離れたところにコンシューマーを持つノード C があることを認識しています。
第37章 高可用性およびフェイルオーバー
警告
37.1. ライブ - バックアップペア
37.1.1. HA モード
注記
37.1.1.1. データレプリケーション
37.2. フェイルオーバーモード
- 自動クライアントフェイルオーバー
- アプリケーションレベルのクライアントフェイルオーバー
37.2.1. 自動クライアントフェイルオーバー
client-failure-check-period
で指定された時間内にサーバーからパケットを受信しない場合に接続失敗を検出します。クライアントが適切な時間内にデータを受け取らない場合は、接続が失敗したと見なされ、フェイルオーバーが試行されます。
HornetQConnectionFactory
(JMS を使用している場合)、 JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
ファイル (接続ファクトリーを定義する場合)、または ClientSessionFactoryImpl
(プロパティーを直接設定してコアを使用する場合) でプロパティー FailoverOnServerShutdown
を true に設定します。このプロパティーのデフォルト値は false
です。つまり、デフォルトでは、ライブサーバーが正常にシャットダウンされた場合に、HornetQ クライアントはバックアップサーバーにフェイルオーバーされません。
注記
FailoverOnServerShutdown
を true に設定します。
ClientSessionFactoryImpl
、または HornetQConnectionFactory
でプロパティー FailoverOnInitialConnection
、またはfailover-on-initial-connection
を設定します。このパラメーターのデフォルト値は false
です。
注記
37.2.1.1. フェイルオーバー中のブロッキングコールの処理
javax.jms.JMSException
(JMS を使用している場合) または HornetQException
(エラーコード HornetQException.UNBLOCKED
) をスローすることにより、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 を使用している場合) がスローされます。
注記
37.2.1.3. 非トランザクションセッションでのフェイルオーバーの処理
37.2.2. 接続障害の検出
java.jms.ExceptionListener
) を非同期的に検出する標準的なメカニズムを提供します。ExceptionListener の詳細については、Oracle javax.jms Javadoc を参照してください。
org.hornet.core.client.SessionFailureListener
という形で提供します。
ExceptionListener
またはコア SessionFailureListener
インスタンスは、接続が正常にフェイルオーバーされたか、最接続されたかに関係なく、接続障害の発生時に常に HornetQ によって呼び出されます。
37.2.3. アプリケーションレベルフェイルオーバー
ExceptionListener
クラスを設定します。ExceptionListener
は、接続障害が検出されたときに HornetQ により呼び出されます。ExceptionListener
で、古い JMS 接続を閉じ、新しい接続ファクトリーインスタンスを JNDI からルックアップし、新しい接続を作成します。この場合は、新しい接続ファクトリーが異なるサーバーからルックアップされるよう HA-JNDI を使用できます。
ClientSession
インスタンスで SessionFailureListener
を設定します。
37.3. フェンシング
第38章 共存および専用の対称クラスター設定
HornetQ インスタンスの指定されたグループにフェイルオーバーするよう設定された、JBoss Enterprise Application Platform で実行されている HornetQ のインスタンス。
- 共存
- 同時に実行されている 1 つのライブと少なくとも 1 つのバックアップサーバーが含まれているトポロジー。各バックアップノードは、別の JBoss Enterprise Application Platform インスタンスのライブノードに属します。
- 専用
- 1 つのライブと、少なくとも 1 つのバックアップサーバーが含まれるトポロジー。一度に 1 つのサーバーだけを実行できます。
38.1. 共存対称ライブおよびバックアップクラスター
注記
$JBOSS_HOME/extras/hornetq/resources/examples/symmetric-cluster-with-backups-colocated
にあります)。このディレクトリ内の readme
は、サンプルを実行するのに必要な基本的な設定を提供します。
例38.1 2 つのインスタンス設定
注記
例38.2 3 インスタンス設定
38.1.1. 共存ライブサーバー
重要
手順38.1 ライブサーバープロファイルの作成
production
プロファイルのコピー作成して、ライブサーバー設定をカスタマイズする必要があります。
重要
$JBOSS_HOME/server/
に移動します。production
プロファイルをコピーして、HornetQ_Colocated
に名前を変更します。
手順38.2 共有ストアとジャーナリングの設定
$JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq/
に移動します。- オープンします。
- <shared-store> element 要素を <configuration> 要素の子として追加します。
<shared-store>true</shared-store>
- バインディング、ジャーナル、および大きなメッセージパスの場所がライブバックアップグループがアクセスできる場所に設定されていることを確認します。例で示されたように絶対パスを設定したり、設定ファイルに存在する 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 をサーバーインスタンスに適切な名前に変更します。
手順38.3 JMS クライアントの正常シャットダウンの設定
$JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq/
に移動します。hornetq-configuration.xml
を開きます。- 手順38.2「共有ストアとジャーナリングの設定」 で記述されたようにジャーナルディレクトリ設定付近の領域に <fail-over-on-shutdown> 要素を指定します。
<failover-on-shutdown>true</failover-on-shutdown>
注記
hornetq-configuration.xml
ファイルに要素を置く場所の制限はありません。ただし、ファイルの上部に詳細レベルが低い設定があると、見つけやすくなります。 - ファイルを保存し、閉じます。
注記
forceFailover
を呼び出します。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
で接続ファクトリー属性を設定することにより行われます。
手順38.4 HA 接続ファクトリーの設定
$JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq/
に移動します。hornetq-jms.xml
を開きます。- 以下で示されたように以下の属性と値を追加します。
- <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>
- 指定されたファイルに以下のいずれかの設定ブロックを追加することにより、マスターノードとバックアップノードの両方で新しいキューを定義します。
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-beans.xml
と hornetq-configuration.xml
設定ファイルのみ必要です。JMS コンポーネントは、バックアップサーバーがライブになったときに共有ジャーナルから作成されます (手順38.2「共有ストアとジャーナリングの設定」 で設定されます)。
手順38.5 バックアップサーバーの作成
重要
$JBOSS_HOME/server/HornetQ_Colocated/deploy/
に移動します。hornetq-backup1
という名前の新しいディレクトリを作成します。このディレクトリに移動します。- テキストエディターを開き、
hornetq-jboss-beans.xml
という名前の新しいファイルをhornetq-backup1
ディレクトリに作成します。 - 以下の設定を
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>
- ファイルを保存し、閉じます。
hornetq-jboss-beans.xml
ファイルには、詳細に調べる価値のある設定が含まれます。BackupConfiguration Bean は、hornetq-configuration.xml
の設定を取得するよう設定されます。このファイルは、手順38.6「バックアップサーバー設定ファイルの作成」 の手順で作成されます。
注記
手順38.6 バックアップサーバー設定ファイルの作成
$JBOSS_HOME/server/HornetQ_Colocated/deploy/hornetq-backup1
に移動します。- テキストエディターを開き、
hornetq-configuration.xml
という名前の新しいファイルをhornetq-backup1
ディレクトリに作成します。 - 以下の設定を
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>
- ファイルを保存し、閉じます。
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 番目のサーバーインスタンスに対して設定を作成
に移動します。JBOSS_HOME
/server/HornetQ_Colocated
ディレクトリをコピーし、HornetQ_Colocated_Second
に名前を変更します。JBOSS_HOME/server/HornetQ_Colocated_Second/hornetq-backup1/
の名前をJBOSS_HOME/server/HornetQ_Colocated_Second/hornetq-backup-serverA/
に変更します。JBOSS_HOME/server/HornetQ_Colocated_Second/hornetq/hornetq-configuration.xml
を開きます。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> に変更します。JBOSS_HOME/server/HornetQ_Colocated_Second/hornetq-backup-serverA/hornetq-configuration.xml
を開きます。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_HOME/extras/hornetq/resources/examples/cluster-with-dedicated-backup
に存在します。
例38.3 単一インスタンス、純粋な JMS、専用対称設定
- 専用 JCA サーバー (例38.4「専用 JCA サーバー」 を参照)
- リモート JCA サーバー (例38.5「リモート JCA サーバー」 を参照)。
38.2.1. 専用 JCA ライブサーバー
例38.4 専用 JCA サーバー
手順38.7 専用ライブサーバープロファイルの作成
重要
production
プロファイルのコピー作成して、ライブサーバー設定をカスタマイズする必要があります。
重要
$JBOSS_HOME/server/
に移動します。production
プロファイルをコピーして、HornetQ_Dedicated
に名前を変更します。
手順38.8 共有ストアとジャーナリングの設定
$JBOSS_HOME/server/HornetQ_Dedicated/deploy/hornetq/
に移動します。hornetq-configuration.xml
を開きます。- <shared-store> element 要素を <configuration> 要素の子として追加します。
<shared-store>true</shared-store>
- バインディング、ジャーナル、および大きなメッセージパスの場所がライブバックアップグループがアクセスできる場所に設定されていることを確認します。例で示されたように絶対パスを設定したり、設定ファイルに存在する 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 クライアントの正常シャットダウンの設定
$JBOSS_HOME/server/HornetQ_Dedicated/deploy/hornetq/
に移動します。hornetq-configuration.xml
を開きます。- 手順38.2「共有ストアとジャーナリングの設定」 で記述されたようにジャーナルディレクトリ設定付近の領域に <fail over-on-shutdown> 要素を指定します。
<failover-on-shutdown>true</failover-on-shutdown>
注記
hornetq-configuration.xml
ファイルに要素を置く場所の制限はありません。ただし、ファイルの上部に詳細レベルが低い設定があると、見つけやすくなります。 - ファイルを保存し、閉じます。
手順38.10 HA 接続ファクトリーの設定
$JBOSS_HOME/server/HornetQ_Dedicated/deploy/hornetq/
に移動します。hornetq-jms.xml
を開きます。- 以下で示されたように以下の属性と値を追加します。
- <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>
- 指定されたファイルに以下のいずれかの設定ブロックを追加することにより、マスターノードとバックアップノードの両方で新しいキューを定義します。
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 専用バックアップサーバーの設定
- HornetQ ライブサーバー (「専用 JCA ライブサーバー」 で記載された手順に従って設定)
- ライブサーバーに対する個別のサーバーインスタンスにインストールされた、適切に設定された JBoss Enterprise Application Platform インスタンス。
- プラットフォームインスタンスにインストールされた HornetQ。
- バックアップサーバーで、コマンドラインを使用して
/extras/hornetq/
に移動します。 sh ./switch.sh -Dbackup=true
を実行します。スクリプトが実行され、production-backup
サーバープロファイルが$JBOSS_HOME/server/
に作成されます。production-backup
サーバープロファイルをコピーして、HornetQ_Dedicated_Backup
に名前を変更します。$JBOSS_HOME/server/HornetQ_Dedicated_Backup/hornetq/hornetq-configuration.xml
を開きます。- <shared-store>true</shared-store> 要素を子要素として <configuration> 要素に追加します。
- 以下の値に一致するようデータディレクトリの場所を変更します。
- <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.2.3. 専用リモートサーバー
例38.5 リモート JCA サーバー
手順38.12 JCA 接続ファクトリーの設定
production
サーバープロファイルをコピーして、EAP2
に名前を変更します。- EAP2 インスタンスで、
$JBOSS_HOME/server/EAP2/deploy/hornetq/jms-ds.xml
に移動します。 - デフォルトの
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>
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>
- テキストエディターで
$JBOSS_HOME/server/EAP2/deploy/jms-ra.rar/META-INF/ra.xml
を開きます。 ra.xml
で、<resourceadapter> を検索します。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 ネイティブライブラリー
libaio
は、Linux カーネルプロジェクトの一部として開発されたライブラリーです。libaio
では、書き込みが、非同期で処理されるオペレーティングシステムに送信されます。書き込みが処理されたときに、オペレーティングシステムはコードをコールバックします。
- libHornetQAIO32.so - x86 32 ビット
- libHornetQAIO64.so - x86 64 ビット
第40章 スレッド管理
40.1. サーバーサイドスレッド管理
nio-remoting-threads
を指定してスレッド数を設定します。この詳細については、14章トランスポートの設定 を参照してください。
40.1.1. サーバースケジュールスレッドプール
java.util.concurrent.ScheduledThreadPoolExecutor
インスタンスに対してマッピングされます。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で scheduled-thread-pool-max-size
パラメーターを使用して設定されます。デフォルト値は 5
個のスレッドです。通常、このプールには少数のスレッドで十分です。
40.1.2. 汎用サーバースレッドプール
java.util.concurrent.ThreadPoolExecutor
インスタンスに対してマッピングされます。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
で thread-pool-max-size
パラメーターを使用して設定されます。
-1
の値が指定された場合、スレッドプールには上限がなく、要求を満たすのに十分なスレッドがないときに新しいスレッドが要求に応じて作成されます。後でアクティビティがなくなると、スレッドはタイムアウトになり、閉じられます。
n
の値 (n
はゼロ以外の正の整数) が使用された場合は、スレッドプールがバインドされることを意味します。さらに要求を受け取り、プールに空きスレッドがなく、プールがいっぱいの場合は、スレッドが利用可能になるまで要求がブロックされます。バインドされたスレッドプールは、上限が低く設定された場合にデッドロックの状況になることがあるため、注意して使用することが推奨されます。
thread-pool-max-size
のデフォルト値は 30
です。
40.1.3. 期限切れリーパースレッド
40.1.4. 非同期 IO
40.2. クライアントサイドスレッド管理
5
スレッドであり、汎用スレッドプールはバインドされない最大サイズを持ちます。
ClientSessionFactory
インスタンスがこれらのスタティックプールを使用せず、独自のスケジュールおよび汎用プールを維持するよう HornetQ を設定できます。ClientSessionFactory
から作成されたすべてのセッションは代わりにこれらのプールを使用します。
ClientSessionFactory
インスタンスが独自のプールを使用するよう設定するには、作成後すぐに適切なセッターメソッドを使用します。以下に例を示します。
ClientSessionFactory myFactory = HornetQClient.createClientSessionFactory(...); myFactory.setUseGlobalPools(false); myFactory.setScheduledThreadPoolMaxSize(10); myFactory.setThreadPoolMaxSize(-1);
ConnectionFactory
インスタンスを作成します。以下に例を示します。
ConnectionFactory myConnectionFactory = HornetQJMSClient.createConnectionFactory(myFactory);
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章 ロギング
注記
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
org.hornetq.core.logging.impl.JULLogDelegateFactory
- JUL を使用するデフォルト値。org.hornetq.integration.logging.Log4jLogDelegateFactory
- Log4J を使用します。
logging.properties
ファイルが提供され、java.util.logging.config.file プロパティーがクライアントの起動時に設定されるようにします。
第42章 インターセプト操作
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章 パフォーマンスチューニング
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 のチューニング
- メッセージ ID を無効にします。
MessageProducer
クラスのsetDisableMessageID()
メソッドを使用してメッセージを無効にします (必要ない場合)。これにより、メッセージのサイズが削減され、一意の ID を作成するオーバーヘッドが回避されます。 - メッセージタイムスタンプを無効にします。
MessageProducer
クラスのsetDisableMessageTimeStamp()
メソッドを使用して必要でないメッセージタイムスタンプを無効にします。 ObjectMessage
を回避します。ObjectMessage
は便利ですが、コストがかかります。ObjectMessage
のボディーは Java シリアル化を使用してバイトにシリアル化します。小さいオブジェクトの Java シリアル化形式であっても冗長になり、サーバートラフィックが増加します。また、Java シリアル化はカスタムマーシャリングテクニックと比較して低速です。他のいずれかのメッセージタイプが適切でない場合 (たとえば、ペイロードのタイプが実行時まで不明な場合) のみ、ObjectMessage
を使用します。AUTO_ACKNOWLEDGE
を回避します。AUTO_ACKNOWLEDGE
モードは、クライアントで受け取る各メッセージに対してサーバーから送信される承認を必要とします。つまり、ネットワークでトラフィックが増加します。可能な場合は、DUPS_OK_ACKNOWLEDGE
、CLIENT_ACKNOWLEDGE
、またはトランザクションセッションを使用して、1 つの承認/コミットで多くの承認をバッチ処理します。- 耐性メッセージを回避します。デフォルトでは、JMS メッセージは耐性です。実際には耐性メッセージが必要ない場合は、メッセージを非耐性に設定します。耐性メッセージの場合は、メッセージをストレージに永続化するオーバーヘッドが大幅に増加します。
- 1 つのトランザクションで多くの送信または承認をバッチ処理します。HornetQ は各送信時または承認時ではなくコミット時にネットワークラウンドトリップのみを必要とします。
43.3. 他のチューニング
- 非同期送信承認を使用します。耐性メッセージをトランザクションで送信せず、send() へのコールが返されるまでにメッセージがサーバーに到達する保証が必要な場合は、耐性メッセージを送信してブロックするよう設定せずに、非同期送信承認を使用して別のストリームで送り返す承認を取得します。この詳細については、18章送信およびコミットの保証 を参照してください。
- 事前承認モードを使用します。事前承認モードでは、メッセージがクライアントに送信される前に承認されます。
これにより、送信される承認トラフィックの量が削減されます。この詳細については、27章事前承認モード を参照してください。
- 永続化を無効にします。メッセージ永続化が必要ない場合は、
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-configuration.xml
でpersistence-enabled
を false に設定してメッセージ永続化を一括して無効にします。 - トランザクションをレイジー状態で同期します。
hornetq-configuration.xml
で、journal-sync-transactional
をfalse
に設定すると、障害発生時にトランザクションが失われることがありますが、トランザクション永続化のパフォーマンスが向上します。詳細については、18章送信およびコミットの保証 を参照してください。 - レイジー状態でトランザクションを使用せずに同期します。
hornetq-configuration.xml
で、journal-sync-non-transactional
をfalse
に設定すると、障害発生時に耐性メッセージが失われることがありますが、非トランザクション永続化のパフォーマンスが向上します。詳細については、18章送信およびコミットの保証 を参照してください。 - メッセージをブロックせずに送信します。
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
(JMS と JNDI を使用している場合) または直接 ClientSessionFactory でblock-on-durable-send
とblock-on-non-durable-send
をfalse
に設定します。したがって、メッセージを送信するごとにネットワーク全体のラウンドトリップを待つ必要がありません。詳細については、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
に存在します。
要素名 | タイプ | 説明 | デフォルト |
---|---|---|---|
バックアップ | ブール値 | 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
JBOSS_DIST/jboss-as/server/PROFILE/deploy/hornetq/hornetq-jms.xml
に存在します。
要素名 | タイプ | 説明 | デフォルト |
---|---|---|---|
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.400 | 2013-10-30 | ||
| |||
改訂 5.1.2-2 | 2012-07-18 | ||
| |||
改訂 5.1.2-108 | Tue 28 Feb 2012 | ||
|