This chapter is from the book
This chapter is from the book
This chapter is from the book
Using Multicast JMS
A messaging system is commonly used as the application's communication backbone. Messages might travel to hundreds or thousands of subscribers. Appropriate message selectors can greatly limit the number of delivered messages, but systems with thousands of clients will still spend considerable system resources delivering messages.
WebLogic's JMS implementation provides a multicast option to efficiently deliver messages to a large number of subscribers.
The WebLogic JMS implementation optionally uses IP multicast to deliver a message to a potentially large set of subscribers. A message producer sends a JMS message to the WebLogic Server using a standard JMS connection. The WebLogic Server then sends a single message via IP multicast to the message consumers. This provides greater scalability than standard PTP connections because the server needs to send a single message to reach many clients instead of sending a message per client. This multicast option also greatly reduces the network traffic between JMS clients and the WebLogic Servers.
The multicast JMS option is only available for the pub/sub model, and durable subscriptions are not supported. Because a single message consumer receives each message to a JMS queue, it does not make sense to extend the multicast option to the JMS PTP model. The multicast JMS option also only supports asynchronous message listeners. Any attempt to synchronously receive messages with multicast JMS will cause a JMSException to be thrown.
Because IP multicast is not a reliable protocol, message delivery is not guaranteed with the JMS multicast option. The messages are sequenced, and the WebLogic JMS implementation automatically indicates when a gap in the sequence has occurred. This gap indicates that a message has been lost or received out of order. The frequency of lost or misordered messages depends on the network topology and the message size. Small messages on a high-bandwidth LAN rarely (if ever) will be lost. Large messages across a congested network might see frequent lost or misordered messages. If a sequence gap is detected, a weblogic.jms.extensions.SequenceGapException is delivered to the session's ExceptionListener.
Configuration Changes for Multicast JMS
The JMS destination is configured with the appropriate multicast address, port number, and TTL. Multicast addresses are in the range 224.0.0.0 to 239.255.255.255, and the port number should be an available port on the client machine. The TTL determines the Time To Live field in the IP multicast packet. Every time a multicast packet takes a network hop through a router, the TTL value in the packet is decreased. If the TTL value is 0, it is discarded. Thus, a TTL value of 1 will reach only hosts on the local network. A TTL value of 2 will reach all hosts on the local network and cross one router to reach an additional network (see Figure 7–11 ). If you are unsure how to set these values, please consult your network administrator for appropriate values.
){kind=link}
You can use 237.124.35.35. Apply, and restart the WebLogic Server.
Figure 7–11 Configuring Multicast JMS
Using Multicast JMS Sessions
A message consumer uses multicast delivery by creating a TopicSession with the MULTICAST_NO_ACKNOWLEDGE acknowledgment mode.
multicastSession = topicConnection.createTopicSession( false, /* non-transacted session */ WLSession.MULTICAST_NO_ACKNOWLEDGE );
Because this is an asynchronous consumer, the javax.jms.MessageListener interface must be implemented.
public class MulticastMessageConsumer
implements javax.jms.MessageListener
{
public void onMessage(Message m)
throws JMSException
{
// message consumer code
...
}
}
The message consumer must then register a javax.jms.MessageListener with the TopicSubscriber.
tsubscriber.setMessageListener(new MulticastMessageConsumer());
Once message delivery is enabled, the consumer will asynchronously receive multicasted JMS messages.