5.5. ポストオフィスの設定

ポストオフィスは、メッセージをそのデスティネーションまたは複数のデスティネーションにルーティングします。メッセージの送信が可能なアドレスと最終的なキューの間のマッピングを管理します。例えば、JMS キューを表すアドレスでメッセージを送信すると、ポストオフィスはこのメッセージをその JMS キューにルーティングします。JMS トピックを表すアドレスでメッセージを送信すると、ポストオフィスはこのメッセージを一連のキューにルーティングします。このセットは各 JMS サブスクリプション毎に 1 つです。
また、ポストオフィスはアドレスマッピングの永続化処理も行います。
JBoss Messaging ポストオフィスはクラスター対応です。クラスターでは、完全分散の JMS キューとトピックを提供するためにポストオフィスは自動的にノード間でメッセージのルーティング (プッシュ) とプルを行います。
<database type>-persistence-service.xml ファイルでポストオフィスを設定します。例えば以下のとおりです。
<mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService"
  name="jboss.messaging:service=PostOffice"
  xmbean-dd="xmdesc/MessagingPostOffice-xmbean.xml">
      
  <depends optional-attribute-name="ServerPeer">
    jboss.messaging:service=ServerPeer
  </depends>
                
  <depends>
    jboss.jca:service=DataSourceBinding,name=DefaultDS
  </depends>
      
  <depends optional-attribute-name="TransactionManager">
    jboss:service=TransactionManager
  </depends>
      
  <!-- The name of the post office -->                  
    
  <attribute name="PostOfficeName">JMS post office</attribute>
      
  <!-- The datasource used by the post office to access it's 
       binding information -->                     
      
  <attribute name="DataSource">java:/DefaultDS</attribute>
      
  <!-- If true will attempt to create tables and indexes on 
       every start-up -->
                        
  <attribute name="CreateTablesOnStartup">true</attribute>
      
  <!-- If true then we will automatically detect and reject 
       duplicate messages sent during failover -->
      
  <attribute name="DetectDuplicates">true</attribute>
      
  <!-- The size of the id cache to use when detecting duplicate 
       messages -->
      
  <attribute name="IDCacheSize">500</attribute>
      
  <attribute name="SqlProperties">
    CREATE_POSTOFFICE_TABLE=CREATE TABLE JBM_POSTOFFICE 
      (POSTOFFICE_NAME VARCHAR(255), 
      NODE_ID INTEGER, QUEUE_NAME VARCHAR(255), COND VARCHAR(1023), 
      SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CHAR(1), 
      ALL_NODES CHAR(1), 
      PRIMARY KEY(POSTOFFICE_NAME, NODE_ID, QUEUE_NAME)) ENGINE = INNODB

    INSERT_BINDING=INSERT INTO JBM_POSTOFFICE 
      (POSTOFFICE_NAME, NODE_ID, QUEUE_NAME, COND, SELECTOR, 
       CHANNEL_ID, CLUSTERED, ALL_NODES) 
      VALUES (?, ?, ?, ?, ?, ?, ?, ?)

    DELETE_BINDING=DELETE FROM JBM_POSTOFFICE WHERE 
      POSTOFFICE_NAME=? AND NODE_ID=? AND QUEUE_NAME=?

    LOAD_BINDINGS=SELECT QUEUE_NAME, COND, SELECTOR, 
      CHANNEL_ID, CLUSTERED, ALL_NODES FROM 
   JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=?
  </attribute>
      
  <!-- This post office is clustered. If you don't want a clustered post 
       office then set to false -->
      
  <attribute name="Clustered">true</attribute>
      
  <!-- All the remaining properties only have to be specified if the post 
       office is clustered. You can safely comment them out if your post 
       office is non clustered -->
      
  <!-- The JGroups group name that the post office will use -->            
      
  <attribute name="GroupName">
    ${jboss.messaging.groupname:MessagingPostOffice}
  </attribute>
      
  <!-- Max time to wait for state to arrive when the post office 
       joins the cluster -->            
                  
  <attribute name="StateTimeout">5000</attribute>
      
  <!-- Max time to wait for a synchronous call to node members using 
       the MessageDispatcher -->            
                  
  <attribute name="CastTimeout">50000</attribute>
      
  <!-- Set this to true if you want failover of connections to occur 
       when a node is shut down -->
      
  <attribute name="FailoverOnNodeLeave">false</attribute>
      
  <!-- JGroups stack configuration for the data channel - used for sending 
       data across the cluster --> 
                   
  <!-- By default we use the TCP stack for data -->                  
  <attribute name="DataChannelConfig">
    <config>
      <TCP start_port="7900"
        loopback="true"
        recv_buf_size="20000000"
        send_buf_size="640000"
        discard_incompatible_packets="true"
        max_bundle_size="64000"
        max_bundle_timeout="30"
        use_incoming_packet_handler="true"
        use_outgoing_packet_handler="false"
        down_thread="false" up_thread="false"
        enable_bundling="false"
        use_send_queues="false"
        sock_conn_timeout="300"
        skip_suspected_members="true"/>
      <MPING timeout="4000"
        bind_to_all_interfaces="true"
        mcast_addr="${jboss.messaging.datachanneludpaddress:228.6.6.6}"
        mcast_port="${jboss.messaging.datachanneludpport:45567}"
        ip_ttl="8"
        num_initial_members="2"
        num_ping_requests="1"/>                     
      <MERGE2 max_interval="100000"
        down_thread="false" up_thread="false" min_interval="20000"/>
      <FD_SOCK down_thread="false" up_thread="false"/>            
      <VERIFY_SUSPECT timeout="1500" down_thread="false" 
       up_thread="false"/>
      <pbcast.NAKACK max_xmit_size="60000"
        use_mcast_xmit="false" gc_lag="0"
        retransmit_timeout="300,600,1200,2400,4800"
        down_thread="false" up_thread="false"
        discard_delivered_msgs="true"/>
      <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
        down_thread="false" up_thread="false"
        max_bytes="400000"/>
      <pbcast.GMS print_local_addr="true" join_timeout="3000"
        down_thread="false" up_thread="false"
        join_retry_timeout="2000" shun="false"
        view_bundling="true"/>
    </config>        
  </attribute>
      
  <!-- JGroups stack configuration to use for 
       the control channel - used for control messages -->         
              
  <!-- We use udp stack for the control channel -->
  <attribute name="ControlChannelConfig">
    <config>
      <UDP
        mcast_addr="${jboss.messaging.controlchanneludpaddress:228.7.7.7}"
        mcast_port="${jboss.messaging.controlchanneludpport:45568}"
        tos="8"
        ucast_recv_buf_size="20000000"
        ucast_send_buf_size="640000"
        mcast_recv_buf_size="25000000"
        mcast_send_buf_size="640000"
        loopback="false"
        discard_incompatible_packets="true"
        max_bundle_size="64000"
        max_bundle_timeout="30"
        use_incoming_packet_handler="true"
        use_outgoing_packet_handler="false"
        ip_ttl="2"
        down_thread="false" up_thread="false"
        enable_bundling="false"/>
      <PING timeout="2000"
        down_thread="false" up_thread="false" num_initial_members="3"/>
      <MERGE2 max_interval="100000"
        down_thread="false" up_thread="false" min_interval="20000"/>
      <FD_SOCK down_thread="false" up_thread="false"/>
      <FD timeout="10000" max_tries="5" down_thread="false" 
        up_thread="false" shun="true"/>
      <VERIFY_SUSPECT timeout="1500" down_thread="false" 
       up_thread="false"/>
      <pbcast.NAKACK max_xmit_size="60000"
        use_mcast_xmit="false" gc_lag="0"
        retransmit_timeout="300,600,1200,2400,4800"
        down_thread="false" up_thread="false"
        discard_delivered_msgs="true"/>
      <UNICAST timeout="300,600,1200,2400,3600"
        down_thread="false" up_thread="false"/>
      <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
        down_thread="false" up_thread="false"
        max_bytes="400000"/>
      <pbcast.GMS print_local_addr="true" join_timeout="3000" 
        use_flush="true" flush_timeout="3000"
        down_thread="false" up_thread="false"
        join_retry_timeout="2000" shun="false"
        view_bundling="true"/>
      <FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
      <pbcast.STATE_TRANSFER down_thread="false" up_thread="false" 
        use_flush="true" flush_timeout="3000"/>
      <pbcast.FLUSH down_thread="false" up_thread="false" timeout="20000" 
        auto_flush_conf="false"/>
    </config>
  </attribute>    
      
</mbean>

5.5.1. MessagingPostOffice 属性

MessagingPostOffice サービス属性について以下の一覧で説明しています。
DataSource
ポストオフィスがマッピングデータの永続化に使用すべきデータソース
SQLProperties
特定のデーターベースの DDL と DML を指定します。特定の DDL や DML ステートメントがオーバーライドされていない場合は、デフォルトの Hypersonic 設定がそのステートメントに使用されます。
CreateTablesOnStartup
ポストオフィスが起動時にテーブル(およびインデックス)の作成を試行するようにするには、これを true に設定します。テーブルまたはインデックスが既に存在している場合は、SQLException は JDBC ドライバーによって送出されますが、永続マネージャーはこれを無視するためその動作は継続します。
デフォルトでは、CreateTablesOnStartup 属性の値は true に設定されています。
DetectDuplicates
ポストオフィスが、サーバー障害の後、別ノードから送信の再試行が行われた際に送信されたなどで、重複したメッセージを検出するようにしたい場合は、これを true に設定します。
デフォルトでは、DetectDuplicates 属性の値は true に設定されています。
IDCacheSize
重複検出が有効になっている場合 (DetectDuplicates 参照)、サーバーは最後から n 個の送信メッセージ ID を記憶し、障害が起こった後にメッセージが重複して送信されないようにします。n の値は、この属性で決定します。
デフォルトでは、IDCacheSize 属性は 500 に設定されています。
PostOfficeName
ポストオフィスの名前
NodeIDView
これは、クラスター内のすべてのノードのノード ID を 1 セットとして返します。
GroupName
クラスター内で同じグループ名を持つ全ポストオフィスで1つのクラスターを作成します。クラスターを形成したいと考えるクラスターにあるノードすべてと、グループ名が一致するようにしてください。
Clustered
True に設定している場合、ポストオフィスはクラスター1つに参加し、分散したキュートトピックを形成します。false に設定すると、クラスターには参加せず、クラスター関連の属性はすべて無視されます。
StateTimeout
ノードが既存のクラスターに参加する際にグループのステータスが到着になるまで待機する最大時間
デフォルト値は、5000 ミリ秒です。
CastTimeout
返信キャストメッセージの同期まで待機する最大時間
デフォルト値は、5000 ミリ秒です。
FailoverOnNodeLeave
ノードがクリーンにシャットダウンした場合、ノードに保存されているメッセージがどのように再配信されるかを指定します。デフォルト値は false になっています。true の場合は、サーバーノードがクリーンにシャットダウンされる (ターミナルでCtrl+C を押す) と、そのノードに保存されている全メッセージが同じクラスターにある別のノードに移動されます。

重要

クリーンシャットダウンされたノードに元々接続されていたクライアントは自動的にクラスター内でフェールオーバーしたノードに再接続されません。クライアントは、メッセージのフェールオーバーが発生すると例外を返します。
MaxConcurrentReplications
返信が戻ってこないようにするまでに、同時複製リクエストを最大で作成できる数。これにより、JGroups が膨大にならないようにします。これは変更しないほうが良いでしょう。
デフォルト値は 50 となっています。
ControlChannelConfig
JBoss Messaging は全グループの管理に JGroups を使用します。これにはコントロールチャンネルの JGroups スタック設定が含まれています。
コントロールチャンネルを使い、クラスター内の別のノードからリクエストを送信/応答を受信します。
JGroups 設定の詳細は、標準の JGroups 設定であるため、ここでは説明しません。JGroups の詳細情報については、JGroups リリース文書か、オンライン (http://www.jgroups.org あるいは http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups) で入手していただけます。
DataChannelConfig
JBoss Messaging は全グループの管理に JGroups を使用します。これにはデータチャンネルの JGroups スタック設定が含まれています。
データチャンネルを使い、クラスター内の別のノードからメッセージを送信/応答を受信し、セッションデータをレプリケートします。
JGroups 設定の詳細は、標準の JGroups 設定であるため、ここでは説明しません。JGroups の詳細情報については、JGroups リリース文書か、オンライン (http://www.jgroups.org あるいは http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups) で入手していただけます。
Database Connection Retry パラメーターは、接続失敗が検出された場合接続を再確立するか、何度再接続を試みるか、接続再試行の間隔はどの程度かを制御します。
RetryOnConnectionFailure
MBean がデータベースへの再接続を試行すべきか指定します。デフォルト値は false です。
MaxRetry
DataSource 接続失敗の上限を指定します。デフォルトは 25 です。パラメーターを -1 に設定し、「Retry forever」モードを有効にします。このパラメーターは RetryOnConnectionFailuretrue に設定されている場合有効です。

重要

クラスター化されたデスティネーションからメッセージをコンシュームするクライアントは、クローズされると応答しなくなります。これは、ノードの MaxRetry 値が-1 に設定されている場合に発生し、データベースへの接続が失われます。この問題を回避するには、ノードのMaxRetry パラメーターを-1よりも大きな値に設定してください。 [database]-persistence-service.xmlファイルにある PersistenceManagerPostOfficeJMSUserManager MBeanの属性値を設定してください。
RetryInterval
連続する再試行の間隔を指定します。デフォルトは、1000 (ミリ秒) となっています。このパラメーターは、RetryOnConnectionFailuretrue に設定されている場合に有効です。
安定性を保ちつつもノードが数秒応答しなくなった場合 (例:マイナーなネットワーク障害)、以前のフェールオーバーの動作によりノードがクラスターを退出したことを報告します。MessagePostOffice bean の以下のパラメーターを指定することでこのシナリオを回避できます。以下のパラメーターは、MessagePostOffice がクラスターの timestamp テーブルにアクセスできるようにします。この timestamp テーブルを使いより正確にノードの状態を判断します。

重要

timestamp テーブルのパラメーターは、MessagingClusterHealthMBean MBean と連携して使う必要があります。ServerPeer MBean にこの MBean をデプロイします。対応のパラメーターと操作に関する包括的な説明については、「ServerPeer の設定」 を参照してください。
KeepOldFailoverMode
timestamp テーブルのフェールオーバーモードを使うかどうかを指定します。デフォルトは true (新規のフェールオーバー動作を無効化) となっています。
NodeStateRefreshInterval
クラスターがノードを無効とするまでに、ノードによるタイムスタンプ更新の最大待機時間 (ミリ秒) を指定します。デフォルトは 30000 です (30 秒)。