Configuring and Managing WebLogic JMS
This document is a resource for system administrators responsible for configuring, managing, and monitoring WebLogic JMS resources, such as JMS servers, standalone destinations (queues and topics), distributed destinations, and connection factories.
The topics in this document are relevant to production phase administration, monitoring, or performance tuning topics. This document 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.
In addition to this document, BEA Systems provides a variety of JMS code samples and tutorials that show JMS configuration and API use, and provide practical instructions on how to perform key JMS development tasks. BEA recommends that you run some or all of the JMS examples before configuring your own system.
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 provides a framework for 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.
MedRec includes a service tier comprised primarily of Enterprise Java Beans (EJBs) that work together to process requests from web applications, web services, and workflow applications, and future client applications. The application includes message-driven, stateless session, stateful session, and entity EJBs.
WebLogic Server 9.0 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 9.0 Start menu.
Additional API examples for download at http://dev2dev.bea.com/code/index.jsp. 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
WebLogic Server 9.0 is compliant with the JMS 1.1 Specification for use in production, and so supports unified APIs that work for both queues and topics. For more information, see the Java JMS technology page on the Sun Web site at http://java.sun.com/products/jms/.
JMS configurations in WebLogic Server 9.0 are stored as modules, defined by an XML file that conforms to the
weblogic-jmsmd.xsd schema, similar to standard J2EE modules. An administrator can create and manage JMS modules as global system resources, as modules packaged with a J2EE application (as a packaged resource), or as standalone modules that can be made globally available. With modular deployment of JMS resources, you can migrate your application and the required JMS configuration from environment to environment, such as from a testing environment to a production environment, without opening an enterprise application file (such as an EAR file) or a JMS standalone module, and without extensive manual JMS reconfiguration.
For more information, see Configuring JMS System Resources.
The JMS Store-and-Forward feature is built on the WebLogic Store-and-Forward (SAF) service to provide highly available JMS message production. For example, a JMS message producer connected to a local server instance can reliably forward messages to a remote JMS destination, even though that remote destination may be temporarily unavailable when the message was sent. Persistent JMS messages are always forwarded with Exactly-once quality of service provided by the SAF. For non-persistent JMS messages, applications can also use the At-least-once and At-most-once qualities of service. JMS store-and-forward works with all WebLogic JMS features, including new features introduced in release 9.0.
For more information, see Understanding the Store-and-Forward Service in Configuring and Managing WebLogic Store-and-Forward.
New message administration enhancements greatly enhance a JMS administrator's ability to view and browse all messages, and to manipulate most messages in a running JMS Server, using either the Administration Console or through new public runtime APIs. These message management enhancements include message browsing (for sorting), message manipulation (such as move and delete), message import and export, as well as transaction management, durable subscriber management and JMS client connection management.
For more information on managing messages, see Monitoring JMS Statistics and Managing Messages.
New WebLogic JMS configuration and runtime APIs enable an administrator to pause and resume message production, message insertion (in-flight messages), and message consumption operations on a given JMS destination, or on all the destinations hosted by a single JMS Server, either programmatically or administratively. A potential use of this feature is asserting administrative control of the JMS subsystem behavior in the event of an external resource failure. Otherwise, such a failure could cause the JMS subsystem to ignore the external failures and overload the system (both server and clients) by continuously accepting and delivering (redelivering) messages.
For more information, see Controlling Message Operations on Destinations.
The message life cycle is an external view of the basic events that a JMS message will traverse through once it has been accepted by the JMS server, either through the JMS APIs or the JMS Message Management APIs. Therefore, Message Life Cycle Logging provides an administrator with better transparency about the existence of JMS messages from the JMS server viewpoint, in particular basic life cycle events, such as message production, consumption, and removal.
For more information, see Message Life Cycle Logging.
In Weblogic Server 9.0, the JMS subsystem uses the new system-wide diagnostics service for centralized debug access and logging. With this new service, enabling debugging is easy, and debug and diagnostic information is more readily available so you can easily diagnose and fix problems.
For more information, see Understanding the WebLogic Diagnostic Framework.
The Unit-of-Order feature goes beyond the message delivery ordering requirements in the JMS 1.1 Specification by providing JMS message producers with the ability to group ordered messages into a single unit. This single unit is called a Unit-of-Order and it guarantees that all messages created from that unit are processed sequentially in order by the same consumer until that consumer acknowledges them or it is closed. For example, if a queue has messages with many consumers, and each message has an account number as a Unit-of-Order, then two consumers will not process messages with the same account number at the same time. A Unit-of-Order can be created programmatically with new JMS API extensions to the JMSMessageProducer interface, or administratively by specifying a Unit-of-Order on a connection factory.
For more information, see Using Message Unit-of-Order in Programming WebLogic JMS.
This release of WebLogic Server introduces a new type of distributed destination, termed Uniform Distributed Destination, that greatly simplifies the management and development of distributed destination applications. By using the Uniform Distributed Destination feature, the administrator no longer needs to create or designate destination members, but relies on the system to uniformly create the necessary members on the JMS servers to which a JMS module is targeted. This feature ensures the consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas. The Weighted Distributed Destination feature is still available for those who want to manually fine-tune distributed destination members.
For more information, see Configuring Distributed Destinations.
The Weblogic JMS C API enables programs written in "C" to participate in JMS applications. This implementation of the JMS C API uses JNI in order to access a Java Virtual Machine (JVM). The JMS C API does not support WebLogic JMS extensions, JMS Object messages, and Java MBean management.
For more information, see WebLogic C API in Programming WebLogic JMS.
MDB enhancements enable support for transaction batching (via processing multiple messages in a single transaction), and for load balancing MDB instances across member destinations in different clusters or domains, regardless of whether the MDB and destination reside in the same cluster or in different clusters or domains.
For more information, see Message-Driven Bean Enhancements in the Release Notes.
This feature enhances the WebLogic JMS API to provide native support for the Document Object Model (DOM) when sending XML messages. This will greatly improve performance for implementations that already use a DOM, since those applications will not have to flatten the DOM before sending XML messages.
For more information, see Sending XML Messages in Programming WebLogic JMS.
The new destination quota objects for JMS modules allows administrators to configure named quota objects and then have destinations refer to them. To increase flexibility, destinations can be assigned their own quotas; multiple destinations can share a quota; or destinations can share the JMS server's quota. In addition, a destination that defines its own quota now no longer also shares space in the JMS server's quota. JMS servers still allow the direct configuration of message and byte quotas. However, these attributes are only used to provide quota for destinations that do not refer to a quota object.
For more information, see Defining Quota.
The message paging feature for freeing up virtual memory during peak message load situations is always enabled on JMS servers. Additionally, administrators no longer need to create a dedicated message paging store since paged out messages can be stored in a directory on your file system. However, for the best performance you should specify that messages be paged to a directory other than the one used by the JMS server's persistent store.
For more information, see Paging Out Messages To Free Up Memory.
This enhancement introduces the JMSXUserID property, which provides the ability to identify the user who produced a message when the message is received. With this property, the recipient has the option of querying the message property to find out who sent the message, and then could possibly run different logic in the application, depending on who the initiator was. The message sender requests the user identity by using a connection factory with the AttachJMSXUserID attribute enabled. The delivery of the user identity is controlled by the Attach Sender value on destinations, which can also be managed for multiple destinations by using a JMS template.
For more information, see "Configuring and Managing a Messaging Bridge" in Configuring and Managing WebLogic Messaging Bridge.
This feature enables the compression of messages that exceed a specified threshold size to improve the performance of sending messages travelling across JVM boundaries. A threshold can be set programmatically using a new JMS API extension to the JMSMessageProducer interface, or administratively by either specifying a value on a connection factory or on a SAF remote context. Once configured, message compression is triggered on producers for message sends, on connection factories for message receives and message browsing, or through SAF forwarding.
For more information, see Compressing Messages.
The new module-based method of configuring WebLogic JMS resources uses Java Descriptor Bean interfaces to create JMS system modules and deployable packaged modules. This fundamental change necessitated the deprecation of the following MBean interfaces:
For more information about JMS module resources, see What Are JMS Configuration Resources?.
This class has been replaced by a new JMSModuleHelper class with methods for managing (locate/create/delete) JMS Module configuration resources (descriptor beans) in a given JMS module (including the JMS Interop Module), and for locating JMS runtime MBeans.
For more information on using the JMS module helper methods, see the JMSModuleHelper Javadoc.
The new simplified JMS Paging configuration necessitated the deprecation of the BytesPagingEnabled and MessagesPagingEnabled attributes of the JMSTemplateMBean, JMSDestinationMBean, and JMSServerMBean interfaces.
For more information, see Paging Out Messages To Free Up Memory.
The JMSSessionPoolMBean (and its associated methods on the JMSServerMBean) and JMSConnectionConsumerMBean interfaces have been deprecated. These interfaces were used to automatically create a JMS session pool and start the JMS consumers on the server side.
For more information on designing MDBs, see Message-Driven EJBs in Programming WebLogic Enterprise JavaBeans.
For more information, see Using The WebLogic Persistent Store in Configuring WebLogic Server Environments.
The new "Pause and Resume JMS Destinations" feature necessitated the deprecation of the
isPaused() APIs on the JMSDestinationRuntimeMBean interface. A new set of Pause/Resume APIs have been introduced to the JMSDestinationRuntimeMBean and JMSServerRuntimeMBean interfaces.
For more information, see "JMSMessageManagementRuntimeMBean" in the WebLogic Server MBean Reference.
For more information on using these WLMessage extensions, see the JMS WLMessage Extension Javadoc.
Thread Pool Size property for a server instance has been deprecated. Use the common thread pool or a work manager. See Change the Thread Pool Size in Configuring and Managing the WebLogic Messaging Bridge