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.

Attributes
Attribute Name | Short Description |
---|---|
async_enabled | Specifies if a messaging bridge instance forwards in asynchronous messaging mode. |
asyncenabled | Specifies if a messaging bridge instance forwards in asynchronous messaging mode |
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. |
batch_size | The number of messages that are processed within one transaction. |
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 |
batchsize | The number of messages that are processed within one transaction. |
bridge_name | The bridge name |
deployment_order | A priority that the server uses to determine when it deploys an item. |
disable_autorequire | Puppet supports automatic ordering of resources by autorequire. |
disable_corrective_change | Disable the modification of a resource when Puppet decides it is a corrective change. |
disable_corrective_ensure | Disable the creation or removal of a resource when Puppet decides is a corrective change. |
distribution_policy | Specifies how the instances of a configured JMS artifact are named and distributed when deployed to a cluster. |
domain | With this parameter, you identify the domain, where your objects is in. |
durability_enabled | Specifies whether or not the messaging bridge allows durable messages. |
durabilityenabled | Specifies whether or not the messaging bridge allows durable messages |
ensure | The basic property that the resource should be in. |
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. |
idle_time_maximum | The maximum amount of time, in seconds, that a messaging bridge instance remains idle. |
idletimemax | The maximum amount of time, in seconds, that a messaging bridge instance remains idle. |
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. |
migration_policy | Controls migration and restart behavior of cluster targeted JMS service artifact instances. |
name | The name. |
notes | Optional information that you can include to describe this configuration. |
number_of_restart_attempts | Specifies the number of restart attempts before migrating a failed JMS artifact instance to another server in the WebLogic cluster. |
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 . |
preserve_msg_property | Specifies if message properties are preserved when messages are forwarded by a bridge instance. |
preservemsgproperty | Specifies if message properties are preserved when messages are forwarded by a bridge instance. |
provider | resource. |
qos | The QOS (quality of service) for this messaging bridge instance. |
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. |
qosdegradationallowed | Specifies if this messaging bridge instance allows the degradation of its QOS (quality of service) when the configured QOS is not available. |
quality_of_service | The QOS (quality of service) for this messaging bridge instance. |
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. |
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. |
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. |
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. |
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. |
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. |
restart_in_place | Enables periodic automatic restart of failed cluster targeted JMS artifact instance(s) running on healthy WebLogic Server instances. |
seconds_between_restarts | Specifies the amount of time, in seconds, to wait in between attempts to restart a failed service instance. |
selector | The filter for messages that are sent across the messaging bridge instance. |
source_destination | The source destination from which this messaging bridge instance reads messages. |
sourcedestination | The source destination from which this messaging bridge instance reads messages. |
started | Specifies the initial operating state of a targeted messaging bridge instance. |
tags | Return all tags on this Configuration MBean |
target | An array of target names. |
target_destination | The target destination where a messaging bridge instance sends the messages it receives from the source destination. |
targetdestination | The target destination where a messaging bridge instance sends the messages it receives from the source destination. |
targettype | An array of target types. |
transaction_timeout | The amount of time, in seconds, that the transaction manager waits for each transaction before timing it out. |
transactiontimeout | The amount of time, in seconds, that the transaction manager waits for each transaction before timing it out. |
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.