Managing WebLogic JMS

 

  1. Configuring WebLogic JMS
  2. Configuring WebLogic JMS Clustering
  3. Configuring JMS Migratable Targets
  4. Tuning WebLogic JMS
  5. Monitoring WebLogic JMS
  6. Recovering from a WebLogic Server Failure

 

Configuring WebLogic JMS

Using the Administration Console, you define configuration attributes to:

 

Modifying Default Values for Configuration Attributes

WebLogic JMS provides default values for some configuration attributes; 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, WebLogic Server will not boot JMS when you restart it. To see the default values for all configurable JMS attributes, see "Attributes and Console Screen Reference for JMS in the Administration Console Online Help.

A sample examplesJMSServer configuration is provided with the product in the Examples Server. For more information about starting the Examples Server, see "Starting and Stopping Servers: Quick Reference in the Administration Guide.

To configure WebLogic JMS attributes, follow the procedures described in the "Configuring JMS section of the Administration Console Online Help, to create and configure the JMS objects. Once WebLogic JMS is configured, applications can send and receive messages using the JMS API. For more information about developing WebLogic JMS applications, refer to Developing a WebLogic JMS Application.

When migrating from a previous release of Weblogic Server, the configuration information is converted automatically

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

 

Starting WebLogic Server and Configuring JMS

The following sections review how to start WebLogic Server and the Administration Console, as well as provide a procedure for configuring a basic WebLogic JMS implementation.

 

Starting the Default WebLogic Server

The default role for a WebLogic Server is the Administration Server. If a domain consists of only one WebLogic Server, that server is the Administration Server. If a domain consists of multiple WebLogic Server instances, start the Administration Server first, and then you start the Managed Servers.

For complete information about starting the Administration Server, see "Starting and Stopping Servers in the Administration Console Online Help.

 

Starting the Administration Console

The Administration Console is the Web-based administrator front-end (administrator client interface) to WebLogic Server. You must start the server before you can access the Administration Console for a server.

For complete details about using the Administration Console to configure a WebLogic Server instance, see "Starting and Using the Administration Console in Configuring and Managing a WebLogic Server.

 

Manually Configuring a Basic JMS Implementation

This section describes how to configure a basic JMS implementation using the Administration Console.

  1. Under the Services node in the navigation tree, expand the JMS node.

  2. For storing persistent messages in a disk-based file, create a JMS file store. If your are using the JMS Paging feature, also configure an additional "paging" JMS file store for temporarily swapping message bodies out to memory.

    1. Create a directory on the file system where the JMS file store will be kept.

    2. Expand the JMS - > Stores node, and then click the Configure a new JMS File Store link in the right pane.

    3. On the General tab, give the store a name, specify the pathname to the file store directory, and optionally, select a Synchronous Write policy to determine how the JMS file store writes data to disk.

    4. Click Create.

    5. Repeat these steps to create a "paging" JMS file store.

    For more information on configuring a JMS file store and a paging file store, see "JMS File Store Tasks in the Administration Console Online Help.

  3. For storing persistent messages in a JDBC-accessible database, create a JMS JDBC store. (If you need to create a JDBC connection pool, then first complete steps A-C; otherwise, you can skip to step D.)

    1. Click to expand the Services and JDBC nodes.

    2. Right-click the Connection Pools node and select Configure a New JDBC Connection Pool. The JDBC Connection Pool Assistant opens in the right pane.

    3. Follow the directions in "Using the JDBC Connection Pool Assistant to configure a connection pool.

    4. Expand the JMS - > Stores node, and then click the Configure a new JMS JDBC Store link in the right pane.

    5. Give the JDBC Store a name, select a connection pool, and enter a prefix name.

    6. Click Create.

      Note: For more information on configuring JDBC connections pools and JMS JDBC stores, see "JMS JDBC Store Tasks, "JDBC Connection Pools," "JDBC Multipools," and "JDBC DataSources in the Administration Console Online Help.

  4. Optionally, you can create a JMS Template to define multiple destinations with similar attribute settings. You also need a JMS Template to create temporary queues.

    1. Click the Templates node in the left pane, and then click the Configure a new JMS Template link in the right pane.

    2. On the General tab, give the template a name, and then click Create.

    3. Fill in the Thresholds & Quotas, Override, Expiration Policy, and Redelivery tabs, as appropriate. Click Apply on each tab when you are done making changes.

    For more information on configuring a JMS template, see "JMS Template Tasks in the Administration Console Online Help.

  5. Configure a JMS Server, as follows:

    1. Expand the Server node, and then click the Configure a new JMS Server link in the right pane.

    2. On the General tab, give the server a name, select a Store if you created one, select a Paging Store if you created one, and select a Template if you created one. Then click Create.

    3. Fill in the Thresholds & Quotas tab, as appropriate. Click Apply when you are done making changes.

    4. On the Target and Deploy tab, target an independent WebLogic Server instance or a Migratable Target server on which to deploy the JMS server by selecting the appropriate check box, and then click Apply.

    For more information on configuring a JMS server, see "JMS Server Tasks in the Administration Console Online Help.

  6. Create the JMS Destinations, which are queues (Point-To-Point) or topics (Publish/Subscribe):

    1. Under the Servers node, click the new JMS server instance to expand the list, and then click the Destinations node.

    2. Click either the Configure a new JMS Queue or Configure a new JMS Topic link in the right pane.

    3. On the General tab, give the destination a name and a JNDI name. Fill in the other attributes, as appropriate, and then click Create.

    4. Fill in the Thresholds & Quotas, Override, Redelivery, Expiration Policy, and Multicast (for topics only) tabs, as appropriate. Click Apply on each tab when you are done making changes.

    For more information on configuring a JMS destination, see "JMS Destination Tasks in the Administration Console Online Help.

  7. If the default connection factories provided by WebLogic JMS are not suitable for your application, create a new Connection Factory to enable your JMS clients to create JMS connections:

    1. Click to the expand the Connection Factory node and in the left pane, and then click the Configure a new JMS Connection Factory link in the right pane.

    2. On the General tab, give the connection factory a name and a JNDI name. Fill in the other attributes, as appropriate, and then click Create.

    3. Fill in the Transactions and Flow Control tabs, as appropriate. Click Apply on each tab when you are done making changes.

    4. On the Target and Deploy tab, target an independent WebLogic Server instance or a server cluster on which to deploy the connection factory by selecting the appropriate check box, and then click Apply.

    For more information about using the default connection factories, see Using the Default Connection Factories. For more information on configuring a Connection Factory, see "JMS Connection Factory Tasks in the Administration Console Online Help.

  8. As messages revive on a destination, they are sorted in FIFO (first-in, first-out) order by default, which sorts ascending based on each message's unique JMSMessageID. However, if you want to configure a different sorting scheme, use the Destination Keys node to define another sort order (like LIFO, last-in, first-out). For more information, see "JMS Destination Key Tasks in the Administration Console Online Help.

  9. Optionally, use the Distributed Destinations node to make your physical destinations part of a single distributed destination set within a server cluster. For more information, see "Distributed Destinations Tasks in the Administration Console Online Help.

  10. Optionally, create JMS Session Pools, which enable your applications to process messages concurrently, and Connection Consumers (queues or topics) that retrieve server sessions and process messages. For more information, see "JMS Session Pools Tasks and "JMS Connection Consumers Tasks in the Administration Console Online Help.

 

Using the Configuration Wizard to Configure JMS

The Configuration Wizard is a Java application that creates WebLogic Server administration domain and server configurations. You can use the Configuration Wizard to configure such resources as JMS, database connectivity , and security groups, security roles, and user accounts. You can also use the Configuration Wizard to modify existing domains. For more information, see "Configuring a Java Messaging Service in Creating WebLogic Configurations Using the Configuration Wizard.

 

Configuring WebLogic JMS Clustering

A WebLogic Server cluster is a group of servers in a domain 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 four 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.

  • Server affinity - when configured for the cluster, affinity load balancing algorithms (round-robin-affinity, weight-based-affinity, or random-affinity), provide server affinity for JMS client connections. If an JMS application has a connection to a given server instance, JMS will attempt to establish new JMS connections to the same server instance.

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 the features and benefits of using WebLogic clusters, see "Introduction to WebLogic Server Clusters in Using WebLogic Server Clusters.

 

Obtain a Clustered JMS Licence

In order to implement JMS clustering, have a valid clustered JMS license, which allows a connection factory and a destination to be on different WebLogic Server instances. A clustered JMS license is also required to use the Foreign JMS Providers feature If you do not have a valid clustered JMS license, contact your BEA sales representative.

 

How JMS Clustering Works

An administrator can establish cluster-wide, transparent access to JMS destinations from any server in the cluster, either by enabling the default connection factories 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. For information on configuring and deploying connection factories, or about using the default connection factories, see "JMS Connection Factory Tasks in the Administration Console Online Help.

The administrator can also 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 instance. For information on configuring and deploying JMS servers, see "JMS Server Tasks in the Administration Console Online Help.

 

JMS Clustering Naming Requirements

The following guidelines apply when configuring WebLogic JMS to work in a clustered environment in a single WebLogic domain or in a multi-domain environment.

  • All WebLogic Servers that JMS clients contact must have unique server names.

  • All JMS connection factories targeted to servers in a cluster must be uniquely named.

  • All JMS servers targeted to nodes in the cluster must be uniquely named.

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

 

JMS Distributed Destination within a Cluster

The WebLogic JMS administrator can also configure multiple destinations as part of a single distributed destination set within a cluster. Producers and consumers are able to send and receive to the distributed destination. In the event of a single server failure within the cluster, WebLogic JMS then distributes the load across all available physical destinations within the distributed destination set. For more information, see "Distributed Destination Tasks in the Administration Console Online Help.

 

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 Steps

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

  1. Administer WebLogic clusters

  2. Identify server targets for JMS servers and for connection factories using the Administration Console:

    • For JMS servers, you can identify either a single-server target or a migratable target, which is a set of WebLogic 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 targets, see Configuring JMS Migratable Targets.

    • For connection factories, you can identify either a single-server target or a cluster target, which are WebLogic Server instances that are associated with a connection factory to support clustering.

    For more information about these configuration attributes, see "JMS Server Tasks or "JMS Connection Factory Tasks in the Administration Console Online Help.

    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.

  3. Optionally, you can configure your physical destinations as part of a single distributed destination set within a cluster. For more information, see "Distributed Destination Tasks in the Administration Console Online Help.

 

What About Failover?

For WebLogic Server instances that are part of a clustered environment, WebLogic JMS offers service continuity in the event of a single 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 within the cluster.

For more information about the migration of pinned services, 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 weblogic.cluster.Migratable interface, which allows JMS servers to respond to activate and deactivate requests.

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 Migration

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

  1. Administer WebLogic clusters

  2. Configure a candidate migratable target server for the cluster that can potentially host a JMS server

  3. Identify a migratable target server instance on which to deploy a JMS server

    When a migratable target server boots, the JMS server boots as well on the user-preferred server in the cluster. However, a JMS server and all of its destinations can migrate to another server within the cluster in response to a WebLogic Server failure or due to a scheduled migration for maintenance.

    Note: A JMS server and all of its distributed destination members can migrate to another WebLogic Server within a cluster - even when the target WebLogic Server is already hosting a JMS server with all of its distributed destination members. Although this can lead to situations where the same WebLogic server hosts two physical destinations for a single distributed destination, this is permissible in the short term, since the WebLogic Server can host multiple physical destinations for that distributed destination. For more information about JMS distributed destinations, see Using Distributed Destinations.

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

  5. You can manually migrate services 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.

 

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 JDBC Stores in the Administration Console Online Help.

 

Migration Failover

For information about procedures for recovering from a WebLogic Server failure, see Recovering from a WebLogic Server Failure.

 

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 Policy for JMS File Stores - disabling the default "Cache-Flush" policy 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 "Improving JMS File Store Performance in the Administration Console Online Help.

  • Using Message Paging - you can free up virtual memory during peak message load periods. This feature can greatly benefit applications with large message spaces. Message paging saves memory for both persistent and non-persistent messages, as even persistent messages cache their data in memory. Paged persistent messages continue to be written to the regular backing store (file or database); and paged non-persistent messages are written to the JMS server's message paging store, which is configured separately.

    For more information, see "Paging Out Messages to Free Up Memory in the Administration Console Online Help.

  • 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 "Controlling the Flow of Messages on JMS Servers and Destinations in the Administration Console Online Help.

  • Avoiding Quota Exceptions by Blocking Message Producers - the "Blocking Send" features help you to avoid receiving message quota errors by temporarily blocking message producers from sending messages to a destination (queue or topic) when it has exceeded its specified maximum message quota.

    For more information, see "Avoiding Quota Exceptions by Blocking Message Producers in the Administration Console Online Help.

  • Active Expired Message Handling - active message expiration ensures that expired messages are cleaned up immediately. Moreover, expired message auditing gives you the option of tracking expired messages, either by logging when a message expires or by redirecting expired messages to a special destination.

    For more information, see "Handling Expired Messages in the Administration Console Online Help.

  • 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 Console Online Help.

 

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 "Monitoring JMS in the Administration Console Online Help.

Once WebLogic JMS has been configured, applications can begin sending and receiving messages through the JMS API

 

Recovering from a WebLogic Server Failure

 

Programming Considerations

You may want to program your JMS application to terminate gracefully in the event of a WebLogic Server failure. For example:

If a WebLogic Server Instance Fails and...

Then...

You are connected to the failed WebLogic Server instance A JMSException is delivered to the connection exception listener. You must restart the application once the server is restarted or replaced.
A JMS Server is targeted on the failed WebLogic Server instance A ConsumerClosedException is delivered to the session exception listener. You must re-establish any message consumers that have been lost.

 

Migrating JMS Data to a New Server

WebLogic JMS uses the migration framework implemented in the WebLogic Server core, which allows WebLogic JMS respond properly to migration requests and bring a WebLogic 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.

Once properly configured, a JMS server and all of its destination members can migrate to another WebLogic Server within a cluster.

You can recover JMS data from a failed WebLogic Server by starting a new server and doing one or more of the tasks in Table 3-3. Note that there are special considerations when you migrate a service from a server instance that has crashed or is unavailable to the Administration Server. If the Administration Server cannot reach the previously active host of the service at the time you perform the migration, see Migrating a Service When Currently Active Host is Unavailable".

If Your JMS Application Uses. . .

Perform the Following Task. . .

Persistent messaging - JDBC Store

  • If the JDBC database store physically exists on the failed server, migrate the database to a new server and ensure that the JDBC connection pool URL attribute reflects the appropriate location reference.

  • If the JDBC database does not physically exist on the failed server, access to the database has not been impacted, and no changes are required.
Persistent messaging - File Store Migrate the file to the new server, ensuring that the pathname within the WebLogic Server home directory is the same as it was on the original server.
Transactions Migrate the transaction log to the new server by copying all files named <servername>*.tlog. This can be accomplished by storing the transaction log files on a dual-ported disk that can be mounted on either machine, or by manually copying the files.If the files are located in a different directory on the new server, update that server's TransactionLogFilePrefix server configuration attribute before starting the new server.

Note: If migrating following a system crash, it is very important that the transaction log files be available when the server is restarted at its new location. Otherwise, transactions in the process of being committed at the time of the crash might not be resolved correctly, resulting in data inconsistencies.

All uncommitted transactions are rolled back.

Note: JMS persistent stores can increase the amount of memory required during initialization of WebLogic Server as the number of stored messages increases. When rebooting WebLogic Server, if initialization fails due to insufficient memory, increase the heap size of the Java Virtual Machine (JVM) proportionally to the number of messages that are currently stored in the JMS persistent store and try the reboot again.

For information about starting a new WebLogic Server, refer to see "Starting and Stopping Servers in the Administration Console Online Help. For information about recovering a failed server, refer to Recovering Failed Servers in the Configuring and Managing WebLogic Domains guide.

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

Skip navigation bar  Back to Top Previous Next