This chapter describes the new cluster-targeting enhancements and how they simplify the JMS configuration process. These enhancements make the JMS service dynamically scalable and highly available without the need for an extensive configuration process in a cluster or WebLogic Server Multitenant environment.
This chapter includes the following sections:
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 Dynamic Cluster Size attribute for the cluster configuration is 0. See Clusters: Configuration: Servers in the Oracle WebLogic Server Administration Console Online Help. This type of cluster is also known as a Static Cluster.
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 Dynamic Cluster Size 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 manually configured (Configured servers). Because a mixed cluster contains dynamic servers, the value of the Dynamic Cluster Size attribute in the Clusters: Configuration: Servers tab of the cluster configuration is greater than 0.
For more information about using dynamic servers, see:
The clustered JMS service has the ability to target JMS service artifacts (such as JMS Server, SAF Agent, and Path Service) and optional associated persistent stores to the same cluster. Messaging Bridge is also a JMS artifact that does not use a Store, but it can be targeted to a cluster.(Required) Enter introductory text here, including the definition and purpose of the concept.
For JMS service artifacts that are configured to be distributed across the cluster, depending on the Distribution Policy, when each new server starts, the cluster can automatically start one instance of the artifact (and associated store if applicable) on each cluster member and that member is called the preferred server for that instance. For artifacts that are not distributed, the system will select a server in the cluster to start a single instance of that artifact. See Simplified JMS Configuration and High Availability Enhancements.
In the case of a dynamic or a mixed cluster, the number of instances automatically grow when the cluster size grows. To dynamically scale the size of the dynamic or mixed cluster or the dynamic servers of the mixed cluster, adjust the dynamic cluster Size attribute in the Clusters: Configuration: Servers tab of your cluster configuration.
Figure 5-1 shows the relationship between the JMS and a dynamic cluster configuration in the
Figure 5-1 Dynamic Clustered JMS
Using Custom Persistent Stores with Cluster-Targeted JMS Service Artifacts
The custom persistent store used by the JMS service artifacts must be targeted to the same cluster with appropriate attribute values configured to take advantage of cluster enhancements. However, cluster-targeted SAF Agents and JMS Servers can also continue to use the default store available on each cluster member, which does not offer any of the new enhancements discussed in this chapter. See Simplified JMS Configuration and High Availability Enhancements.
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 or SAF Agents for hosting regular destinations or imported destinations respectively. Using a cluster-targeted JMS Server or a SAF Agent in a subdeployment eliminates the need to individually create and enumerate the JMS Servers or SAF Agents in the subdeployment, which is particularly useful for Uniform Distributed Destination and imported destination deployment.
Note:A module or its subdeployments cannot be directly targeted to a Dynamic cluster member server.
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.
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.
A module or its subdeployments cannot be directly targeted to a Dynamic cluster member.
WebLogic Server supports high availability for JMS service artifacts deployed in a cluster. Both server and service failure scenarios are handled by automatically migrating an artifact's instance to other running servers. During this process, the system evaluates the overall server load and availability and moves the instances accordingly.
Cluster-targeting enhancements in this release of WebLogic Server eliminates many of the limitations that existed in the previous releases:
In the previous releases, only JMS servers, persistent stores, and SAF Agent (partially) were allowed to target to a cluster. In this release, the support is extended for all of the JMS service artifacts including SAF Agents, path service, an messaging bridges and for all types of clusters (Configured, Mixed, and Dynamic).
Enhancements in this release lets you easily configure and control the distribution behavior, as well as the JMS high availability (also known as JMS automatic service migration) behavior for all cluster targeted JMS Service artifacts. All of these configurations now exist in a single location, which is a Persistent Store for all the artifacts that depend on that store, or on the messaging bridge (which does not use the Store). This eliminates the need for migratable targets that were used in the previous releases.
Because the logical JMS artifacts are targeted to clusters, the system automatically creates any "physical" instances required on a cluster member when it joins the cluster. This allows the JMS Service to automatically scale up when the cluster size grows. With optional high availability configuration, the "physical" instances can restart or migrate in the event of service failure or server failure or shutdown, making the JMS Service highly available with minimal configuration.
The primary attributes that control the scalability and high availability behavior are Distribution policy and Migration policy. In addition to these policies, there are a few additional attributes that can be used for fine-tuning the high availability behavior such as restarting the instance in place (on the same server) before attempting to migrate elsewhere. These policies and attributes are described in the following sections:
The Distribution Policy setting for a custom persistent store or messaging bridge determines how the associated JMS Service artifacts (JMS Server, SAF Agent, and Path Service) are distributed in a cluster and the same setting on the Messaging Bridge determines its distribution behavior.
Note:The Distribution Policy is the default value for this policy. It is also required for cluster-targeted SAF Agents and cluster-targeted JMS Servers that host Uniform Distributed Destinations (UDD).
This option is the default policy and it is also required for cluster-targeted SAF Agents and cluster-targeted JMS Servers that host Uniform Distributed Destinations (UDD).
Singleton: In this mode, a JMS server or a path service has one instance per cluster.
Note:This option is required for path service and cluster-targeted JMS servers that host singleton or standalone (non-distributed) destinations.
For more information about the Distribution Policy, see JDBC Store: HA Configuration in the Oracle WebLogic Server Administration Console Online Help
The Migration Policy controls migration and restart behavior of cluster-targeted JMS service artifact instances. For high availability and service migration, set the migration policy as follows on the associated store:
Off: This option disables both migration and restart in place.
Always: This option enables the system to automatically migrate instances in all situations. This includes administrative shutdown, crashes or bad health of the hosting server or subsystem service. This option also enables service migration, which automatically restarts a failing Store on the current hosting server or migrates it to another server based on its restart-in-place configuration.
To enable support for cluster-targeted JMS Service artifacts with the Always or On-Failure migration policy, you must configure Cluster Leasing. For more information, see Leasing in Administering Clusters for Oracle WebLogic Server.
JMS Service Migration and JTA Migration work independently based on their Migration Policy. For information on Dynamic Clusters and JTA migration policies, see Understanding the Service Migration Framework.
It is a best practice to use the Database Leasing option instead of Consensus Leasing.
When a distributed instance is migrated from its preferred server, it will try to fail back when the preferred server is restarted.
For more information about Migration Policy, see JDBC Store: HA Configuration in Oracle WebLogic Server Administration Console Online Help
Table 5-1 Configuration Properties for JMS Service Migration
Restart In Place
Defines how the system responds on a JMS Service failure within a healthy WebLogic Server. If a service fails and if this property is enabled, then the system first attempts to restart that store and associated service artifact on the same server before migrating to another server.
Note:This attribute does not apply when an entire server fails.
Seconds Between Restarts
If Restart In Place is enabled, then his property specifies the delay, in seconds, between restarts on the same server.
Number of Restart Attempts
If Restart In Place is enabled, then this number determines the restart attempts the system should make before trying to migrate the artifact instance to another server.
Initial Boot Delay Seconds
Controls how fast subsequent instances are started on a server after the first instance is started. This prevents the system getting overloaded at the startup.
A value of 0 indicates that the system does not need to wait, which may lead to overload situations. The system’s default value is 60 seconds.
Failback Delay Seconds
Specifies the time to wait before failing back an artifact's instance to its preferred server.
A value > 0 specifies that the time, in seconds, to delay before failing a JMS artifact back to its preferred server.
A value of 0 indicates that the instance would never failback.
A value of -1 indicates that there is no delay and the instance would failback immediately.
Partial Cluster Stability Seconds
Specifies the amount of time, in seconds, to delay before a partially started cluster starts all cluster-targeted JMS artifact instances that are configured with a Migration Policy of Always or On-Failure.
This delay ensures that services are balanced across a cluster even if the servers are started sequentially.
A value > 0 specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.
A value of 0 specifies no delay in starting all the instances on available servers.
The default delay value is 240 seconds.
For more information about these properties, see JDBC Store: HA Configuration in the Oracle WebLogic Server Administration Console Online Help.
The following limitations and other behavior provides information on limitations and other behaviors you should consider before developing applications using dynamic clusters and 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 is hosted on a mixed or dynamic cluster. See Best Practices for Using Clustered JMS Services.
WLST Offline does not support the
assign command to target JMS servers to a dynamic cluster. Use the
Weighted distributed destinations (a deprecated 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.
Custom persistent store with "Singleton" Distribution Policy, and "Always" (Or On-Failure) Migration Policy is required for cluster targeted JMS Server to allow Standalone destinations.
There is no support for manually (administratively) forcing the migration or fail-back of a service instance that is generated from a cluster-targeted JMS artifact.
A path service must be configured if there are any distributed or imported destinations that are used to host Unit-of-Order (UOO) messages. In addition, such destinations need to be configured with a path service UOO routing policy instead of the default hashed UOO routing policy because hash-based UOO routing is not supported in cluster-targeted JMS.
Attempts to send messages to a distributed or imported destination that is hosted on a cluster-targeted JMS Service will fail with an exception.
Note that a cluster-targeted path service must be configured to reference a Store that has a Singleton Distribution Policy and an Always Migration Policy.
The following section provides information about 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 is hosted on a Mixed or Dynamic cluster. See Best Practices for Using Clustered JMS Services.
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 migratable target-based service migration of JMS services is supported on a Configured Cluster.
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 an target a single manually configured WebLogic Server or to a single migratable target or to a Cluster.
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, delete the destinations that are hosted on a cluster targeted JMS server before shutting down the WebLogic Server instance. For example:
Pause the individual destination for production.
Let the applications delete the destinations.
Shut down the server instance.
Use cluster targeted stores instead of default stores for clustered targeted JMS servers and SAF Agents.
When enabling high availability (that is, when the Migration Policy on the store is set to either On-Failure or Always), ensure that cluster leasing is configured. As a best practice, database leasing is preferred over consensus leasing. For more information, see Leasing in Administering Clusters for Oracle WebLogic Server.
When configuring destinations in a module, use a subdeployment that targets a specific clustered JMS server or SAF agent instead of using default targeting. This ensures that the destination creates members on exactly the desired JMS server instances.
Exactly-Once QOS Level SAF agents and SAF clients, as a best practice, ensure that Stores associated with the SAF Agents are configured with the migration-policy set to Always.
Also, in the event of change in the cluster size (particularly when shrinking), ensure that the backing tables (in case of JDBC store) or files (in case of FILE store) are not deleted or destroyed, so that they can be migrated over to any available cluster members for continuous availability of the SAF service.
The runtime MBean associated with each of the JMS artifacts (such as Persistent store, JMS server, SAFAgent, MessagingBridge and PathService) distributed in a cluster are named based on the distribution policy set. This is enforced by a MBean check.
Distributed — Instances are automatically created and named uniquely by naming them after their home or preferred host WebLogic Server the first time when the WebLogic Server boots . The format is <
01”. The format is <
configured-name>–01. No server name is added to this instance name.
The following sections brief about the Instance Naming Syntax for persistent store:
In case of file stores (.DAT files) that are targeted to a cluster, an instance’s data files are uniquely named based on the corresponding store instance name. For example, in Distributed mode, an instance's files will be names as
<Store name>@<Server instance name>
NNNNNN.DAT, where <
NNNNNN> is a number ranging from 000000–999999.
Note:A single file instance may create one or more .DAT files.
A replicated store’s instance regions targeted to a cluster, are uniquely named based on the corresponding store instance name. For example, in distributed mode, a replicated store’s instance will contain the syntax of
<configured Replicated Store name>@<Server instance name>
NNNNNN.RGN, where <
NNNNNN> is a number ranging from
Table 5-2 JDBC Store Table Name Syntax for Cluster Targeted Case
|Default Name||PrefixName||Distribution Policy||Instance Name||Store Table Name|
|myPrefix. (ends with ‘.’)||Distributed||myServer||myPrefix._myServer_WLStore|
Table 5-3 Non-Cluster (single-server) TargetedCase
|Default Name||Prefix Name||Distribution Policy||Instance Name||Store Table Name|