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 the procedures described in Administration Guide.

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

• Configuring WebLogic JMS

• Configuring WebLogic JMS Clustering

• 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 (topics and queues), destination templates, destination sort ordering (using destination keys), backing stores, session pools, and connection consumers.

• Set up custom JMS applications.

• Define thresholds and quotas.

• Enable any desired JMS features, such as server clustering (see the next section), concurrent message processing, destination sort ordering, and persistent messaging.

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 Migrating 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 two 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.

A clustered service is an API or interface that is available on multiple servers in the cluster.

For WebLogic JMS, A system administrator can establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and using targets to assign them to WebLogic Servers. Each connection factory can be deployed on multiple WebLogic 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 server.

The administrator can configure multiple JMS servers on the various nodes in the cluster-as long as each server is uniquely named-and can then assign destinations to the various JMS servers.

In order to use JMS in a clustered environment, you must:

1. Administer WebLogic clusters as described in "Configuring WebLogic Servers and Clusters" in the Administration Guide.

2. Identify server targets for JMS servers and connection factories using the Administration Console. For more information about the configuration attributes, see "Managing JMS" 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.

For more information about starting WebLogic clusters and its features and benefits, see the Using WebLogic Server Clusters.

Note: Automatic failover is not supported for the clustered JMS service for this release. For information about performing a manual failover, refer to Recovering From a WebLogic Server Failure.

Monitoring WebLogic JMS

Statistics are provided for the following JMS objects: JMS servers, connections, sessions, destinations, 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.