wls messaging bridge

Overview

This resource allows you to manage a messaging bridge in an WebLogic domain.

Here is an example on how you should use this:

wls_messaging_bridge { 'myBrigde':
  ensure                 => 'present',
  asyncenabled           => 1,
  batchinterval          => '-1',
  batchsize              => '10',
  durabilityenabled      => 1,
  idletimemax            => '60',
  qos                    => 'Exactly-once',
  reconnectdelayincrease => '5',
  reconnectdelaymax      => '60',
  reconnectdelaymin      => '15',
  selector               => 'sel',
  transactiontimeout     => '30',
  sourcedestination      => 'mySourceBrigdeDest',
  targetdestination      => 'MyDestBridgeDest',
  target                 => ['ManagedServer1', 'WebCluster'],
  targettype             => ['Server', 'Cluster'],
}

In this example you are managing a message bridge in the default domain. When you want to manage a message bridge in a specific domain, you can use:

wls_messaging_bridge { 'my_domain/myBrigde':
  ensure                 => 'present',
  asyncenabled           => 1,
  batchinterval          => '-1',
  batchsize              => '10',
  durabilityenabled      => 1,
  idletimemax            => '60',
  qos                    => 'Exactly-once',
  reconnectdelayincrease => '5',
  reconnectdelaymax      => '60',
  reconnectdelaymin      => '15',
  selector               => 'sel',
  transactiontimeout     => '30',
  sourcedestination      => 'mySourceBrigdeDest',
  targetdestination      => 'MyDestBridgeDest',
  target                 => ['ManagedServer1', 'WebCluster'],
  targettype             => ['Server', 'Cluster'],
}

Check the documentation for valid messaging bridge properties.

Experience the Power of Puppet for WebLogic

If you want to play and experiment with Puppet and WebLogic, please take a look at our playgrounds. At our playgrounds, we provide you with a pre-installed environment, where you experiment fast and easy.

For WebLogic   here at our playground...

Attributes

async_enabled

Specifies if a messaging bridge instance forwards in asynchronous messaging mode. AsyncEnabled only applies to messaging bridge instances whose source destination supports asynchronous receiving. Messaging bridges instances that forward in asynchronous mode are driven by the source destination. A messaging bridge instance listens for messages and forwards them as they arrive. When AsyncEnabled is not selected, a bridge instance is forced to work in synchronous mode, even if the source supports asynchronous receiving. Note: For a messaging bridge instance with a QOS of Exactly-once to work in asynchronous mode, the source destination has to support the MDBTransaction interface. Otherwise, the bridge automatically switches to synchronous mode if it detects that MDBTransaction is not supported by the source destination.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   async_enabled => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:async_enabled']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

asyncenabled

Specifies if a messaging bridge instance forwards in asynchronous messaging mode

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

batch_interval

The maximum amount of time, in milliseconds, that a messaging bridge instance waits before sending a batch of messages in one transaction, regardless of whether the Batch Size has been reached or not. <ul> <li> Only applies to a messaging bridge instance forwarding messages in synchronous mode and has a QOS (quality of service) that requires two-phase transactions. </li> <li> The default value of -1 indicates that the bridge instance waits until the number of messages reaches the Batch Size before it completes a transaction. </li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   batch_interval => '-1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:batch_interval']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

batch_size

The number of messages that are processed within one transaction. Batch Size only applies to a messaging bridge instance forwarding messages in synchronous mode and has a QOS (quality of service) that requires two-phase transactions.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   batch_size => '10'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:batch_size']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

batchinterval

The maximum amount of time, in milliseconds, that a messaging bridge instance waits before sending a batch of messages in one transaction, regardless of whether the Batch Size has been reached or not

Back to overview of wls_messaging_bridge

batchsize

The number of messages that are processed within one transaction.

Back to overview of wls_messaging_bridge

bridge_name

The bridge name

Back to overview of wls_messaging_bridge

deployment_order

A priority that the server uses to determine when it deploys an item. The priority is relative to other deployable items of the same type. For example, the server prioritizes and deploys all EJBs before it prioritizes and deploys startup classes. Items with the lowest Deployment Order value are deployed first. There is no guarantee on the order of deployments with equal Deployment Order values. There is no guarantee of ordering across clusters.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   deployment_order => '1000'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:deployment_order']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

disable_autorequire

Puppet supports automatic ordering of resources by autorequire. Sometimes, however, this causes issues. Setting this parameter to true, disables autorequiring for this specific resource.

USE WITH CAUTION!!

Here is an example on hopw to use this:

...{'domain_name/...':
  disableautorequire => true,
  ...
}

Back to overview of wls_messaging_bridge

disable_corrective_change

Disable the modification of a resource when Puppet decides it is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_change parameter, you can disable corrective changes on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ...
  disable_corrective_change => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not modify the resource and signal an error:

    Error: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/parameter: change from '10' to '20' failed: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change. (corrective)

Back to overview of wls_messaging_bridge

disable_corrective_ensure

Disable the creation or removal of a resource when Puppet decides is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_ensure parameter, you can disable corrective ensure present or ensure absent actions on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ensure                    => 'present',
  ...
  disable_corrective_ensure => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not create or remove the resource and signal an error:

    Error: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure.
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/ensure: change from 'absent' to 'present' failed: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure. (corrective)

Back to overview of wls_messaging_bridge

distribution_policy

Specifies how the instances of a configured JMS artifact are named and distributed when deployed to a cluster. When this setting is configured on a Store it applies to all JMS artifacts that reference the store. Valid options: <ul> <li> Distributed creates an artifact instance on each cluster member in a cluster. Required for all SAF Agents and for cluster targeted or resource group scoped JMS Servers that host distributed destinations. </li> <li> Singleton creates one artifact instance on a single cluster member of 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. </li> </ul> 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.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   distribution_policy => 'Distributed'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:distribution_policy']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

domain

With this parameter, you identify the domain, where your objects is in.

The domain name is part of the full qualified name of any WebLogic object on a system. Let’s say we want to describe a WebLogic server. The full qualified name is:

wls_server{'domain_name/server_name':
  ensure => present,
  ...
}

When you don’t specify a domain name, Puppet will use default as domain name. For every domain you want to manage, you’ll have to put a wls_settings in your manifest.

Back to overview of wls_messaging_bridge

durability_enabled

Specifies whether or not the messaging bridge allows durable messages. When enabled and the source destination is a JMS topic, a messaging bridge instance uses a durable subscription to ensure that no messages are lost in the event of a failure. DurabilityEnabled ignored if the source destination is a JMS queue. <ul> <li> When enabled and the source destination uses durable subscriptions, the source JMS implementation saves messages that are sent when a messaging bridge instance is not running. When the bridge instance is restarted, these messages are forwarded to the target destination. The administrator can choose not to be durable. </li> <li> When not enabled, messages that are sent to the source JMS implementation while the bridge instance is down cannot be forwarded to the target destination. </li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   durability_enabled => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:durability_enabled']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

durabilityenabled

Specifies whether or not the messaging bridge allows durable messages

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

ensure

The basic property that the resource should be in.

Valid values are present, absent.

Back to overview of wls_messaging_bridge

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. <ul> <li>A value > 0 specifies the time, in seconds, to delay before failing a JMS artifact back to its user preferred server.</li> <li>A value of 0 specifies there is no delay and the dynamic load balancer manages the failback process.</li> <li>A value of -1 specifies the default delay value is used.</li> </ul> Note: This setting only applies when the JMS artifact is cluster targeted and the Migration Policy is set to On-Failure or Always>.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   failback_delay_seconds => '-1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:failback_delay_seconds']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

idle_time_maximum

The maximum amount of time, in seconds, that a messaging bridge instance remains idle. <ul> <li> In asynchronous mode, this is the longest amount of time a messaging bridge instance stays idle before it checks the sanity of its connection to the source. </li> <li> In synchronous mode, this is the amount of time the messaging bridge can block on a receive call if no transaction is involved. </li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   idle_time_maximum => '60'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:idle_time_maximum']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

idletimemax

The maximum amount of time, in seconds, that a messaging bridge instance remains idle.

Back to overview of wls_messaging_bridge

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. 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. <ul> <li>A value > 0 is the time, in seconds, to delay before before loading resources after a failure and restart.</li> <li>A value of 0 specifies no delay.</li> <li>A value of -1 specifies the default delay value is used.</li> </ul> Note: This setting only applies when the JMS artifact is cluster targeted and the Migration Policy is set to On-Failure or Always>.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   initial_boot_delay_seconds => '-1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:initial_boot_delay_seconds']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

migration_policy

Controls migration and restart behavior of cluster targeted JMS service artifact instances. When this setting is configured on a Store it applies to all JMS artifacts that reference the store. Valid options: <ul> <li>Off disables migration and restart support for cluster targeted JMS service objects, including the ability to restart a failed persistent store instance and its associated services. This policy can not be combined with the Singleton Migration Policy. </li> <li>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. </li> <li>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. </li> </ul> Note: Cluster leasing must be configured for On-Failure and Always.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   migration_policy => 'Off'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:migration_policy']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

name

The name.

Back to overview of wls_messaging_bridge

notes

Optional information that you can include to describe this configuration. WebLogic Server saves this note in the domain’s configuration file (config.xml) as XML PCDATA. All left angle brackets (<) are converted to the XML entity <. Carriage returns/line feeds are preserved. <dl> <dt>Note:</dt> <dd> If you create or edit a note from the Administration Console, the Administration Console does not preserve carriage returns/line feeds. </dd> </dl>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   notes => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:notes']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

number_of_restart_attempts

Specifies the number of restart attempts before migrating a failed JMS artifact instance to another server in the WebLogic cluster. <ul> <li>A value > 0 specifies the number of restart attempts before migrating a failed service instance.</li> <li>A value of 0 specifies the same behavior as setting {@link #getRestartInPlace} to false.</li> <li>A value of -1 specifies the service is never migrated. Instead, it continues to attempt to restart until it either starts or the server instance shuts down.</li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   number_of_restart_attempts => '6'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:number_of_restart_attempts']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

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 once a cluster is fully started (stable) or when individual servers are started. <ul> <li>A value > 0 specifies the time, in seconds, to delay before a partially started cluster starts dynamically configured services.</li> <li>A value of 0 specifies no delay.</li> <li>A value of -1 specifies a default delay value of 240 seconds.</li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   partial_cluster_stability_delay_seconds => '-1'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:partial_cluster_stability_delay_seconds']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

preserve_msg_property

Specifies if message properties are preserved when messages are forwarded by a bridge instance. If the target bridge destination is on wls 9.0 or higher, the following message properties are preserved: <ul> <li> message ID </li> <li> message timestamp </li> <li> user ID </li> <li> delivery mode </li> <li> priority </li> <li> expiration time </li> <li> redelivery limit </li> <li> unit of order name </li> </ul> If the target bridge destination is on wls between 6.0 and 8.1 or on a foreign JMS server, the following message properties are preserved: <ul> <li> delivery mode </li> <li> priority </li> <li> expiration time </li> </ul> If the target bridge destination is on wls 5.1 or older, no properties are preserved.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   preserve_msg_property => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:preserve_msg_property']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

preservemsgproperty

Specifies if message properties are preserved when messages are forwarded by a bridge instance.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

provider

The specific backend to use for this wls_messaging_bridge resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.Available providers are:

simple

Manage a Messaging bridge in an WebLogic domain via regular WLST

Back to overview of wls_messaging_bridge

qos

The QOS (quality of service) for this messaging bridge instance.

Valid values are absent, Exactly-once, Atmost-once, Duplicate-okay.

Back to overview of wls_messaging_bridge

qos_degradation_allowed

Specifies if this messaging bridge instance allows the degradation of its QOS (quality of service) when the configured QOS is not available. <ul> <li> When enabled, the messaging bridge instance degrades the QOS when the configured QOS is not available. If the QOS is degraded, a log message is delivered to the WebLogic startup window or log file. </li> <li> When not enabled, if messaging bridge instance cannot satisfy the quality of service requested, an error results and the messaging bridge instance does not start. </li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   qos_degradation_allowed => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:qos_degradation_allowed']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

qosdegradationallowed

Specifies if this messaging bridge instance allows the degradation of its QOS (quality of service) when the configured QOS is not available.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

quality_of_service

The QOS (quality of service) for this messaging bridge instance. <ul> <li>Exactly-once: Each message in the source destination is transferred to the target exactly once. This is the highest QOS a messaging bridge instance can offer. </li> <li>Atmost-once: Each message in the source is transferred to the target only once with the possibility of being lost during the forwarding. </li> <li>Duplicate-okay: Messages in the source destination are transferred to the target (none are lost) but some may appear in the target more than once. </li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   quality_of_service => 'Exactly-once'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:quality_of_service']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

reconnect_delay_increase

The incremental delay time, in seconds, that a messaging bridge instance increases its waiting time between one failed reconnection attempt and the next retry. <ul> <li> Use with ReconnectDelayMinimum and ReconnectDelayMaximum. After the first failure to connect to a destination, the bridge instance waits for the number of seconds defined by ReconnectDelayMinimum. Each time a reconnect attempt fails, the bridge instance increases its waiting time by the number of seconds defined by ReconnectDelayIncrease. The maximum delay time is defined by ReconnectDelayMaximum. Once the waiting time is increased to the maximum value, the bridge instance stops increase its waiting time. Once the bridge instance successfully connects to the destination, the bridge instance resets its waiting time to the initial value defined by ReconnectDelayMinimum. </li>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   reconnect_delay_increase => '5'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:reconnect_delay_increase']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

reconnect_delay_maximum

The longest time, in seconds, that a messaging bridge instance waits between one failed attempt to connect to the source or target, and the next retry. <ul> <li> Use with ReconnectDelayMinimum and ReconnectDelayIncrease. After the first failure to connect to a destination, a bridge instance waits for the number of seconds defined by ReconnectDelayMinimum. Each time a reconnect attempt fails, the bridge instance increases its waiting time by the number of seconds defined by ReconnectDelayIncrease. The maximum delay time is defined by ReconnectDelayMaximum. Once the waiting time is increased to the maximum value, the bridge instance stops increase its waiting time. Once the bridge instance successfully connects to the destination, the bridge instance resets its waiting time to the initial value defined by ReconnectDelayMinimum. </li>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   reconnect_delay_maximum => '60'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:reconnect_delay_maximum']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

reconnect_delay_minimum

The minimum amount of time, in seconds, that a messaging bridge instance waits before it tries to reconnect to the source or target destination after a failure.

• Use with ReconnectDelayMaximum and ReconnectDelayIncrease. After the first failure to connect to a destination, the bridge instance waits for the number of seconds defined by ReconnectDelayMinimum. Each time a reconnect attempt fails, the bridge instance increases its waiting time by the number of seconds defined by ReconnectDelayIncrease. The maximum delay time is defined by ReconnectDelayMaximum. Once the waiting time is increased to the maximum value, the bridge instance stops increase its waiting time. Once the bridge instance successfully connects to the destination, the bridge instance resets its waiting time to the initial value defined by ReconnectDelayMinimum.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   reconnect_delay_minimum => '15'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:reconnect_delay_minimum']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

reconnectdelayincrease

The incremental delay time, in seconds, that a messaging bridge instance increases its waiting time between one failed reconnection attempt and the next retry.

Back to overview of wls_messaging_bridge

reconnectdelaymax

The longest time, in seconds, that a messaging bridge instance waits between one failed attempt to connect to the source or target, and the next retry.

Back to overview of wls_messaging_bridge

reconnectdelaymin

The minimum amount of time, in seconds, that a messaging bridge instance waits before it tries to reconnect to the source or target destination after a failure.

Back to overview of wls_messaging_bridge

restart_in_place

Enables periodic automatic restart of failed cluster targeted JMS artifact instance(s) running on healthy WebLogic Server instances. Restart attempts occur before attempts to migrate an instance to a different server in the cluster. When this setting is configured on a Store it applies to all JMS artifacts that reference the store. <ul> <li>Restarts occur when Restart In Place is set to true, the JMS artifact is cluster targeted, and the Migration Policy is set to On-Failure or Always>.</li> <li>This attribute is not used by WebLogic Messaging Bridges which automatically restart internal connections as needed. </li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   restart_in_place => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:restart_in_place']
   ...
}

This help text generated from MBean text of the WebLogic server.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

seconds_between_restarts

Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   seconds_between_restarts => '30'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:seconds_between_restarts']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

selector

The filter for messages that are sent across the messaging bridge instance.

Back to overview of wls_messaging_bridge

source_destination

The source destination from which this messaging bridge instance reads messages.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   source_destination => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:source_destination']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

sourcedestination

The source destination from which this messaging bridge instance reads messages.

Back to overview of wls_messaging_bridge

started

Specifies the initial operating state of a targeted messaging bridge instance.

Valid values are absent, 1, 0.

Back to overview of wls_messaging_bridge

tags

Return all tags on this Configuration MBean

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   tags => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:tags']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

target

An array of target names.

The array of targets for this resource. A target can be a WebLogic Server, a WebLogic cluster, or a JMS Server. When specifying a target, you’ll also have to specify targettype. Here is an example on how you can specify a target.

..{ 'aResource':
  ...
  target     => ['myServer','myCluster'],
  targettype => ['Server','Cluster'],
  ...
}

here is an example on specifying the target and targettype for a regular WebLogic cluster:

wls_cluster{ 'aCluster':
  ...
  target     => ['myServer','myCluster'],
  targettype => ['Server','Cluster'],
  ...
}

Back to overview of wls_messaging_bridge

target_destination

The target destination where a messaging bridge instance sends the messages it receives from the source destination.

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   target_destination => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:target_destination']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

targetdestination

The target destination where a messaging bridge instance sends the messages it receives from the source destination.

Back to overview of wls_messaging_bridge

targettype

An array of target types.

The array of target types for this resource. A target can be a WebLogic Server, a WebLogic cluster, or a JMS Server. When specifying a targettype, you’ll also have to specify a target. Here is an example on how you can specify a target.

...{ 'aResource':
  ...
  target     => ['myServer','myCluster'],
  targettype => ['Server','Cluster'],
  ...
}

here is an example on specifying the target and targettype for a regular WebLogic cluster:

wls_cluster{ 'aCluster':
  ...
  target     => ['myServer','myCluster'],
  targettype => ['Server','Cluster'],
  ...
}

Back to overview of wls_messaging_bridge

transaction_timeout

The amount of time, in seconds, that the transaction manager waits for each transaction before timing it out. <ul> <li> Transaction timeouts are used when the QOS (quality of service) for a messaging bridge instance requires transactions. </li> <li> If a bridge is configured with Exactly-once QOS, the receiving and sending is completed in one transaction. </li> </ul>

An example on how to use this:

wls_messaging_bridge {a_wls_messaging_bridge :
   ...
   transaction_timeout => '30'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_messaging_bridge:transaction_timeout']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_messaging_bridge

transactiontimeout

The amount of time, in seconds, that the transaction manager waits for each transaction before timing it out.

Back to overview of wls_messaging_bridge