|
|
マルチキャストを使用することによって、後でメッセージをサブスクライバに転送する、指定したホストのグループにメッセージを配信できます。以下の節では、WebLogic Server でマルチキャストを使用する場合の利点、制限事項、およびコンフィグレーションについて説明します。
マルチキャストを使用すると便利な例としては、株価表示があります。最新の株価を入手する場合に重要になるのは、信頼性よりもタイムリーな配信です。全部または一部の内容が配信されなくても、リアルタイムの株価情報にアクセスするときに、クライアントは簡単に情報の再送信を要求できます。クライアントでは情報の回復は必要とされません。回復された情報が再配信される頃には、その情報は古くて価値のないものになっています。
| 注意 : | マルチキャストは、Pub/Sub メッセージング モデル、および非恒久サブスクライバのみでサポートされています。 |
| 注意 : | マルチキャスト セッションおよびマルチキャスト コンシューマに関するモニタ統計は提供されません。 |
マルチキャストを設定する前に、マルチキャストをサポートするよう、次のように接続ファクトリおよび送り先をコンフィグレーションする必要があります。
DataOverrunException が送出され、メッセージは自動的に破棄されます。これらの属性は、動的にコンフィグレーションすることもできます (「マルチキャストのコンフィグレーション属性の動的コンフィグレーション」を参照)。| 注意 : | マルチキャスト IP アドレス、ポート、存続時間の各属性をコンフィグレーションする場合は、ネットワーク管理者に相談の上、適切な値を設定することを強くお勧めします。 |
詳細については、Administration Console オンライン ヘルプの「トピック マルチキャスト パラメータのコンフィグレーション」を参照してください。
「JMS アプリケーションの設定」に説明されているとおりに JMS アプリケーションを設定します。ただし、セッションを作成する際は、「手順 3 : 接続を使用してセッションを作成する」に説明されているように、acknowledgeMode の値を MULTICAST_NO_ACKNOWLEDGE に設定して、セッションがマルチキャスト メッセージを受信するように指定します。
| 注意 : | マルチキャストは、Pub/Sub メッセージング モデル、および非恒久サブスクライバのみでサポートされています。マルチキャスト セッションで恒久サブスクライバを作成しようとすると、JMSException が送出されます。 |
たとえば、次のメソッドは、Pub/Sub メッセージング モデル用のマルチキャスト セッションの作成方法を示します。
tsession = tcon.createTopicSession(
false,
WLSession.MULTICAST_NO_ACKNOWLEDGE
);
| 注意 : | クライアント サイドでは、マルチキャスト セッションごとに、ソケットからメッセージを取り出すための専用のスレッドが 1 つ必要になります。そのため、JMS クライアントサイドのスレッド プール サイズを増やして調整する必要があります。スレッド プール サイズの調整に関する詳細については、「WebLogic JMS Performance Guide」ホワイト ペーパーの「Tuning Thread Pools and EJB Pools」の節を参照してください。JMS クライアントサイドのスレッド プールのチューニングについて書かれています。 |
さらに、「TopicPublisher と TopicSubscriber の作成」の説明に従って、トピック サブスクライバを作成します。
たとえば、次のコードは、トピック サブスクライバの作成方法を示します。
tsubscriber = tsession.createSubscriber(myTopic);
| 注意 : | 指定した送り先がマルチキャストをサポートするようコンフィグレーションされていない場合、createSubscriber() メソッドは失敗します。 |
マルチキャストのトピック サブスクライバでは、メッセージを非同期に受信することしかできません。マルチキャスト セッションで同期メッセージを受信しようとすると、JMSException が送出されます。
「メッセージの非同期受信」の説明に従って、トピック サブスクライバに対してメッセージ リスナを設定します。
たとえば、次のコードは、メッセージ リスナの設定方法を示します。
tsubscriber.setMessageListener(this);
メッセージを受信すると、WebLogic JMS では、送り先から送信されたメッセージのシーケンスがトラッキングされます。マルチキャスト サブスクライバのメッセージ リスナがシーケンスの異なるメッセージを受信すると、その結果、1 つまたは複数のメッセージがスキップされ、そのセッションの ExceptionListener に SequenceGapException が送出されます。スキップされたメッセージは、その後配信されても破棄されます。たとえば、次の図では、サブスクライバは 2 つの送り先から同時にメッセージを受信しています。
送り先 1 からメッセージ「4」を受信すると、SequenceGapException が送出され、シーケンスの異なるメッセージが受信されたことがアプリケーションに通知されます。その後、メッセージ「3」が配信されても、それは破棄されます。
| 注意 : | やり取りされるメッセージ数が多くなるほど、SequenceGapException が発生する危険性も大きくなります。 |
システム管理者は、コンフィグレーション時に、マルチキャストをサポートするよう、各接続ファクトリに対して以下の情報をコンフィグレーションします。
メッセージが最大数に達すると、DataOverrunException が送出され、メッセージは超過時のポリシーに基づいて自動的に破棄されます。また、Session クラスの set メソッドを使用して、最大メッセージ数と超過時のポリシーを設定する方法もあります。
次の表に、Session クラスの set メソッドと get メソッドを、動的コンフィグレーションが可能な属性ごとに示します。
| 注意 : | set メソッドを使用して設定された値は、コンフィグレーションされた値よりも優先されます。 |
Session クラスのメソッドの詳細については、weblogic.jms.extensions.WLSession の Javadoc を参照してください。これらのマルチキャスト コンフィグレーション属性の詳細については、Administration Console オンライン ヘルプの「トピック マルチキャスト パラメータのコンフィグレーション」を参照してください。
| 注意 : | 次の図は、マルチキャスト TTL (存続時間) 送り先コンフィグレーション属性が、ルータを経由したメッセージの配信に影響する様子を説明するための単純な例です。マルチキャスト TTL 属性をコンフィグレーションする場合は、ネットワーク管理者に相談してから、適切な値を設定することをお勧めします。 |
| 注意 : | マルチキャスト TTL は、メッセージの存続時間に依存しません。 |
次の例では、マルチキャスト TTL 送り先コンフィグレーション属性が、ルータを経由したメッセージの配信に影響する様子を示します。
詳細については、Administration Console オンライン ヘルプの「トピック マルチキャスト パラメータのコンフィグレーション」を参照してください。
この図では、ネットワークは 3 つのサブネットで構成されています。サブネット A にはマルチキャスト パブリッシャがあり、サブネット B および C にはそれぞれ 1 台ずつマルチキャスト サブスクライバがあります。
マルチキャスト TTL 属性が 0 に設定されている (メッセージはルータを経由できず、現在のサブネットにしか配信されないことを示す) 場合は、サブネット A にあるマルチキャスト パブリッシャでメッセージがパブリッシュされても、メッセージはどのマルチキャスト サブスクライバにも配信されません。
マルチキャスト TTL 属性が 1 に設定されている (メッセージは 1 台のルータを経由できることを示す) 場合、サブネット A にあるマルチキャスト パブリッシャでメッセージがパブリッシュされると、サブネット B にあるマルチキャスト サブスクライバでメッセージが受信されます。
同様に、マルチキャスト TTL 属性が 2 に設定されている (メッセージは 2 台のルータを経由できることを示す) 場合、サブネット A にあるマルチキャスト パブリッシャでメッセージがパブリッシュされると、サブネット B および C にあるマルチキャスト サブスクライバでメッセージが受信されます。
  
|
