Programming WebLogic JMS

      

Using Multicasting with WebLogic JMS

Multicasting enables the delivery of messages to a select group of hosts that subsequently forward the messages to subscribers in a cluster. The following sections provide information on the benefits, limitations, and configuration of using multicasting with WebLogic JMS:

 


Benefits of Using Multicasting

The benefits of multicasting include:

 


Limitations of Using Multicasting

The limitations of multicasting include:

For an example of when multicasting might be useful, consider a stock ticker. When accessing stock quotes, timely delivery is more important than reliability. When accessing the stock information in real-time, if all or a portion of the contents is not delivered, the client can simply request the information to be resent. Clients would not want to have the information recovered, in this case, as by the time it is redelivered, it would be out-of-date.

 


Using WebLogic Server Unicast

WebLogic Server provides an alternative to using multicast to handle cluster messaging and communications. Unicast configuration is much easier because it does not require cross network configuration that multicast requires. Additionally, it reduces potential network errors that can occur from multicast address conflicts.

JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:

For more details, see Communications In a Cluster in Using WebLogic Server Clusters.

 


Configuring Multicasting for WebLogic Server

The following figure illustrates the steps required to set up multicasting. Figure 7-1 Setting Up Multicasting

Setting Up Multicasting

Multicasting is only supported for the Pub/Sub messaging model, and only for non-durable subscribers.

Note: Monitoring statistics are not provided for multicast sessions or consumers.

 

Prerequisites for Multicasting

Before setting up multicasting, the connection factory and destination must be configured to support multicasting, as follows:

It is strongly recommended that you seek the advice of your network administrator when configuring the multicast IP address, port, and time-to-live attributes to ensure that the appropriate values are set.

For more information, see “Configure topic multicast parameters” in the Administration Console Online Help.

 

Step 1: Set Up the JMS Application, Creating Multicast Session and Topic Subscriber

Set up the JMS application as described in Setting Up a JMS Application. However, when creating sessions, as described in Step 3: Create a Session Using the Connection, specify that the session would like to receive multicast messages by setting the acknowledgeMode value to MULTICAST_NO_ACKNOWLEDGE.

Multicasting is only supported for the Pub/Sub messaging model for non-durable subscribers. An attempt to create a durable subscriber on a multicast session will cause a JMSException to be thrown.

For example, the following method illustrates how to create a multicast session for the Pub/Sub messaging model.

tsession = tcon.createTopicSession(

false,
WLSession.MULTICAST_NO_ACKNOWLEDGE
);

On the client side, each multicasting session requires one dedicated thread to retrieve messages off the socket. Therefore, you should increase the JMS client-side thread pool size to adjust for this.

In addition, create a topic subscriber, as described in Create TopicPublishers and TopicSubscribers.

For example, the following code illustrates how to create a topic subscriber:

tsubscriber = tsession.createSubscriber(myTopic);

The createSubscriber() method fails if the specified destination is not configured to support multicasting.

 

Step 2: Set Up the Message Listener

Multicast topic subscribers can only receive messages asynchronously. If you attempt to receive synchronous messages on a multicast session, a JMSException is thrown.

Set up the message listener for the topic subscriber, as described in Receiving Messages Asynchronously.

For example, the following code illustrates how to establish a message listener:

tsubscriber.setMessageListener(this);

When receiving messages, WebLogic JMS tracks the order in which messages are sent by the destinations. If a multicast subscriber's message listener receives the messages out of sequence, resulting in one or more messages being skipped, a SequenceGapException will be delivered to the ExceptionListener for the session(s) present. If a skipped message is subsequently delivered, it will be discarded. For example, in the following figure, the subscriber is receiving messages from two destinations simultaneously. Figure 7-2 Multicasting Sequence Gap

Multicasting Sequence Gap

Upon receiving the “4” message from Destination 1, a SequenceGapException is thrown to notify the application that a message was received out of sequence. If subsequently received, the “3” message will be discarded.

The larger the messages being exchanged, the greater the risk of encountering a SequenceGapException.

 

Dynamically Configuring Multicasting Configuration Attributes

During configuration, for each connection factory the system administrator configures the following information to support multicasting:

If the messages maximum is reached, a DataOverrunException is thrown and messages are automatically discarded based on the overrun policy. Alternatively, you can set the messages maximum and overrun policy using the Session set methods.

The following table lists the Session set and get methods for each dynamically configurable attribute.

Table 7-1 Message Producer Set and Get Methods
Attribute Set Method Get Method
Messages Maximum public void setMessagesMaximum(
int messagesMaximum
) throws JMSException
public int getMessagesMaximum(
) throws JMSException
Overrun Policy public void setOverrunPolicy (
int overrunPolicy
) throws JMSException
public int getOverrunPolicy(
) throws JMSException

The values set using the set methods take precedence over the configured values.

For more information about these Session class methods, see the weblogic.jms.extensions.WLSession Javadoc. For more information on these multicast configuration attributes, see “Configure topic multicast parameters” in the Administration Console Online Help.

 

Example: Multicast TTL

The following example is a very simplified illustration of how the Multicast TTL (time-to-live) destination configuration attribute impacts the delivery of messages across routers. It is strongly advised that you seek the assistance of your network administrator when configuring the multicast TTL attribute to ensure that the appropriate value is set.

Note: The Multicast TTL is independent of the message time-to-live.

The following example illustrates how the Multicast TTL destination configuration attribute impacts the delivery of messages across routers.

For more information, see “Configure topic multicast parameters” in the Administration Console Online Help.

Consider the following network diagram. Figure 7-3 Multicast TTL Example

Multicast TTL Example

In the figure, the network consists of three subnets: Subnet A containing the multicast publisher, and Subnets B and C each containing one multicast subscriber.

If the Multicast TTL attribute is set to 0 (indicating that the messages cannot traverse any routers and are delivered on the current subnet only), when the multicast publisher on Subnet A publishes a message, the message will not be delivered to any of the multicast subscribers.

If the Multicast TTL attribute is set to 1 (indicating that messages can traverse one router), when the multicast publisher on Subnet A publishes a message, the multicast subscriber on Subnet B will receive the message.

Similarly, if the Multicast TTL attribute is set to 2 (indicating that messages can traverse two routers), when the multicast publisher on Subnet A publishes a message, the multicast subscribers on Subnets B and C will receive the message.