Managing WebLogic JMS

The Administration Console provides the interface that you can use to enable, configure, and monitor the features of the WebLogic Server, including JMS. To invoke the Administration Console, refer to the procedures described in "Starting and Using the Administration Console" in the Administration Guide.

The following sections provide an overview of configuring and monitoring WebLogic JMS:

• Configuring WebLogic JMS

• Configuring WebLogic JMS Clustering

• Configuring JMS Migratable Targets

• Tuning WebLogic JMS

• Monitoring WebLogic JMS

• Recovering from a WebLogic Server Failure

 

---

Configuring WebLogic JMS

Using the Administration Console, you define configuration attributes to:

• Enable JMS.

• Create JMS servers.

• Create and/or customize values for JMS servers, connection factories, destinations (physical queues and topics), distributed destinations (sets of physical queue and topic members within a cluster) destination templates, destination sort ordering (using destination keys), persistent stores, paging stores, session pools, and connection consumers.

• Set up custom JMS applications.

• Define thresholds and quotas.

• Enable any desired JMS features, such as:

  • server clustering

  • concurrent message processing

  • persistent messaging

  • message paging

  • flow control

WebLogic JMS provides default values for some configuration attributes; you must provide values for all others. If you specify an invalid value for any configuration attribute, or if you fail to specify a value for an attribute for which a default does not exist, the WebLogic Server will not boot JMS when you restart it. A sample JMS configuration is provided with the product.

When migrating from a previous release, the configuration information will be converted automatically, as described in Porting Existing Applications.

Note: Configuration Checklists, provides checklists that enable you to view the attribute requirements and/or options for supporting various JMS features.

 

---

Configuring WebLogic JMS Clustering

A WebLogic Server cluster is a group of servers that work together to provide a more scalable, more reliable application platform than a single server. A cluster appears to its clients as a single server but is in fact a group of servers acting as one. A cluster provides three key features above a single server:

• Scalability—servers can be added to the cluster dynamically to increase capacity.

• High Availability—redundancy of multiple servers insulates applications from failures. Redundancy of multiple destinations (queues and topics) as members of a single distributed destination set within a cluster ensures redistribution of the messaging load to other available members in the set when one member becomes unavailable.

• Migratability—respond to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure.

Note: JMS clients depend on unique WebLogic Server names to successfully access a cluster—even when WebLogic Servers reside in different domains. Therefore, make sure that all WebLogic Servers that JMS clients contact have unique server names.

For more information about starting WebLogic clusters and its features and benefits, see "Configuring WebLogic Servers and Clusters" in Using WebLogic Server Clusters.

How JMS Clustering Works

An administrator can establish cluster-wide, transparent access to JMS destinations from any server in the cluster, either by using the default connection factory for each server instance in the cluster, or by configuring one or more connection factories and targeting them to one or more server instances in the cluster. This way, each connection factory can be deployed on multiple WebLogic Servers. However, each user-defined connection factory must be uniquely named to be successfully deployed on multiple WebLogic Servers.

The administrator can configure multiple JMS servers on the various nodes in the cluster—as long as the JMS servers are uniquely named—and can then assign JMS destinations to the various JMS servers.

The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. Requests for destinations not handled by a JMS server are forwarded to the appropriate WebLogic Server.

JMS Clustering Naming Requirements

JMS clients depend on unique WebLogic Server names to successfully access a cluster—even when WebLogic Servers reside in different domains. Therefore, make sure that all WebLogic Servers that JMS clients contact have unique server names.

The following unique naming requirements apply when configuring WebLogic JMS to work in a clustered environment in either a single WebLogic domain or in a multi-domain environment.

• All JMS connection factories targeted to nodes in a domain must be uniquely named.

• All JMS servers targeted to nodes in all domains must be uniquely named.

• If persistent messaging is required, all JMS stores in all domains must be uniquely named.

For more information about JMS resource naming rules in single domain and multi-domain environments, see "JMS Resource Naming Rules for Domain Interoperability" in the Administration Guide.

JMS Distributed Destination within a Cluster

An administrator can also configure multiple JMS destinations in cluster as part of a single distributed destination, which is a set of queues or topics that are called under a single JNDI name so This way they appear to be a single, logical destination to a JMS client, when the members of the set are actually distributed across multiple servers within a cluster, with each destination member belonging to a separate JMS server. This way, in the event of a single server failure within the cluster, the message load is distributed across the other available members of the distributed destination. For more information on configuring a distributed destination, see "Configuring Distributed Destinations" in the Administration Guide.

JMS as a Migratable Service within a Cluster

WebLogic JMS takes advantage of the migration framework implemented in the WebLogic Server core for clustered environments. This allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure. For more information, see Configuring JMS Migratable Targets.

Configuration Guidelines for JMS Clustering

In order to use WebLogic JMS in a clustered environment, follow these guidelines:

1. Configure your clustered environment as described in "Setting Up WebLogic Clusters" in Using WebLogic Server Clusters.

2. Identify server targets for JMS connection factories using the Administration Console. For connection factories, you can identify either a single-server target or a cluster target, which are server instances that are associated with a connection factory to support clustering.

   For more information about these connection factory configuration attributes, see "Configuring Connection Factories" in the Administration Guide.

3. Optionally, identify migratable server targets for JMS servers using the Administration Console. For JMS servers, you can identify either a single-server target or a migratable target, which is a set of server instances in a cluster that can host an "exactly-once" service like JMS in case of a single server failure.

   For more information on migratable JMS server targets, see Configuring JMS Migratable Targets. For more information about JMS server configuration attributes, see "Configuring JMS Servers" in the Administration Guide.

   Note: You cannot deploy the same destination on more than one JMS server. In addition, you cannot deploy a JMS server on more than one WebLogic Server.

4. Optionally, you can configure the physical JMS destinations in a cluster as part of a distributed destination set, as discussed in JMS Distributed Destination within a Cluster.

What About Failover?

For WebLogic JMS implementations that are part of a WebLogic 7.0 clustered environment, JMS offers service continuity in the event of a single Weblogic Server failure by enabling you to configure multiple physical destinations (queues and topics) as part of a single distributed destination set. In addition, implementing the Migratable Service feature, will ensure that pinned "exactly-once" services, like JMS, do not introduce a single point of failure for dependent applications in the cluster,

However, automatic failover is not currently supported by WebLogic JMS. For information about performing a manual failover, refer to Recovering from a WebLogic Server Failure.

 

---

Configuring JMS Migratable Targets

As an exactly-once service, WebLogic JMS is not active on all WebLogic Server instances in a cluster. It is instead "pinned" to a single server in the cluster to preserve data consistency. To ensure that pinned services do not introduce a single point of failure for dependent applications in the cluster, WebLogic Server can be configured to migrate exactly-once services to any server in the migratable target list.

WebLogic JMS takes advantage of the migration framework by allowing an administrator to specify a migratable target for a JMS server in the Administration Console. Once properly configured, a JMS server and all of its destinations can migrate to another WebLogic Server within a cluster.

This allows WebLogic JMS to properly respond to migration requests and bring a JMS server online and offline in an orderly fashion. This includes both scheduled migrations as well as migrations in response to a WebLogic Server failure with the cluster.

For more information about defining migratable targets, see "Migration for Pinned Services" in Using WebLogic Server Clusters.

How JMS Migration Works

For implementations that are part of a WebLogic clustered environment, WebLogic JMS implements the server migration framework, which allows JMS servers to respond to activate and deactivate requests.

Table 3-1 WebLogic JMS Migration Process

Migration state...	What takes place...
Initialization	Initialization of a JMS server includes processing any configuration or deployment information and creating the appropriate objects. Destinations and other JMS resources are unavailable at this time. In addition, the persistent store is not opened, as this could compromise the integrity of the store. The JMS server makes itself available to handle changes in configuration that may occur between initialization and activation.
Activation	When a JMS server is activated, it opens the persistent store, performs any necessary recovery, reconciles the contents of the store with the current configuration, and makes the destinations available for access by applications. In addition, any configured server session pools begin processing after activation is complete.
Deactivation	When a JMS server is deactivated it stops all server session pool processing, marks all destinations as unavailable, flushes and closes its persistent stores, purges its destinations, and deletes all objects for the JMS server.

Configuration Steps for JMS Server Migration

In order to make a JMS server a migratable service in a clustered environment, you must do the following:

1. Optionally, familiarize yourself with how server migration for pinned services works by reading "Migration for Pinned Services" in Using WebLogic Server Clusters.

2. For JMS implementations that use persistent messaging, make sure that the JMS store is configured such that all the candidate servers in a migratable target share access to the store. For more information about migrating JMS stores, see Persistent Store Migration.

3. Configure a migratable target server for the cluster that can potentially host a JMS server, as described in "Configure Migratable Targets for Pinned Services" in Using WebLogic Server Clusters.

   Note: You must set a unique Listen Address value for the migratable target server instance that will host a migrated the JMS server; otherwise, the migration will fail.

4. Identify a migratable target server instance on which to deploy a JMS server as described in "Deploying JMS to a Migratable Target Server Instance" in Using WebLogic Server Clusters.

   Note: When a migratable target server boots, the JMS server automatically boots as well on the user-preferred server in the cluster.

5. You can also manually migrate a JMS server and all of its destinations before performing server maintenance or to a healthy server if the host server fails. For more information, see "Migrating a Pinned Service To a Target Service Instance" in Using WebLogic Server Clusters.

   Note: A JMS server's distributed destination members can migrate to another server instance within a cluster—even when the target server instance is already hosting a JMS server with its own distributed destination members. For more information about distributed destination failover, see Distributed Destination Failover.

Persistent Store Migration

Weblogic JMS persistent stores cannot be migrated along with JMS servers; therefore, applications that need access to persistent stores from other physical machines after the migration of a JMS server must implement an alternative solution, as follows:

• Implement a hardware solution, such as a dual-ported SCSI disk or Storage Area Network (SAN) to make your JMS persistent store available from other machines.

• Use JDBC to access your JMS JDBC store, which can be on yet another server. Applications can then take advantage of any high-availability or failover solutions offered by your database vendor.

  For more information about configuring a JMS JDBC store, see "Configuring Stores" in the Administration Guide.

Migration Failover

For information about procedures for recovering from a WebLogic Server failure, see "Managing JMS" in the Administration Guide.

 

---

Tuning WebLogic JMS

The following sections explain how to get the most out of your applications by implementing the administrative performance tuning features available with WebLogic JMS.

• Synchronous Write Policies for JMS File Stores—disabling synchronous writes improves file store performance, often quite dramatically, but at the expense of possibly losing sent messages or generating duplicate received messages in the event of an operating system crash or a hardware failure.

  For more information, see "Configuring a Synchronous Write Policy for JMS File Stores" in the Administration Guide.

• Using Message Paging—you can free up valuable virtual memory during peak message load periods by swapping out messages from memory to persistent storage whenever your message loads reach a specified threshold. From a performance perspective, this feature can greatly benefit WebLogic Server implementations with the large message spaces that are required by today's enterprise applications.

  For more information, see "Using Message Paging" in the Administration Guide.

• Establishing Message Flow Control—a JMS server or JMS destination (queue or topic) can be configured to instruct message producers to limit their message flow when it determines that it is becoming overloaded.

  For more information, see "Establishing Message Flow Control" in the Administration Guide.

• Tuning Distributed Destinations—the following attributes on the JMS Connection Factory can be configured to tune your distributed destinations:

  • Load Balancing—defines whether WebLogic JMS will spread or balance the messaging load across distributed destinations.

  • Server Affinity—defines whether a WebLogic Server that is attempting to load balance consumers or producers across multiple physical destinations in a distributed destination set, will first attempt to load balance across those physical destinations being served by any JMS servers that are also running on the same WebLogic Server.

  For more information, see "Tuning Distributed Destinations" in the Administration Guide.

 

---

Monitoring WebLogic JMS

Statistics are provided for the following JMS objects: JMS servers, connections, sessions, destinations, durable subscribers, message producers, message consumers, and server session pools. You can monitor JMS statistics using the Administration Console.

JMS statistics continue to increment as long as the server is running. Statistics can only be reset when the server is rebooted.

For more information on configuring and monitoring WebLogic JMS, see "Managing JMS" in the Administration Guide.

Once WebLogic JMS has been configured, applications can begin sending and receiving messages through the JMS API, as described in Developing a WebLogic JMS Application.

 

---

Recovering from a WebLogic Server Failure

The procedures for recovering from a WebLogic Server failure, and performing a manual failover, including programming considerations, are described in detail in "Managing JMS" in the Administration Guide.