Using Multicasting with WebLogic JMS

8 Using Multicasting with WebLogic JMS

Learn how WebLogic JMS Multicasting enables the delivery of messages to a select group of hosts that subsequently forward the messages to subscribers in a cluster.

Benefits of Using Multicasting

Understand the benefits of using multicasting.

Near real-time delivery of messages to a host group
High scalability due to the reduction in the amount of resources required by the JMS server to deliver messages to topic subscribers in a cluster

Limitations of Using Multicasting

Understand the limitations of multicasting and the scenarios when multicasting should not be used.

The limitations of multicasting include:

Multicast messages are not guaranteed to be delivered to all members of the host group. For messages requiring reliable delivery and recovery, you should not use multicasting.
For interoperability with different versions of WebLogic Server, clients cannot have an earlier release of WebLogic Server installed than the host has. They must all have at least the same version or later.

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 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 the 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:

The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.
JMS multicast subscribers need to be in a network hardware configuration that allows multicast accessibility.

See Communications In a Cluster in Administering Clusters for Oracle WebLogic Server.

Configuring Multicasting for WebLogic Server

Learn how to configure multicasting for WebLogic server.

Figure 8-1 shows the steps required to set up multicasting.

Figure 8-1 Setting Up Multicasting

Description of "Figure 8-1 Setting Up Multicasting"

Note:

Multicasting is only supported for the Publish/Subscribe messaging model, and only for non durable subscribers.

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:

For each connection factory, the system administrator configures the maximum number of outstanding messages that can exist on a multicast session and whether the most recent or oldest messages are discarded in the event the maximum is reached. If the message maximum is reached, a DataOverrunException is thrown, and messages are automatically discarded. These attributes are also dynamically configurable, as described in Dynamically Configuring Multicasting Configuration Attributes.
For each destination, the Multicast Address (IP), Port, and TTL (Time-To-Live) attributes are specified. To better understand the TTL attribute setting, see Example: Multicast Time-to-Live.

Note:

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 Oracle WebLogic Server Administration Console Online Help.

Step 1: Set Up the JMS Application, 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.

Note:

Multicasting is only supported for the Publish/Subscibe 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 shows how to create a multicast session for the Publish/Subscibe messaging model.

JMSModuleHelper.createPermanentQueueAsync(ctx, domain, jmsServerName, 
 queueName, jndiName);
Queue queue = findQueue(qsess, jmsServerName, queueName,
 retry_count, retry_interval);

Note:

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);

Note:

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, then a JMSException is thrown.

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

For example, the following code shows 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, then a SequenceGapException will be delivered to the ExceptionListener for the session(s) present. If a skipped message is subsequently delivered, then it will be discarded. For example, in the Figure 8-2, the subscriber is receiving messages from two destinations simultaneously.

Figure 8-2 Multicasting Sequence Gap

Description of "Figure 8-2 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.

Note:

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:

Message maximum specifying the maximum number of outstanding messages that can exist on a multicast session.
Overrun policy specifying whether recent or older messages are discarded in the event the message maximum is reached.

If the message 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.

Table 8-1 lists the Session set and get methods for each dynamically configurable attribute.

Table 8-1 Message Producer Set and Get Methods

Attribute	Set Method	Get Method
Message 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`

Note:

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 about these multicast configuration attributes, see Configure topic multicast parameters in the Oracle WebLogic Server Administration Console Online Help.

Example: Multicast Time-to-Live

Note:

The following example is a very simplified illustration of how the Multicast TTL (time-to-live) destination configuration attribute affects 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.

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

Figure 8-3 shows how the Multicast TTL destination configuration attribute affects the delivery of messages across routers.

For more information, see Configure topic multicast parameters in the Oracle WebLogic Server Administration Console Online Help.

Figure 8-3 Multicast TTL Example

Description of "Figure 8-3 Multicast TTL Example"

In the figure, the network consists of three subnets: Subnet A containing the multicast publisher, and Subnets B and C each contain 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.