|         | 
 
Messaging Bridge: Configuration: High Availability
A messaging bridge instance transfers messages between two messaging providers. The providers may be another implementation of WebLogic JMS or a 3rd-party JMS messaging provider.
Use this page to configure high availability (HA) configuration settings for this messaging bridge instance.
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:
DistributedCreates 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.
SingletonCreates 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 Policymust beOn-FailureorAlwayswhen using this option with a JMS server,On-Failurewhen using this option with a messaging bridge, andAlwayswhen using this option with a path service.Instance Naming Note:
The
DistributionPolicydetermines the instance name suffix for cluster-targeted JMS artifacts. The suffix for a cluster-targetedSingletonis-01and for a cluster-targetedDistributedis@ClusterMemberName.Messaging Bridge Notes:
When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge
Distributed PolicyandMigration PolicytoDistributed/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 PolicyandMigration PolicytoSingleton/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 Policyon the migratable target toExactly-Once.MBean Attribute:
DynamicDeploymentMBean.DistributionPolicyChanges 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.
Note:
OffDisables 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
SingletonMigration Policy.
On-FailureEnables 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.
AlwaysProvides the same behavior as
On-Failureand automatically migrates instances even in the event of a graceful shutdown or a partial cluster start.Cluster leasing must be configured for
On-FailureandAlways.Messaging Bridge Notes:
When an instance per server is desired for a cluster-targeted messaging bridge, Oracle recommends setting the bridge
Distributed PolicyandMigration PolicytoDistributed/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 PolicyandMigration PolicytoSingleton/On-Failure, respectively.
A
Migration PolicyofAlwaysis 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 Policyon the migratable target toExactly-Once.MBean Attribute:
DynamicDeploymentMBean.MigrationPolicyChanges take effect after you redeploy the module or restart the server.
Initial Boot Delay Secconds 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.
Note:
A value >
0is the time, in seconds, to delay before before loading resources after a failure and restart.
A value of
0specifies no delay.This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to
On-FailureorAlways.MBean Attribute:
MessagingBridgeMBean.InitialBootDelaySecondsChanges 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.
Note:
A value >
0specifies the time, in seconds, to delay before failing a JMS artifact back to its user preferred server.
A value of
0indicates that the instance would never failback.
A value of
-1indicates that there is no delay and the instance would failback immediately.This setting only applies when the JMS artifact is cluster-targeted and the Migration Policy is set to
On-FailureorAlways.MBean Attribute:
MessagingBridgeMBean.FailbackDelaySecondsChanges 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
AlwaysorOn-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 >
0specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.
A value of
0specifies no delay.MBean Attribute:
MessagingBridgeMBean.PartialClusterStabilityDelaySecondsChanges take effect after you redeploy the module or restart the server.
|   |