Skip Headers
Oracle® Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server
11g Release 1 (10.3.4)

Part Number E13738-04
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Go to next page
View PDF

9 Best Practices for JMS Beginners and Advanced Users

The following sections provide advice and best practices for beginning JMS users as well as advanced JMS users:

Configuration Best Practices

The following sections outline a basic procedure on how to configure JMS applications:

  1. Configure JMS Servers and Persistent Stores.

  2. Configure a JMS Module

  3. Configure JMS Resources

  4. Configure SAF Agents, Stores, and Imported Destination

Configure JMS Servers and Persistent Stores.

Before you start configuring JMS servers and persistent stores, consider the following:

  • Destinations, connection factories, and other JMS resources are configured separately from their host JMS servers and persistent stores. The best practice steps for configuring JMS resources will be described later.

  • If you plan to leverage WebLogic distributed destinations, you will need to configure a WebLogic cluster with a JMS server and a custom persistent store on each WebLogic server in the cluster. WebLogic JMS distributed destination features require a WebLogic cluster to work.

  • Migratable targets are only supported with clusters. If you are not using a cluster, you may want to reconsider and use a cluster of size one. This enables the use of migratable targets, and migratable targets enable a useful restart-in-place capability as mentioned below. This also helps "future-proof" your application, as it simplifies the process of expanding from a single server to multiple servers.

Use the following steps to configure JMS servers and persistent stores:

  1. Create a custom store on each WebLogic server that will host a JMS server. If there's already a custom store on a WebLogic server, you can skip this step as its usually more convenient and more performant for services to share a store. (Why use a custom store? Custom stores provide more flexibility in tuning and administration. In addition, the default file store is not migratable -- only custom stores are migratable.)

  2. In a cluster, target each store to its host server's "default migratable target". If you have decided not to use a cluster, target each store directly to its host server. Migratable targets enable restart-in-place options on a store failure, and also enable service migration options.

    It is recommended to always target to migratable targets when available (instead of direct server targets). Migratable targets are compatible with the whole server migration option, and usually should be configured even when whole server migration is the primary fail-over option.

  3. Configure a JMS server on each WebLogic server. Configure the JMS server to reference the store that was created in step 1. Target the JMS server to the same target that was used for the store. Multiple JMS servers can reference the same store.

  4. Configure message count quotas on each JMS server. There is no default quota, so configuring one helps protect against out-of-memory conditions. Rule of thumb: conservatively assume that each message consumes 512 bytes of memory even if it is paged out.

  5. Although JMS paging is enabled by default, verify that the default behavior is valid for your environment.

Configure a JMS Module

A homogenous set of JMS servers is either a single JMS server that is meant to host non-distributed destinations, or a set of similarly configured JMS servers that each host the same distributed destination. Configure a JMS module and a single associated subdeployment for each homogenous set of JMS servers:

  1. Create a system module. Target it to a single cluster (if using clusters) or a single WebLogic Server instance. You must always target the module even when leveraging subdeployments.

    It is almost always preferable to use system modules instead of deployable application modules. System modules can be created using the administration console, the JMX API (Java MBeans), or WLST, there is no equivalent tooling for deployable modules. The only way to modify deployable modules is to manually edit the XML and redeploy.

  2. Create exactly one subdeployment per module. Subdeployments are sometimes referred to as "advanced targeting" on the administration console. A single subdeployment aids simplicity - it's much easier for third parties to understand the targeting, and it reduces the chances of making configuration errors. If a single subdeployment is not sufficient, create two modules.

  3. Populate the subdeployment only with JMS servers - not WebLogic servers. Only include the JMS servers that you wish to host destinations. This ensures that when the JMS resources are configured, they are targeted to the correct JMS servers. For modules that support non-distributed destinations, the subdeployment must only reference a single JMS Server. If you have a mix of distributed and non-distributed destinations, use two modules each with its own subdeployment.

Configure JMS Resources

Configure your JMS resources and target them properly.

  1. Create destinations and target them to a single subdeployment (called "advanced targeting" on the console). Note that only distributed destinations can be targeted to a subdeployment target that resolves to multiple JMS servers. If you have a mix of distributed destinations, stand-alone destinations, and imported destinations, use two modules each with its own subdeployment. See Targeting Best Practices.

  2. Create and use custom connection factories instead of using default connection factories. Default connection factories are not tunable.

    In most cases, you can use default targeting with connection factories as default targeting causes the resource to inherit the module's target. For connection factories that are only used by remote clients, use the module's subdeployment target.

Configure SAF Agents, Stores, and Imported Destination

SAF agents, their stores, and their imported destinations should follow the same best practices as JMS servers, their stores, and JMS destinations. Avoid targeting a SAF agent at a cluster, as such a SAF agent is not be able to use migratable targets.

Targeting Best Practices

Oracle recommends the following targeting guidelines for JMS resources:

Integration and Multi-Domain Best Practices

The following section provides best practice information for integration and multi-domain environments using WebLogic Server:

Understanding WebLogic JMS Client Options

For client applications (applications that have a runtime environment independent of WebLogic Server) there are multiple JMS client options, including: Java, .NET, and C clients. See "JMS Clients" in Programming Stand-alone Clients for Oracle WebLogic Server.


WebLogic JMS clients do not directly support foreign transaction managers. Use the WebLogic TM if possible. For advanced users, the transaction subsystem Interposed Transaction Manager feature may be used as an XA resource.

Understanding WebLogic URLs

Applications that are communicating with a remote WebLogic Server instance or cluster must specify a URL when creating their JNDI InitialContext objects and/or setting application attributes in order to connect to a server or a cluster.

URL syntax

The WebLogic URL syntax is:



  • address = hostlist : portlist

  • hostlist = hostname [,hostname]...

  • portlist = portrange [+portrange]...

  • portrange = port [-port]

Use port-port to indicate a port range, and + to separate multiple port ranges. For example, a simple address is typically something like t3://hostA:7001; the address t3://hostA,hostB:7001-7002 is equivalent to the following addresses.

  • t3://hostA,hostB:7001+7002

  • t3://hostA:7001-7002,hostB:7001-7002

  • t3://hostA:7001+7002,hostB:7001+7002

  • t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002

Strict Message Ordering Best Practices

If strictly ordered message processing is required, then application design and configuration needs to carefully take this requirement into account.

The simplest and most capable option is to leverage the WebLogic JMS Unit-of-Order feature. This option normally requires minimal or even no changes to applications, plus it works with distributed destinations, scheduled messages, delayed messages, transactions, and store-and-forward. See "Using Message Unit-of-Order" in Programming JMS for Oracle WebLogic Server.

High Availability Best Practices

If High Availability (HA) or scalability is a concern, develop applications so that they leverage clustered WebLogic features. This approach is best taken in the early configuration and application design stage as it is usually difficult process to change a non-clustered application into a clustered application.

In WebLogic JMS, a message is only available if its host JMS server for the destination is running. If a message is in a central persistent store, the only JMS server that can access the message is the server that originally stored the message. WebLogic includes features for automatically restarting and/or migrating a JMS server after a failure. It also includes features for clustering (distributing) a destination across multiple JMS servers within the same cluster.

HA is normally accomplished using both:

Distributed Queues vs Distributed Topics

Distributed queues are generally fairly easy to apply to an arbitrary clustered queueing use case. Distributed topics have a series of fundamental limitations that can restrict their applicability.

JMS Performance and Tuning

The following section provides a link to a checklist of items to consider when tuning WebLogic JMS: