5 Simplified JMS Cluster Configuration

This chapter describes new cluster targeting options in WebLogic Server 12.1.3 that simplify the configuration process and allow applications to more easily scale WebLogic Messaging resources, such as JMS servers and persistent stores.

Cluster targeted JMS servers and persistent stores eliminate the need to individually configure many JMS resource artifacts for every server in a cluster by allowing the targeting of the resource artifacts directly to the cluster.

This chapter includes the following sections:

What are the WebLogic Clustering Options for JMS?

A WebLogic Cluster may contain individually configured servers, dynamically generated servers, or a mix of both. WebLogic Server has the following cluster types:

  • Configured: A cluster where each member server is individually configured and individually targeted to the cluster. The value of the Maximum Number of Servers attribute in the Clusters: Configuration: Servers tab of the cluster configuration is 0.

  • Dynamic: A cluster where all the member servers are created using a server template. These servers are referred to as dynamic servers. The value of the Maximum Number of Servers attribute in the Clusters: Configuration: Servers tab of the cluster configuration is greater than 0.

  • Mixed: A cluster where some member servers are created using a server template (Dynamic servers) and the remaining servers are individually configured (Configured servers). Because a mixed cluster contains dynamic servers, the value of the Maximum Number of Servers attribute in the Clusters: Configuration: Servers tab of the cluster configuration is greater than 0.

For more information on using dynamic servers, see:

What is Simplified JMS Cluster Configuration

The Clustered JMS Servers is the ability to target a JMS server and optional associated persistent store to the same cluster. During cluster startup, the cluster automatically starts one instance of the JMS server (and associated store if applicable) on each cluster member.

If targeted to a Dynamic cluster or a Mixed cluster, you can dynamically scale WebLogic JMS resources of the Dynamic cluster or the Dynamic servers of the Mixed cluster by adjusting the Maximum Number of Servers attribute in the Clusters: Configuration: Servers tab of your cluster configuration.

Figure 5-1, "Dynamic Clustered JMS" shows the relationship between the JMS and a Dynamic cluster configuration in the config.xml file.

Figure 5-1 Dynamic Clustered JMS

Description of Figure 5-1 follows
Description of ''Figure 5-1 Dynamic Clustered JMS''

Using Persistent Stores with Cluster Targeted JMS Servers

The persistent store associated with a Cluster Targeted JMS server can be a custom persistent store that is targeted to the same cluster or the default store available on each cluster member.

Targeting JMS Modules Resources

JMS system modules continue to support two types of targeting, either of which can be used to take advantage of simplified cluster configuration.

  • Any default targeted JMS resource in a module (a JMS resource that is not associated with a subdeployment), inherits the targeting of its parent module, and the parent module can be targeted to any type of cluster.

  • Module subdeployment targets can reference clustered JMS servers. Using a cluster targeted JMS server in a subdeployment eliminates the need to individually enumerate individual JMS servers in the subdeployment, which is particularly useful for uniform distributed destination deployment.

See Targeting Best Practices.

Note:

A module or its subdeployments cannot be directly targeted to a Dynamic cluster member.

Considerations and limitations of Clustered JMS

The following section provides information on limitations and other behaviors you should consider before developing applications using dynamic clusters and cluster targeted JMS servers.

  • Automatic Service Migration (ASM) is not supported for cluster targeted JMS servers or stores.

  • Unit-of-Order (UOO) and Unit-of-Work (UOW) are not supported by cluster targeted JMS servers. UOO is supported in a Configured cluster or stand-alone WebLogic Server instance when all JMS servers that host the UOO's destination are directly targeted to a server instance or migratable target. UOO is not supported with destinations that are fully or partially hosted on Clustered JMS servers.

  • Store-and-Forward (SAF) Agents cannot be targeted to a Dynamic or Mixed cluster. You can target SAF Agents to Configured clusters using the default store.

  • There are special considerations when a SAF Agent imported destination with an Exactly-Once QOS Level forwards messages to a distributed destination that is hosted on a Mixed or Dynamic cluster. See Store-and-Forward to Cluster Targeted JMS Servers.

  • WLST Offline does not support the assign command to target JMS servers to a dynamic cluster. Use the get and set command.

  • Singleton destinations (queues and topics) are not directly supported on cluster targeted JMS servers.

    If a singleton destination is required, configure and use a non-cluster targeted JMS server, or apply one of the following workarounds:

    • Directly reference a member of a distributed destination using one of the methods described in See "How to Lookup a Destination" in Developing JMS Applications for Oracle WebLogic Server.

    • Use a foreign JMS server and destination to indirectly reference a distributed destination member.

  • Weighted distributed destinations (a type of distributed destination composed of a group of singleton destinations), are not supported on cluster targeted JMS servers.

  • Replicated distributed topics (RDTs) are not supported when any member destination is hosted on a cluster targeted JMS server.

  • AQ-JMS integration is not supported in a mixed or dynamic cluster. No exception is thrown when this is attempted. See Interoperating with Oracle AQ JMS.

  • Targeting a messaging bridge to a mixed or dynamic cluster is not supported. No exception is thrown when this is attempted (see "JMS Issues and Workarounds" in Release Notes for Oracle WebLogic Server Release Notes).

Interoperability and Upgrade Considerations of Cluster Targeted JMS Servers

The following section provides information on interoperability and upgrade considerations when using cluster targeted JMS servers:

  • JMS clients, bridges, MDBs, SAF clients, and SAF agents from previous releases can communicate with cluster targeted JMS servers.

  • There are special considerations when a SAF Agent imported destination with an Exactly-Once QOS Level forwards messages to a distributed destination that's hosted on a Mixed or Dynamic cluster. See Store-and-Forward to Cluster Targeted JMS Servers.

  • No conversion path is available for moving data (messages) or configurations from non-cluster targeted JMS servers to cluster targeted JMS servers, or vice versa.

The service migration of cluster targeted JMS server and store instances between WebLogic Servers is not supported, including Restart in Place. The same restrictions hold for singleton JMS server or store instances in a mixed cluster. However, the migration of migratable target targeted JMS servers and stores continues to be supported in configured clusters.

For example, a messaging configuration for JMS servers and persistent stores can target a single manually configured WebLogic Server or to a single Migratable Target. Similarly, SAF Agents can target a single manually configured WebLogic Server or to a single Migratable Target or to a Cluster.

See Automatic Migration of JMS Services.

Store-and-Forward to Cluster Targeted JMS Servers

Exactly-Once QOS Level SAF agents and SAF clients cannot safely forward to JMS servers hosted in Dynamic or Mixed clusters unless either:

  • The number of dynamic JMS servers does not permanently shrink.

  • All messages are drained from SAF prior to permanently shrinking the number of dynamic JMS servers. To shrink:

    • Exactly-Once Level SAF Agents and SAF clients that forward to Dynamic destinations need to be shutdown cleanly before shrinking a remote Dynamic cluster.

    • Restart the SAF Agents or Client after the Dynamic cluster is restarted. Failure to do so risks a condition where SAF Agent messages become stuck in attempts to forward them to the destinations that were removed during the shrink.

Failure to take these precautions can result in messages being stranded in the Exactly-Once Level SAF Agent or SAF Client when the remote cluster shrinks. See Best Practices for Using Clustered JMS Servers.

Best Practices for Using Clustered JMS Servers

The following section provides information on best practices and design patterns:

  • Prior to decreasing the size of a Dynamic cluster or decreasing the number of Dynamic cluster members in a Mixed cluster, drain the destinations that are hosted on a cluster targeted JMS server before shutting down the WebLogic Server instance. For example:

    1. Pause the individual destination for production.

    2. Let the applications drain the destinations.

    3. Shut down the server instance.

  • Use cluster targeted stores instead of default stores for clustered targeted JMS servers.

  • When configuring destinations in a module, use a subdeployment that targets a specific clustered JMS server instead of using default targeting. This ensures that the destination creates members on exactly the desired JMS server instances.

  • If you have Exactly-Once QOS Level SAF agents and SAF clients that forward to JMS servers hosted in Dynamic or Mixed clusters, see Store-and-Forward to Cluster Targeted JMS Servers.