Skip navigation.

Configuring and Managing WebLogic JMS

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Introduction and Roadmap

The following sections describe the contents and organization of this guide—Configuring and Managing WebLogic JMS.


Document Scope and Audience

This document is a resource for system administrators who configure, manage, and monitor WebLogic JMS resources, including JMS servers, stand-alone destinations (queues and topics), distributed destinations, and connection factories.

The document is relevant to production phase administration, monitoring, and performance tuning. It does not address the pre-production development or testing phases of a software project. For links to WebLogic Server documentation and resources for these topics, see Related Documentation.

It is assumed that the reader is familiar with WebLogic Server system administration. This document emphasizes the value-added features provided by WebLogic Server JMS and key information about how to use WebLogic Server features and facilities to maintain WebLogic JMS in a production environment.


Guide to This Document


Related Documentation

This document contains JMS-specific configuration and maintenance information.

For comprehensive information on developing, deploying, and monitoring WebLogic Server applications:


JMS Samples and Tutorials for the JMS Administrator

In addition to this document, BEA Systems provides JMS code samples and tutorials that document JMS configuration, API use, and key JMS development tasks. BEA recommends that you run some or all of the JMS examples before configuring your own system.

Avitek Medical Records Application (MedRec) and Tutorials

MedRec is an end-to-end sample J2EE application shipped with WebLogic Server that simulates an independent, centralized medical record management system. The MedRec application enables patients, doctors, and administrators to manage patient data using a variety of different clients.

MedRec demonstrates WebLogic Server and J2EE features, and highlights BEA-recommended best practices. MedRec is included in the WebLogic Server distribution, and can be accessed from the Start menu on Windows machines. For Linux and other platforms, you can start MedRec from the WL_HOME\samples\domains\medrec directory, where WL_HOME is the top-level installation directory for WebLogic Platform.

JMS Examples in the WebLogic Server Distribution

This release of WebLogic Server optionally installs API code examples in WL_HOME\samples\server\examples\src\examples, where WL_HOME is the top-level directory of your WebLogic Server installation. You can start the examples server, and obtain information about the samples and how to run them from the WebLogic Server Start menu.

Additional JMS Examples Available for Download

Additional API examples for download at These examples are distributed as ZIP files that you can unzip into an existing WebLogic Server samples directory structure.

You build and run the downloadable examples in the same manner as you would an installed WebLogic Server example. See the download pages of individual examples for more information at


New and Changed JMS Features In This Release

WebLogic Server introduces the following improvements in the configuration, administration, availability, and performance of WebLogic JMS.

Note: If you are not familiar with the new features provided in version 9.0 of WebLogic Server, see the What's New in WebLogic Server 9.0 section of the WebLogic Server Release Notes.

Simplified Configuration and Targeting of JMS System Resources

JMS configurations are stored as modules, which are defined by an XML file that conforms to the weblogic-jmsmd.xsd schema. The configuration of JMS resources in a globally-available system module using the Administration Console, has been simplified so you can choose whether to simply accept pre-selected targets for a resource type or proceed to an advanced targeting page where you can either select an existing subdeployment or create a new one. A subdeployment is a mechanism by which JMS module resources (such as queues, topics, and connection factories) are grouped and targeted to a server resource (such as JMS servers, server instances, or cluster). A module-level subdeployment management page has also been added to allow you to manage the configured subdeployments in JMS system modules.

For more information, see JMS System Module and Resource Subdeployment Targeting.

Message Life Cycle Logging for JMS SAF Destinations

The Store-and-Forward service now includes message life cycle logging for JMS SAF destinations. The Message Life Cycle Logging feature provides an administrator with better transparency about the existence of JMS messages from a JMS server's viewpoint, in particular basic life cycle events, such as message production, consumption, and removal. Logging can occur on a continuous basis and over a long period of time. It can be also be used in real-time mode while the JMS server is running, or in an off-line fashion when a JMS server is down.

For more information, see Troubleshooting WebLogic Store-and-Forward in Configuring and Managing WebLogic Store-and-Forward.

Enhanced Run-time Management for Durable Topic Subscribers and Distributed Queues

New message administration enhancements allow administrators to manage durable topic subscribers and distributed queues using either the Administration Console or through new public runtime APIs. This functionality also provides the ability to view and browse all messages, and to manipulate most messages on durable subscribers and distributed queues. These message management enhancements include message browsing (for sorting), message manipulation (such as move and delete), message import and export.

For more information on managing messages, see Monitoring JMS Statistics and Managing Messages.

Automatic JMS Client Failover

The JMS client reconnect feature provides transparent failover by making JMS client objects individually and collectively refreshable on a network failure. The network connection failure could be due to transient (temporary blip in the network connection) or non-transient (server bounce or network failure) reasons. For release 9.1, refreshable client objects include Destinations, Connections, Sessions, and Producers.

For example, a JMS destination (queue or topic) looked up via JNDI will be re-usable after a network failure without requiring it to be re-looked up. This network failure could be between the JMS client JVM and the remote WebLogic Server it is connected to as part of the JNDI lookup, or between the JMS client JVM and any remote WebLogic server in the same cluster that the client subsequently connects to.

See Automatic Failover for JMS Clients in Programming WebLogic JMS.

Performance Improvements

The following performance enhancing features have been added for release 9.1.

Message Prefetching Available for Synchronous Message Consumers

In WebLogic Server 9.1, synchronous consumers can use the same efficient behavior as asynchronous consumers by enabling the Prefetch Mode for Synchronous Consumers option on the consumer's JMS connection factory using the Administration Console or new APIs. Similar to the asynchronous message pipeline, when the Prefetch Mode is enabled on a connection factory, its targeted JMS server will proactively push batches of unconsumed messages to synchronous message consumers, using the connection factory's Messages Maximum per Session parameter to define the maximum number of prefetched messages per batch.

This may improve performance because messages are ready and waiting for synchronous consumers when the consumers are ready to process more messages, and it may also reduce network traffic by reducing synchronous calls from consumers that must otherwise continually poll for messages.

See Receiving Messages Synchronously in Programming WebLogic JMS.

Improved Tuning of Message Latency or Throughput on Destinations

The Messaging Performance Preference tuning option on JMS destinations enables you to fine-tune message handling by a destination. JMS destinations include internal algorithms that attempt to automatically optimize performance by grouping messages into batches for delivery to consumers. In response to changes in message rate and other factors, these algorithms change batch size and delivery times. However, it is impossible for the algorithms to optimize performance for every messaging environment. The Messaging Performance Preference tuning option enables you to modify how these algorithms react to changes in message rate and other factors so that you can fine-tune performance for your system.

See Tuning Destination Performance.

Deprecated JMS Methods and Interfaces

The following method has been removed for release 9.1:


WebLogic Server Value-Added JMS Features

WebLogic JMS provides numerous WebLogic JMS Extension APIs that go above and beyond the standard JMS APIs specified by the JMS 1.1 Specification. Moreover, it is tightly integrated into the WebLogic Server platform, allowing you to build highly-secure J2EE applications that can be easily monitored and administered through the WebLogic Server console. In addition to fully supporting XA transactions, WebLogic JMS also features high availability through its clustering and service migration features, while also providing seamless interoperability with other versions of WebLogic Server and third-party messaging providers.

The following sections provide an overview of the unique features and powerful capabilities of WebLogic JMS.

Note: For a comprehensive listing of the new WebLogic JMS feature introduced in this release, see New and Changed JMS Features In This Release.

Enterprise-Grade Reliability

Enterprise-Level Features


WebLogic JMS features enterprise-class performance features, such as automatic message paging, message compression, and DOM support for XML messages:

Tight Integration With WebLogic Server

Interoperability With Other Messaging Services


Skip navigation bar  Back to Top Previous Next