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