JMS

WebLogic Server JMS architecture allows multiple JMS servers to be created in a WebLogic domain. But each JMS server can only be instantiated (targeted) on one WebLogic Server as it is an "exactly-once" service. Multiple destinations can be hosted on a JMS Server. Persistent storage (disk-based file or JDBC-accessible database) can be configured for storing persistent message data.
If one JMS store must be shared across multiple destinations, configure multiple destinations to reside on one JMS server. But to use separate persistent stores for each destination, create them under multiple JMS servers.

Tips

1.Enabling a direct-write synchronous write policy for the JMS file store frees the virtual-memory (VM) heap, but direct-write can significantly improve performance only if there are few concurrently active JMS clients.

2.Isolate file stores on separate disks, or even on separate disk controllers.

3.To make the file store highly available, you can use Storage Area Network (SAN), a multi-ported disk, or disk-mirroring technology.

4.Do not associate a connection pool that uses an XA JDBC driver with a JMS JDBC store, because JMS JDBC store does not support XA resource drivers (WebLogic JMS implements its own XA resource).

5.Using Expiration Scan Interval to scan destinations for expired messages frees up VM, but too-frequent scanning can increase scanning overhead; ensure that you tune this optimally.

6.Set MessagesMaximum on connection factories, to tune the size of asynchronous message pipelines.

7.To avoid message buildup, set the Time To Live attribute, at the connection factory level.

8.Disable default JMS connection factories; configure application-specific JMS connection factories for production.

9.For load-balancing JMS messages across physical destinations that are configured in different JMS servers, configure a distributed destination.

10.When deploying distributed destinations, use similar settings for each JMS server and member destination in a cluster.