e-docs > WebLogic Server > Programming WebLogic JMS > Managing WebLogic JMS |
Programming 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:
Using the Administration Console, you define configuration attributes to:
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:
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.
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.
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:
For more information about these connection factory configuration attributes, see "Configuring Connection Factories" in the Administration Guide.
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.
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.
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.
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:
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.
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:
For more information about configuring a JMS JDBC store, see "Configuring Stores" in the Administration Guide.
For information about procedures for recovering from a WebLogic Server failure, see "Managing JMS" in the Administration Guide.
The following sections explain how to get the most out of your applications by implementing the administrative performance tuning features available with WebLogic JMS.
For more information, see "Configuring a Synchronous Write Policy for JMS File Stores" in the Administration Guide.
For more information, see "Using Message Paging" in the Administration Guide.
For more information, see "Establishing Message Flow Control" in the Administration Guide.
For more information, see "Tuning Distributed Destinations" in the Administration Guide.
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.