Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

JMS Clustering Part I

Queues, topics, and connection factories

This article is the first of a two-part series on JMS clustering. Part 1 will discuss the fundamental aspects of clustering JMS resources such as queues, topics, and connection factories, and illustrate the steps to go through to configure a clustered destination in a WebLogic cluster. Part 2 will discuss JMS clustering in the context of several design and configuration strategies that demonstrate how to create efficient and optimized JMS architectures.

WebLogic v7.0 introduced JMS clustering. This article will discuss the fundamental aspects of JMS clustering in WebLogic 8.1 (SP3).

Clustering JMS Resources

Scalability, high availability, and fault tolerance are required of mission-critical systems. The standards that have been memorialized in J2EE provide the framework needed to build the robust architecture that meets those requirements. JMS provides enterprise systems with a foundation for messaging. JMS systems that demand near-zero downtime, such as those in financial houses, must provide the high availability and failover for JMS resources to meet stringent service-level agreements. So it's vital to use a JMS implementation that lets JMS resources, such as queues, topics, and connection factories, be clustered and highly available while load-balancing message traffic among distributed JMS destinations.

WebLogic's JMS is a complete messaging implementation that supports JMS standards. It also provides services so that clustered JMS configurations can load-balance messages and offer high availability for all kinds of JMS resources. In a WebLogic cluster, ordinary queues and topics can be configured as distributed destinations that consist of many physical destinations dispersed among physical machines, creating a highly available messaging layer. Connection factories can also be distributed. It lets WebLogic load-balance connection requests from JMS clients and transparently directs message traffic to the desired destination, or redirects messages in the event of destination failure.

Distributed Destinations

A distributed destination represents a group of physical queues, or topics, whose members are hosted by JMS servers in a WebLogic cluster. The distributed destination is bound to a logical JNDI name in the cluster-wide JNDI tree. WebLogic will load-balance messages among the members of a distributed destination and, if a destination member fails, messages will be transparently redirected to other members in the distributed destination. From the point-of-view of a JMS client, a distributed destination appears as an ordinary destination, which means that an existing JMS application configured with ordinary destinations can change its configuration to distributed destinations without impacting JMS clients or application code.

Distributed Queues
A distributed queue represents a group of physical queues. If a QueueSender is created using the JNDI name of a distributed queue, any message sent from that QueueSender is delivered to only one physical queue destination. A decision is made every time a message is sent determining which member will get the message. This decision is based on a load-balancing algorithm provided by WebLogic. The default load-balancing scheme is a Round Robin, but you can use a Random load-balancing scheme to distribute messages to destination members at random.

When a QueueReceiver is created using a distributed queue name, it will connect to a physical queue member and, unlike a QueueSender, remain pinned to that destination until the QueueReceiver loses connection.

Figure 1 illustrates how JMS clients interact with a distributed queue in a WebLogic cluster. In the diagram, the distributed queue (DQ) has two physical queue members MQ1 and MQ2 residing on server instances 1 and 2, respectively. The queue receiver (QR) gets messages from MQ1 and will remained pinned to MQ1 until the connection is closed. The queue sender (QR) sends messages to the distributed queue DQ. Only one physical queue member gets the messages sent to a distributed queue and, as the illustration shows, the first message, Message1, sent by QS is load-balanced and sent to MQ1. The next message, Message2, is also load-balanced and is sent to the next queue member in the sequence, MQ2. The illustration uses a Round Robin load-balancing policy, which picks server instances in an ordered sequence.

When a message is sent to a distributed queue member with no consumers, the message will remain in that queue until a consumer is available, and, if the queue member fails, all messages pending in that queue will be unavailable until the queue member is available again. Configuring a Forward Delay on each member in the distributed queue can prevent this situation. This option automatically forwards messages from a queue member with no active consumers to queue members with active consumers. By default, the Forward Delay is disabled. We'll discuss how to configure this destination parameter below.

If a physical queue member fails, all consumers connected to it are notified by a JMSException and effectively lose their connection to the queue. For synchronous consumers, the exception is returned directly to the client. For asynchronous consumers whose queue session is configured with an ExceptionListener, a ConsumerClosedException is sent. In either case - assuming the failure was isolated to the physical queue member - the JMS connection and session remain valid. The client application just closes the queue receiver and recreates it using the same JMS session.

Distributed Topics
A distributed topic represents a group of physical topics. JMS client applications can create topic message producers and consumers using a distributed topic name. Your application doesn't know how many physical destination members the distributed topic has, which eliminates any special programming considerations when using this kind of clustered JMS resource.

When the TopicPublisher created with a distributed topic name publishes a message, the message is automatically sent to all members of the distributed topic so all subscribers get the message. Messages are forwarded to all topic member destinations even if a TopicPublisher is created using the JNDI name of a physical topic destination and not the distributed topic JNDI name.

Non-persistent messages published to a distributed topic are sent only to the topic destinations that are available. If your application uses persistent messages, then it's a good idea to configure each topic member destination with a persistent store. WebLogic gives preference to topic destinations configured with persistent stores when publishing a persistent message on a distributed topic to avoid lost messages. If any topic members are unavailable when a persistent message is published, the message will be stored on the topic members with persistent stores and forwarded to the remaining topic members as they become available.

A TopicSubscriber created with a distributed topic name is pinned to a physical topic member of the distributed topic. Connection is maintained until the destination topic member fails. If and when that happens, the topic subscriber is sent a JMSException the same as when a destination queue member fails. If a topic destination member with active subscribers fails, then any persistent messages published to the distributed topic after the failure won't be delivered to the disconnected subscribers until the topic destination member can get messages again. In contrast, a subscriber that lost connection with a distributed topic member never gets a non-persistent message.

Figure 2 illustrates how JMS clients interact with a distributed topic in a WebLogic cluster. The distributed topic (DT) in the diagram consists of two physical topic members T1 and T2 residing on server instances 1 and 2, respectively. A topic subscriber (TS) gets messages from T1 and remains pinned to this topic member until the connection is closed or lost. A topic publisher (TP) sends messages to the distributed topic (DT). All physical topic members get the messages sent to the distributed topic. As the illustration shows, TP publishes Message1 to the distributed topic DT, which sends it to topic members T1 and T2. The next message Message2 is also sent to both topic members.

Clustering Connection Factories
Connection factories can also leverage the capabilities of JMS clustering to provide load balancing, high availability, and failover for JMS clients.

A connection factory can be targeted to a cluster, or targeted to individual WebLogic instances in a cluster, whether or not those WebLogic instances host a JMS server. From an architectural perspective, you need to consider the physical location of the JMS clients in your application and the destinations they will access before you decide where to target your connection factories. For example, if an external client uses a connection factory targeted to multiple WebLogic instances in a cluster, the decision of which connection factory to use as well as which JMS server will host the JMS connection is load-balanced.

The connection routing might be inefficient if the new JMS connection and the local JMS server are on the same physical machine. To avoid unnecessary connection routing, make sure the Server Affinity parameter for each connection factory in your JMS application is enabled. You can change this setting from the WebLogic Administration console by navigating to the "Services/JMS/Connection Factories" node. Select the connection factory from the list, and scroll to the bottom of the General tab to find the Server Affinity parameter.

In contrast, an internal JMS client trying to locate a connection factory and create a JMS connection won't incur a wasteful remote connection if the connection factory is physically located on the same WebLogic instance as the JMS server that hosts the desired destination. The default load-balancing policy used by the connection factory for internal JMS clients is circumvented because WebLogic gives preference to collocated connection factories and JMS servers to avoid creating remote connections.

The details of configuring and targeting connection factories in the context of different JMS application scenarios will be discussed in part two of this article.

Configuring a Distributed Destination

To configure a distributed queue or topic, open the WebLogic Administration console and navigate to the "Services/JMS/Distributed Destinations" node (Figure 3).

Now you can create a Distributed Topic or a Distributed Queue. In this example we'll create a distributed queue. To continue, click Configure a new Distributed Queue. Figure 4 displays the configuration parameters for creating a distributed queue.
Name: The unique logical identifier for the distributed queue destination.
JNDI Name: The lookup alias for cluster-wide JNDI.
Load Balancing Policy: The algorithm used to determine the distribution of messages among the distributed destination members.
Forward Delay: Only for distributed queues. It defines the amount of time a distributed queue member with no consumers will wait before forwarding its pending messages to other queue members with active consumers.

Once you create the distributed queue click the Thresholds and Quotas tab. The parameters on this screen are well documented so we'll skip the point of each setting, but in general the parameters let you configure the maximum message quotas, message thresholds, maximum message size, and bytes message paging. These settings apply globally to all physical members belonging to the distributed destination.

At this point, you're ready to add physical queue members to the distributed queue. If your WebLogic domain has queue destinations that you want to designate as members of your newly created distributed queue, click the Members tab (Figure 5), then click Configure a new Distributed Queue Member.

On the next screen, enter the configuration parameters of the physical queue member (Figure 6).

Name: The unique logical identifier for the member destination.
JMS Queue/Topic: The list of available queues from which you select the physical destination of new members of the distributed queue.
Weight: The integer that controls the message load balancing for the Round Robin algorithm. The weights are relative to the other queue member destinations in the same distributed queue; a higher value designates the members that get more messages than those with a lower setting.

Click the Create button to create the new distributed queue member. You can repeat this procedure for adding other members to the distributed queue.

WebLogic provides a convenient feature to create physical queues or topics automatically and assign them to a distributed destination.

To use this feature, click the Auto Deploy tab (Figure 7) and then click Create members on the selected Servers (and JMS Servers).

On the next screen you have the option of choosing the WebLogic instances directly, or the WebLogic cluster, to serve as the targets for the distributed destination.

If you want to target a WebLogic instance directly:
Select (none), then click Next (Figure 8)
Select the WebLogic instance on which to create destination members, then click Next (Figure 9)
Select the JMS servers on which to deploy the destinations members, then click Next (Figure 10)
     If you want to target to a WebLogic cluster:
Select the cluster name, then click Next (Figure 8)
Select the WebLogic instances on which to create destination members, then click Next (Figure 11)
Select the JMS servers on which to deploy the destinations members, then click Next (Figure 12)

After applying the configuration changes, WebLogic automatically creates member destinations on the JMS servers selected. Click the Members tab to see the list of newly generated member destinations (Figure 13).

Conclusion

At this point you should understand the basic features of JMS clustering and the kinds of distributed resources it provides. The next article will discuss JMS application design strategies for internal producers/consumers, external-only producers, highly distributed and load-balanced JMS applications, and the best practices and guidelines to follow when using JMS clustering.

More Stories By Raffi Basmajian

Raffi Basmajian works as an application architect for a major financial services firm in New York City. He specializes in architecting Java/J2EE distributed systems and integration frameworks. He can be reached at [email protected]

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
David Karr 04/12/05 12:52:30 PM EDT

This is useful information, but it could use more elaboration in two different areas:

The information on Connection Factories could be much better. From this description, I'm not really sure what a Connection Factory does. A simple description would be fine. In addition, it's not clear what the relationship is between "local" and "remote" components, and why the connection routing might be inefficient if the connection and server are not colocated.

Secondly, in a couple of different places, reference is made to a state where there is a distributed queue member with no consumers. It would be useful to clarify exactly what this means.

@ThingsExpo Stories
I think DevOps is now a rambunctious teenager - it's starting to get a mind of its own, wanting to get its own things but it still needs some adult supervision," explained Thomas Hooker, VP of marketing at CollabNet, in this SYS-CON.tv interview at DevOps Summit at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
"MobiDev is a software development company and we do complex, custom software development for everybody from entrepreneurs to large enterprises," explained Alan Winters, U.S. Head of Business Development at MobiDev, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
Major trends and emerging technologies – from virtual reality and IoT, to Big Data and algorithms – are helping organizations innovate in the digital era. However, to create real business value, IT must think beyond the ‘what’ of digital transformation to the ‘how’ to harness emerging trends, innovation and disruption. Architecture is the key that underpins and ties all these efforts together. In the digital age, it’s important to invest in architecture, extend the enterprise footprint to the cl...
Data is the fuel that drives the machine learning algorithmic engines and ultimately provides the business value. In his session at Cloud Expo, Ed Featherston, a director and senior enterprise architect at Collaborative Consulting, discussed the key considerations around quality, volume, timeliness, and pedigree that must be dealt with in order to properly fuel that engine.
Two weeks ago (November 3-5), I attended the Cloud Expo Silicon Valley as a speaker, where I presented on the security and privacy due diligence requirements for cloud solutions. Cloud security is a topical issue for every CIO, CISO, and technology buyer. Decision-makers are always looking for insights on how to mitigate the security risks of implementing and using cloud solutions. Based on the presentation topics covered at the conference, as well as the general discussions heard between sessio...
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
No hype cycles or predictions of zillions of things here. IoT is big. You get it. You know your business and have great ideas for a business transformation strategy. What comes next? Time to make it happen. In his session at @ThingsExpo, Jay Mason, Associate Partner at M&S Consulting, presented a step-by-step plan to develop your technology implementation strategy. He discussed the evaluation of communication standards and IoT messaging protocols, data analytics considerations, edge-to-cloud tec...
Announcing Poland #DigitalTransformation Pavilion
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. All In Mobile is a mobile app development company from Poland. Since 2014, they maintain passion for developing mobile applications for enterprises and startups worldwide.
CloudEXPO | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
The best way to leverage your CloudEXPO | DXWorldEXPO presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering CloudEXPO | DXWorldEXPO will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at CloudEXPO. Product announcements during our show provide your company with the most reach through our targeted audienc...
Everything run by electricity will eventually be connected to the Internet. Get ahead of the Internet of Things revolution. In his session at @ThingsExpo, Akvelon expert and IoT industry leader Sergey Grebnov provided an educational dive into the world of managing your home, workplace and all the devices they contain with the power of machine-based AI and intelligent Bot services for a completely streamlined experience.
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world.
DXWorldEXPO | CloudEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
22nd International Cloud Expo, taking place June 5-7, 2018, at the Javits Center in New York City, NY, and co-located with the 1st DXWorld Expo will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud ...
In his keynote at 19th Cloud Expo, Sheng Liang, co-founder and CEO of Rancher Labs, discussed the technological advances and new business opportunities created by the rapid adoption of containers. With the success of Amazon Web Services (AWS) and various open source technologies used to build private clouds, cloud computing has become an essential component of IT strategy. However, users continue to face challenges in implementing clouds, as older technologies evolve and newer ones like Docker c...
JETRO showcased Japan Digital Transformation Pavilion at SYS-CON's 21st International Cloud Expo® at the Santa Clara Convention Center in Santa Clara, CA. The Japan External Trade Organization (JETRO) is a non-profit organization that provides business support services to companies expanding to Japan. With the support of JETRO's dedicated staff, clients can incorporate their business; receive visa, immigration, and HR support; find dedicated office space; identify local government subsidies; get...
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...