9
Best Practices for JMS Beginners and Advanced Users 9-1
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:
■
Section 9.1, Configuration Best Practices
■
Section 9.2, Targeting Best Practices
■
Section 9.3, Integration and Multi-Domain Best Practices
■
Section 9.4, Understanding WebLogic JMS Client Options
■
Section 9.5, Understanding WebLogic URLs
■
Section 9.6, Strict Message Ordering Best Practices
■
Section 9.7, High Availability Best Practices
■
Section 9.8, JMS Performance and Tuning
9.1 Configuration Best Practices
The following sections outline a basic procedure on how to configure JMS applications:
1.
Section 9.1.1, Configure JMS Servers and Persistent Stores.
2.
Section 9.1.2, Configure a JMS Module
3.
Section 9.1.3, Configure JMS Resources
4.
Section 9.1.4, Configure SAF Agents, Stores, and Imported Destination
9.1.1 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
9-2 Configuring and Managing JMS for Oracle WebLogic Server
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 theres 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 servers 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.
9.1.2 Configure a JMS Module
