Administration Console Online Help

Replicated Store: HA Configuration

Configuration Options     Related Tasks     Related Topics

Use this page to configure high availability (HA) settings for a cluster-targeted replicated store.

Configuration Options

Name	Description
Distribution Policy	Specifies how the instances of a configured JMS artifact are named and distributed when cluster-targeted. A JMS artifact is cluster-targeted when its target is directly set to a cluster, or when it is scoped to a resource group and the resource group is in turn targeted to a cluster. When this setting is configured on a store, it applies to all JMS artifacts that reference the store. Valid options: Distributed Creates an instance on each server JVM in a cluster. Required for all SAF agents and for cluster-targeted or resource-group-scoped JMS servers that host distributed destinations. Singleton Creates a single instance on a single server JVM within a cluster. Required for cluster-targeted or resource-group-scoped JMS servers that host standalone (non-distributed) destinations and for cluster-targeted or resource-group-scoped path services. The Migration Policy must be On-Failure or Always when using this option with a JMS server, On-Failure when using this option with a messaging bridge, and Always when using this option with a path service. Instance Naming Note: The DistributionPolicy determines the instance name suffix for cluster-targeted JMS artifacts. The suffix for a cluster-targeted Singleton is -01 and for a cluster-targeted Distributed is @ClusterMemberName. Messaging Bridge Notes: When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Distributed/Off, respectively; these are the defaults. When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Singleton/On-Failure, respectively. If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the Migration Policy on the migratable target to Exactly-Once. MBean Attribute: DynamicDeploymentMBean.DistributionPolicy Changes take effect after you redeploy the module or restart the server.
Migration Policy	Controls migration and restart behavior of cluster-targeted JMS service artifact instances. When this setting is configured on a cluster-targeted store, it applies to all JMS artifacts that reference the store. See the migratable target settings for enabling migration and restart on migratable-targeted JMS artifacts. Off Disables migration support for cluster-targeted JMS service objects, and changes the default for Restart In Place to false. If you want a restart to be enabled when the Migration Policy is Off, then Restart In Place must be explicitly configured to true. This policy cannot be combined with the Singleton Migration Policy. On-Failure Enables automatic migration and restart of instances on the failure of a subsystem Service or WebLogic Server instance, including automatic fail-back and load balancing of instances. Always Provides the same behavior as On-Failure and automatically migrates instances even in the event of a graceful shutdown or a partial cluster start. Note: Cluster leasing must be configured for On-Failure and Always. Messaging Bridge Notes: When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Distributed/Off, respectively; these are the defaults. When a single instance per cluster is desired for a cluster-targeted bridge, Oracle recommends setting the bridge Distributed Policy and Migration Policy to Singleton/On-Failure, respectively. A Migration Policy of Always is not recommended for bridges. If you cannot cluster-target a bridge and still need singleton behavior in a configured cluster, you can target the bridge to a migratable target and configure the Migration Policy on the migratable target to Exactly-Once. MBean Attribute: DynamicDeploymentMBean.MigrationPolicy Changes take effect after you redeploy the module or restart the server.
Restart In Place	Enables a periodic automatic in-place restart of failed cluster-targeted or standalone-server-targeted JMS artifact instance(s) running on healthy WebLogic Server instances. See the migratable target settings for in-place restarts of migratable-targeted JMS artifacts. When the Restart In Place setting is configured on a store, it applies to all JMS artifacts that reference the store. If the Migration Policy of the JMS artifact is set to Off, Restart In Place is disabled by default. If the Migration Policy of the JMS artifact is set to On-Failure or Always, Restart In Place is enabled by default. This attribute is not used by WebLogic messaging bridges which automatically restart internal connections as needed. For a JMS artifact that is cluster-targeted and the Migration Policy is set to On-Failure or Always, if restart fails after the configured maximum retry attempts, it will migrate to a different server within the cluster. MBean Attribute: DynamicDeploymentMBean.RestartInPlace Changes take effect after you redeploy the module or restart the server.
Seconds Between Restarts	Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance. MBean Attribute: DynamicDeploymentMBean.SecondsBetweenRestarts Minimum value: 1 Changes take effect after you redeploy the module or restart the server.
Number Of Restart Attempts	Specifies the maximum number of restart attempts. A value > 0 specifies the maximum number of restart attempts. A value of 0specifies the same behavior as setting RestartInPlace tofalse. A value of -1 means infinite retry restart until it either starts or the server instance shuts down. MBean Attribute: DynamicDeploymentMBean.NumberOfRestartAttempts Minimum value: -1 Changes take effect after you redeploy the module or restart the server.
Initial Boot Delay Seconds	Specifies the amount of time, in seconds, to delay before starting a cluster-targeted JMS instance on a newly booted WebLogic Server instance. When this setting is configured on a store, it applies to all JMS artifacts that reference the store. This allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot. A value > 0 is the time, in seconds, to delay before before loading resources after a failure and restart. A value of 0 specifies no delay. Note: This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to On-Failure or Always. MBean Attribute: DynamicDeploymentMBean.InitialBootDelaySeconds Changes take effect after you redeploy the module or restart the server.
Failback Delay Seconds	Specifies the amount of time, in seconds, to delay before failing a cluster-targeted JMS artifact instance back to its preferred server after the preferred server failed and was restarted. This delay allows time for the system to stabilize and dependent services to be restarted, preventing a system failure during a reboot. A value > 0 specifies the time, in seconds, to delay before failing a JMS artifact back to its user 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. Note: This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to On-Failure or Always. MBean Attribute: DynamicDeploymentMBean.FailbackDelaySeconds Changes take effect after you redeploy the module or restart the server.
Partial Cluster Stability Delay 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. Before this timeout expires or all servers are running, a cluster starts a subset of such instances based on the total number of servers running and the configured cluster size. Once the timeout expires or all servers have started, the system considers the cluster stable and starts any remaining services. This delay ensures that services are balanced across a cluster even if the servers are started sequentially. It is ignored after a cluster is fully started (stable) or when individual servers are started. 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. MBean Attribute: PersistentStoreMBean.PartialClusterStabilityDelaySeconds Changes take effect after you redeploy the module or restart the server.
Fail Over Limit	Specify a limit for the number of cluster-targeted JMS artifact instances that can fail over to a particular JVM. This can be used to prevent too many instances from starting on a server, avoiding a system failure when starting too few servers of a formerly large cluster. A typical limit value should allow all instances to run in the smallest desired cluster size, which means (smallest-cluster-size * (limit + 1)) should equal or exceed the total number of instances. A value of -1 means there is no fail over limit (unlimited). A value of 0 prevents any fail overs of cluster-targeted JMS artifact instances, so no more than 1 instance will run per server (this is an instance that has not failed over). A value of 1 allows one fail-over instance on each server, so no more than two instances will run per server (one failed over instance plus an instance that has not failed over). Note: This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to On-Failure or Always. MBean Attribute: PersistentStoreMBean.FailOverLimit Minimum value: -1 Changes take effect after you redeploy the module or restart the server.

Related Tasks

• Configure a replicated store for high availability

Related Topics

• Using the Replicated Store