wls jms connection factory

Overview

This resource allows you to manage a connection factory in a JMS Module of a WebLogic domain.

Here is an example on how you should use this:

wls_jms_connection_factory { 'jmsClusterModule:cf':
  ensure                    => 'present',
  attachjmsxuserid          => '0',
  clientidpolicy            => 'Restricted',
  defaulttargeting          => '0',
  jndiname                  => 'jms/cf',
  loadbalancingenabled      => 1,
  messagesmaximum           => '10',
  reconnectpolicy           => 'producer',
  serveraffinityenabled     => 1,
  subdeployment             => 'wlsServers',
  subscriptionsharingpolicy => 'Exclusive',
  transactiontimeout        => '3600',
  xaenabled                 => '0',
}

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

wls_jms_connection_factory { 'my_domain/jmsClusterModule:cf2':
  ensure                    => 'present',
  attachjmsxuserid          => '0',
  clientidpolicy            => 'Restricted',
  defaulttargeting          => 1,
  jndiname                  => 'jms/cf2',
  loadbalancingenabled      => 1,
  messagesmaximum           => '10',
  reconnectpolicy           => 'producer',
  serveraffinityenabled     => 1,
  subscriptionsharingpolicy => 'Exclusive',
  transactiontimeout        => '3600',
  xaenabled                 => 1,
}

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

attachjmsxuserid

attachjmsxuserid

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

client_acknowledge_policy

Acknowledge policy for non-transacted sessions that use the CLIENT_ACKNOWLEDGE mode. All indicates that calling acknowledge on a message acknowledges all unacknowledged messages received on the session. Previous specifies that calling acknowledge on a message acknowledges only unacknowledged messages up to, and including, the given message. This parameter works around a change in the JMS specification and only applies to implementations that use the CLIENT_ACKNOWLEDGE acknowledge mode for a non-transacted session. Specifically, the specification allowed users to acknowledge all messages before and including the message being acknowledged. The specification was changed so that acknowledging any message acknowledges all messages ever received (even those received after the message being acknowledge). ACKNOWLEDGE_PREVIOUS retains the old behavior (acknowledge all message up to and including the message being acknowledged). Whereas, ACKNOWLEDGE_ALL yields the new behavior, where all messages received by the given session are acknowledged regardless of which message is being used to effect the acknowledge. This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_acknowledge_policy => 'All'
   ...
}

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_jms_connection_factory:client_acknowledge_policy']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_allow_close_in_on_message

Specifies whether the connection factory creates message consumers that allow a close() method to be issued within its onMessage() method call. <ul> <li> If enabled, a close() method call from within an onMessage() method call will succeed instead of blocking forever. If the acknowledge mode of the session is set to AUTO_ACKNOWLEDGE, the current message will still be acknowledged automatically when the onMessage() call completes.</li> <li> If disabled, it will cause the stop() and close() methods to hang if called from onMessage() .</li> </ul> This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_allow_close_in_on_message => 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_jms_connection_factory:client_allow_close_in_on_message']
   ...
}

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

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

client_id

An optional Client ID for applications that use this JMS connection factory. If the Client ID Policy is set to Restricted (the default), then configuring a Client ID on the connection factory prevents more than one JMS client from using a connection from this factory. This attribute is rarely configured and should normally be left at the default (blank), as JMS application programs can set their Client IDs dynamically using the standard JMS API javax.jms.Connection.setClientID(), and JMS application message processing containers (such as MDBs) normally make the Client ID configurable as part of container configuration. This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_id => '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_jms_connection_factory:client_id']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_id_policy

The Client ID Policy indicates whether more than one JMS connection can use the same Client ID. The valid values are: <li>CLIENT_ID_POLICY_RESTRICTED - The default. Only one connection that uses this policy can exist in a cluster at any given time for a particular Client ID (if a connection already exists with a given Client ID, attempts to create new connections using this policy with the same Client ID fail with an exception).</li> <li>CLIENT_ID_POLICY_UNRESTRICTED - Connections created using this policy can specify any Client ID, even when other restricted or unrestricted connections already use the same Client ID. The Unrestricted Client ID capability was added in WebLogic 10.3.4 (11gR1PS3). </li> </ul> Notes: <ul><li>WebLogic JMS applications can override the Client ID Policy specified on the connection factory configuration by casting a javax.jms.Connection instance to weblogic.jms.extension.WLConnection and calling setClientID(String clientID, String clientIDPolicy) or setClientIDPolicy(String clientIDPolicy).</li> <li>Two connections with the same Client ID are treated as two different independent connections if they have a different Client ID Policy. This means a cluster can host a single Restricted Client ID Policy connection, and also concurrently host multiple Unrestricted Client ID Policy connections that have the same Client ID as the Restricted connection.</li> <li>Two durable subscriptions with the same Client ID and Subscription Name are treated as two different independent subscriptions if they have a different Client ID Policy. Similarly, two Sharable non-durable subscriptions with the same Client Id are treated as two different independent subscriptions if they have a different Client ID Policy.</li> <li>Durable subscriptions created using an Unrestricted Client Id must be unsubscribed using weblogic.jms.extensions.WLSession.unsubscribe(Topic topic, String name), instead of javax.jms.Session.unsubscribe(String name).</li> </ul> This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_id_policy => 'Restricted'
   ...
}

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_jms_connection_factory:client_id_policy']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_messages_maximum

The maximum number of messages that can exist for an asynchronous session and that have not yet been passed to the message listener. When the Synchronous Prefetch Mode is enabled, this value also affects synchronous sessions with a message consumer that will prefetch messages in one server access. A value of -1 indicates that there is no limit on the number of messages. In this case, however, the limit is set to the amount of remaining virtual memory. When the number of messages reaches the MessagesMaximum value: <ul> <li>For multicast sessions, new messages are discarded according the policy specified by the OverrunPolicy parameter and a DataOverrunException is thrown.</li> <li>For non-multicast sessions, new messages are flow-controlled, or retained on the server until the application can accommodate the messages.</li> </ul> For multicast sessions, when a connection is stopped, messages will continue to be delivered, but only until the MessagesMaximum value is reached. Once this value is reached, messages will be discarded based on the Overrun policy. This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_messages_maximum => '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_jms_connection_factory:client_messages_maximum']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_multicast_overrun_policy

The policy to use when the number of outstanding multicast messages reaches the value specified in MessagesMaximum and some messages must be discarded. <ul> <li> Keep New - Indicates that the most recent messages are given priority over the oldest messages, and the oldest messages are discarded, as needed.</li> <li> Keep Old - Indicates that the oldest messages are given priority over the most recent messages, and the most recent messages are discarded, as needed.</li> </ul> Message age is defined by the order of receipt, not by the JMSTimestamp value. This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_multicast_overrun_policy => 'KeepOld'
   ...
}

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_jms_connection_factory:client_multicast_overrun_policy']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_reconnect_blocking_millis

The maximum length of time, in milliseconds, that any synchronous JMS calls, such as a producer.send(), consumer.receive(), or session.createBrowser(), will block the calling thread before giving up on a JMS client reconnect in progress. This attribute is effective only if the Reconnect Policy option is set to either Producers or All. A value of 0 will cause synchronous JMS calls to not wait for any reconnect in progress; a value of -1 will cause an infinite wait for a reconnect. This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_reconnect_blocking_millis => '60000'
   ...
}

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_jms_connection_factory:client_reconnect_blocking_millis']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_reconnect_policy

Specifies which types of JMS clients will be explicitly and implicitly refreshed after a lost network connection with a server or upon a server reboot. For example, selecting the Producers option will explicitly refresh JMS Producers and implicitly refresh any related Session and Connection clients. <ul> <li>None Do not refresh any JMS clients derived from this connection factory.</li> <li>Producers Refresh all JMS Producer clients derived from this connection factory. This option does not refresh Consumers, QueueBrowsers, or Connections with a configured Client ID for a durable subscriber.</li> <li>All Refresh all JMS Consumer and Producer clients derived from this connection factory, including Connections with a configured Client ID for a durable subscriber. This option does not refresh QueueBrowser clients.</li> </ul> This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_reconnect_policy => 'producer'
   ...
}

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_jms_connection_factory:client_reconnect_policy']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_subscription_sharing_policy

Specifies the subscription sharing policy on this connection. Although this attribute is dynamic, the new values only take effect on future connections and have no impact to existing connections created before the value was changed. The valid values are: <ul> <li>Exclusive - The default. All subscribers created using this connection factory cannot share subscriptions with any other subscribers.</li> <li>Sharable - Subscribers created using this connection factory can share their subscriptions with other subscribers, regardless of whether those subscribers are created using the same connection factory or a different connection factory. Consumers can share a non-durable subscriptions only if they have the same Client ID and Client ID Policy; consumers can share a durable subscription only if they have the same Client ID, Client ID Policy, and Subscription Name. The Sharable Subscription Sharing capability was added in WebLogic 10.3.4 (11gR1PS3).</li> </ul> Notes: <ul><li>WebLogic JMS applications can override the Subscription Sharing Policy specified on the connection factory configuration by casting a javax.jms.Connection instance to weblogic.jms.extension.WLConnection and calling setSubscriptionSharingPolicy(String).</li> <li>Most applications with a Sharable Subscription Sharing Policy will also use an Unrestricted Client ID Policy in order to ensure that multiple connections with the same client ID can exist.</li> <li>Two durable subscriptions with the same Client ID and Subscription Name are treated as two different independent subscriptions if they have a different Client ID Policy. Similarly, two Sharable non-durable subscriptions with the same Client ID are treated as two different independent subscriptions if they have a different Client ID Policy.</li> <li>Durable subscriptions created using an Unrestricted Client Id must be unsubscribed using weblogic.jms.extensions.WLSession.unsubscribe(Topic topic, String name), instead of javax.jms.Session.unsubscribe(String name), regardless of the Subscription Sharing Policy ((Exclusive or Sharable).</li> <li>Sharable subscriptions are not part of the standard JMS 1.1 specification. Although most major JMS vendors support some form of sharable subscriptions, the detailed behavior of shared subscriptions may differ from vendor to vendor.</li> </ul> This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_subscription_sharing_policy => 'Exclusive'
   ...
}

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_jms_connection_factory:client_subscription_sharing_policy']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_synchronous_prefetch_mode

Specifies whether a synchronous consumer will prefetch messages (that is, messages sent from the server to the client) in one server access. <ul> <li>Disabled - Indicates that message prefetching is disabled.</li> <li>Enabled - Indicates that a synchronous consumer (queue receiver or topic subscriber) will prefetch messages. The amount of prefetched messages cannot exceed the maximum number of messages defined by the Messages Maximum parameter.</li> <li>Topic Subscriber Only - Indicates that only a synchronous topic subscriber will prefetch messages. The amount of prefetched messages cannot exceed the maximum number of messages defined by the Messages Maximum parameter.</li> </ul> Synchronous message prefetching does not support the following conditions, and will throw a JMS Exception when encountered: <ul> <li>User (XA) transactions for synchronous message receives</li> <li>Multiple synchronous consumers per session (regardless of queue or topic)</li> </ul> This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_synchronous_prefetch_mode => 'disabled'
   ...
}

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_jms_connection_factory:client_synchronous_prefetch_mode']
   ...
}

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

Back to overview of wls_jms_connection_factory

client_total_reconnect_period_millis

The maximum length of time, in milliseconds, that JMS clients (particularly asynchronous consumers) will continue to try to reconnect to the server after either the initial network disconnect or the last synchronous call attempt, whichever occurred most recently, before giving up retrying. This attribute is effective only if the ReconnectPolicy attribute is set to either Producers or All. The default value of -1 means that that it will keep trying to reconnect indefinitely; a value of 0 means that there would be exactly one retry attempt. This attribute is dynamic and can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   client_total_reconnect_period_millis => '-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_jms_connection_factory:client_total_reconnect_period_millis']
   ...
}

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

Back to overview of wls_jms_connection_factory

clientidpolicy

clientidpolicy

Valid values are absent, Restricted, Unrestricted.

Back to overview of wls_jms_connection_factory

connection_factory_name

The Connection Factory name

Back to overview of wls_jms_connection_factory

default_targeting_enabled

Specifies whether this JMS resource defaults to the parent module’s targeting or uses the subdeployment targeting mechanism. When set to true, this resource implicitly inherits the targeting of its parent module. When set to false, this resource gets targeted based its subdeployment’s targets, if one is specified.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   default_targeting_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_jms_connection_factory:default_targeting_enabled']
   ...
}

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

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

defaultdeliverymode

The default delivery mode

Valid values are absent, Persistent, Non-Persistent.

Back to overview of wls_jms_connection_factory

defaultredeliverydelay

The default redelivery delay

Back to overview of wls_jms_connection_factory

defaulttargeting

default targeting enabled.

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

delivery_default_compression_threshold

The number of bytes for the serialized message body so any message exceeds this limit will trigger message compression when the message is sent or received by the JMS message producer or consumer. The compression will occur either: <ul> <li> On the JMS message producer’s JVM if the JMS message producer’s JVM is not collocated with the JMS provider’s JVM and the message body size exceeds the threshold limit. </li> <li> On the JMS provider’s JVM when the JMS message consumer’s JVM is not collocated with the JMS provider’s JVM and the message body size exceeds the threshold limit. </li> </ul>

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_default_compression_threshold => '2147483647'
   ...
}

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_jms_connection_factory:delivery_default_compression_threshold']
   ...
}

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

Back to overview of wls_jms_connection_factory

delivery_default_delivery_mode

The default delivery mode used for messages when a delivery mode is not explicitly defined. All messages with a DefaultDeliveryMode of null that are produced on a connection created with this factory will receive this value. Message producers can get the delivery mode explicitly by calling the javax.jms.MessageProducer.getDeliveryMode() method. This attribute is dynamic. It can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_default_delivery_mode => 'Persistent'
   ...
}

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_jms_connection_factory:delivery_default_delivery_mode']
   ...
}

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

Back to overview of wls_jms_connection_factory

delivery_default_priority

The default priority used for messages when a priority is not explicitly defined. All messages with a DefaultPriority of -1 that are produced on a connection created with this factory will receive this value. Message producers can get the priority explicitly by calling the javax.jms.MessageProducer.getPriority() method. This attribute is dynamic. It can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_default_priority => '4'
   ...
}

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_jms_connection_factory:delivery_default_priority']
   ...
}

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

Back to overview of wls_jms_connection_factory

delivery_default_redelivery_delay

The delay time, in milliseconds, before rolled back or recovered messages are redelivered. All messages consumed by a consumer created with this factory that have a DefaultRedeliveryDelay of -1 will use this value. Message consumers can get the redelivery delay explicitly by calling the weblogic.jms.extensions.WLSession.getRedliveryDelay() method. This attribute is dynamic. It can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_default_redelivery_delay => '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_jms_connection_factory:delivery_default_redelivery_delay']
   ...
}

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

Back to overview of wls_jms_connection_factory

delivery_default_time_to_deliver

The delay time, in milliseconds, between when a message is produced and when it is made visible on its destination. All messages produced by a producer created with this factory that have a DefaultTimeToDeliver of -1 will use this value. Message producers can get the Time-to-Deliver explicitly by calling the weblogic.jms.extensions.WLMessageProducer.getTimeToDeliver() method. This attribute is dynamic. It can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_default_time_to_deliver => '0'
   ...
}

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_jms_connection_factory:delivery_default_time_to_deliver']
   ...
}

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

Back to overview of wls_jms_connection_factory

delivery_default_time_to_live

The maximum length of time, in milliseconds, that a message exists. This value is used for messages when both the time-to-live is not explicitly set by the sender application that is using this connection factory and the time-to-live is not explicitly overridden by the destination’s TimeToLiveOverride attribute . A value of 0 indicates that the message has an infinite amount time to live. Message producer applications can set the time-to-live explicitly by calling the standard JMS javax.jms.MessageProducer.setTimeToLive(long) method. Note that programmatically setting time-to-live using javax.jms.Message.setJMSExpiration() has no effect - the message setter is ignored by the JMS send call as required by the JMS specification. This attribute is dynamic. It can be changed at any time. However, changing the value does not affect existing connections. It only affects new connections made with this connection factory.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_default_time_to_live => '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_jms_connection_factory:delivery_default_time_to_live']
   ...
}

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

Back to overview of wls_jms_connection_factory

delivery_default_unit_of_order

The default Unit-of-Order name for producers that connect using this connection factory. A Unit-of-Order allows for messages to be processed in a certain order, even among multiple recipients. System-generated indicates that WebLogic Server will automatically generate a Unit-of-Order name. User-Generated indicates that the Unit-of-Order name will come from the name specified name in the Unit-of-Order Name field. If None is selected, no message ordering is enforced.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_default_unit_of_order => '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_jms_connection_factory:delivery_default_unit_of_order']
   ...
}

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

Back to overview of wls_jms_connection_factory

delivery_send_timeout

The maximum length of time, in milliseconds, that a sender will wait when there isn’t enough available space (no quota) on a destination to accommodate the message being sent. The default time is 10 milliseconds. A value of 0 indicates that the sender does not want to wait for space. This attribute is dynamic. It can be changed at any time. However, changing the value does not affect existing connections or their producers. It only affects new connections made with this connection factory. Producers inherit the setting from the connection factory used to create their session and connection. The value can then be overridden at run time by setting the value on the producer.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   delivery_send_timeout => '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_jms_connection_factory:delivery_send_timeout']
   ...
}

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

Back to overview of wls_jms_connection_factory

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_jms_connection_factory

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_jms_connection_factory

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_jms_connection_factory

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_jms_connection_factory

ensure

The basic property that the resource should be in.

Valid values are present, absent.

Back to overview of wls_jms_connection_factory

flow_control_enabled

Specifies whether a producer created using a connection factory allows flow control. If true, the associated message producers will be slowed down if a JMS server or a destination reaches its specified upper byte or message threshold.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   flow_control_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_jms_connection_factory:flow_control_enabled']
   ...
}

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

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

flow_interval

The adjustment period of time, in seconds, when a producer adjusts its flow from the FlowMaximum number of messages to the FlowMinimum amount, or vice versa. When a producer is flow controlled, it is slowed down from its FlowMaximum to its FlowMinimum over the specified FlowInterval amount of seconds.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   flow_interval => '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_jms_connection_factory:flow_interval']
   ...
}

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

Back to overview of wls_jms_connection_factory

flow_maximum

The maximum number of messages-per-second allowed for a producer that is experiencing a threshold condition. When a producer is flow controlled it will never be allowed to go faster than the FlowMaximum messages per second. If a producer is not currently limiting its flow when a threshold condition is reached, the initial flow limit for that producer is set to FlowMaximum. If a producer is already limiting its flow when a threshold condition is reached (the flow limit is less than FlowMaximum), then the producer will continue at its current flow limit until the next time the flow is evaluated. Note: Once a threshold condition has subsided, the producer is not permitted to ignore its flow limit. If its flow limit is less than the FlowMaximum, then the producer must gradually increase its flow to the FlowMaximum each time the flow is evaluated. When the producer finally reaches the FlowMaximum, it can then ignore its flow limit and send without limiting its flow.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   flow_maximum => '500'
   ...
}

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_jms_connection_factory:flow_maximum']
   ...
}

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

Back to overview of wls_jms_connection_factory

flow_minimum

The minimum number of messages-per-second allowed for a producer that is experiencing a threshold condition. This is the lower boundary of a producer’s flow limit. That is, WebLogic JMS will not further slow down a producer whose message flow limit is at its FlowMinimum. When a producer is flow controlled it will never be required to go slower than FlowMinimum messages per second.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   flow_minimum => '50'
   ...
}

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_jms_connection_factory:flow_minimum']
   ...
}

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

Back to overview of wls_jms_connection_factory

flow_one_way_send_mode

Specifies whether message producers created using this connection factory are allowed to do one-way message sends to improve typical non-persistent, non-transactional messaging performance. When enabled, the associated queue senders and/or topic publishers can send messages without internally waiting for a response from the target destination’s host JMS server. One-way sends are supported only when the connection factory hosting the producer and the JMS server hosting the target destination are targeted to the same WebLogic Server instance. In addition, one-way sends are not supported for higher quality-of-service (QOS) features, such as XA, transacted sessions, persistent messaging, unit-of-order, unit-of-work, distributed destinations, and client-side store-and-forward. If the producer and target destination are in separate domains, or if any of these higher QOS features are detected, then the one-way mode setting will be ignored and standard two-way sends will be used instead. <ul> <li>Disabled One-way send is disabled.</li> <li>Enabled One-way send is permitted for queue senders or topic publishers. <li>Topic Only Only topic publishers are permitted to do one-way sends. </ul> Notes: <ul> <li>One-way message sends are disabled if your connection factory is configured with XA Connection Factory Enabled. This setting disables one-way sends whether or not the sender actually uses transactions. <li>To benefit from one-way performance, the default One-Way Send Window Size value must also be configured higher. After every OneWaySendWindowSize - 1 number of messages, a two-way is used instead of a one-way, so all messages are actually two-way when the OneWaySendWindowSize = 1. </ul>

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   flow_one_way_send_mode => 'disabled'
   ...
}

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_jms_connection_factory:flow_one_way_send_mode']
   ...
}

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

Back to overview of wls_jms_connection_factory

flow_one_way_send_window_size

Specifies the maximum number of sent messages per window when One-Way Send Mode is set to allow queue senders and/or topic publishers to make one-way sends. The window size determines when a two-way message is required to regulate the producer before it can continue making additional one-way sends. To benefit from one-way performance, the default One-Way Send Window Size value must be configured higher in addition to enabling one-way sends. After every OneWaySendWindowSize - 1 number of messages, a two-way is used instead of a one-way, so all messages are actually two-way when the OneWaySendWindowSize = 1.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   flow_one_way_send_window_size => 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_jms_connection_factory:flow_one_way_send_window_size']
   ...
}

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

Back to overview of wls_jms_connection_factory

flow_steps

The number of steps used when a producer is adjusting its flow from the Flow Maximum amount of messages to the Flow Minimum amount, or vice versa. Specifically, the Flow Interval adjustment period is divided into the number of Flow Steps (for example, 60 seconds divided by 6 steps is 10 seconds per step). Also, the movement (i.e., the rate of adjustment) is calculated by dividing the difference between the Flow Maximum and the Flow Minimum into steps. At each Flow Step, the flow is adjusted upward or downward, as necessary, based on the current conditions, as follows: <ul> <li> The downward movement (the decay) is geometric over the specified period of time (Flow Interval) and according to the specified number of Flow Steps. (For example, 100, 50, 25, 12.5)</li> <li> The movement upward is linear. The difference is simply divided by the number of steps.</li> </ul>

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   flow_steps => '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_jms_connection_factory:flow_steps']
   ...
}

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

Back to overview of wls_jms_connection_factory

jmsmodule

The JMS module name.

Back to overview of wls_jms_connection_factory

jndi_name

The global JNDI name used to look up a connection factory within a clustered JNDI namespace. In a clustered environment, this name is propagated to the entire cluster. If you want the JNDI name to be bound only on the local server, and not propagated to the rest of the cluster, then use the Local JNDI Name setting. If not specified, then the connection factory is not bound into a clustered JNDI namespace.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   jndi_name => '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_jms_connection_factory:jndi_name']
   ...
}

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

Back to overview of wls_jms_connection_factory

jndiname

The jndi name.

Back to overview of wls_jms_connection_factory

lb_load_balancing_enabled

Specifies whether non-anonymous producers created through a connection factory are load balanced within a distributed destination on a per-call basis. <ul> <li>If enabled, the associated message producers are load balanced on every send() or publish() .</li> <li>If disabled, the associated message producers are load balanced on the first send() or publish().</li> </ul>

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   lb_load_balancing_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_jms_connection_factory:lb_load_balancing_enabled']
   ...
}

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

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

lb_server_affinity_enabled

Specifies whether a server instance that is load balancing consumers or producers across multiple members destinations of a distributed destination, will first attempt to load balance across any other physical destinations that are also running on the same server instance.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   lb_server_affinity_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_jms_connection_factory:lb_server_affinity_enabled']
   ...
}

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

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

loadbalancingenabled

loadbalancingenabled

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

local_jndi_name

The local JNDI name used to look up the connection factory within the JNDI namespace of the server where the connection factory is targeted. In a clustered environment, this name is bound only on the local server instance and is not propagated to the rest of the cluster. If not specified, then the connection factory is not bound into the local JNDI namespace.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   local_jndi_name => '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_jms_connection_factory:local_jndi_name']
   ...
}

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

Back to overview of wls_jms_connection_factory

localjndiname

The local jndi name

Back to overview of wls_jms_connection_factory

messagesmaximum

Maximum messages

Back to overview of wls_jms_connection_factory

name

The name.

Back to overview of wls_jms_connection_factory

notes

Optional information that you can include to describe this named JMS descriptor bean. JMS module saves this note in the JMS descriptor file 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_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   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_jms_connection_factory:notes']
   ...
}

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

Back to overview of wls_jms_connection_factory

provider

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

simple

Manage JMS connection factories

Back to overview of wls_jms_connection_factory

reconnectpolicy

Reconnect policy

Valid values are absent, none, producer, all.

Back to overview of wls_jms_connection_factory

security_attach_jmsx_user_id

Specifies whether WebLogic Server attaches the authenticated user name to sent messages. If enabled, the system will attach the authenticated username onto sent messages if the destination supports this behavior. The username is placed in the JMSXUserID user property. You should consult the JMSXUserID documentation in Programming WebLogic JMS before using this feature. When dynamically changed this will affect all connections made using this connection factory after the change was made.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   security_attach_jmsx_user_id => 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_jms_connection_factory:security_attach_jmsx_user_id']
   ...
}

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

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

serveraffinityenabled

Server affinity enabled

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

sub_deployment_name

Gets the name of the sub-deployment to use when targeting this entity Entities are targeted using a sub-deployment with this name. The targets of the sub-deployment will be the targets of this entity.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   sub_deployment_name => '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_jms_connection_factory:sub_deployment_name']
   ...
}

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

Back to overview of wls_jms_connection_factory

subdeployment

The subdeployment name.

Back to overview of wls_jms_connection_factory

subscriptionsharingpolicy

Subscription sharing policy

Valid values are absent, Exclusive, Sharable.

Back to overview of wls_jms_connection_factory

timeout

Timeout for applying a resource.

To be sure no Puppet operation, hangs a Puppet daemon, all operations have a timeout. When this timeout expires, Puppet will abort the current operation and signal an error in the Puppet run.

With this parameter, you can specify the length of the timeout. The value is specified in seconds. In this example, the timeout is set to 600 seconds.

wls_server{'my_server':
  ...
  timeout => 600,
}

The default value for timeout is 120 seconds.

Back to overview of wls_jms_connection_factory

transaction_timeout

The timeout value (in seconds) for all transactions on connections created with this connection factory. If a transacted session is still active after the timeout has elapsed, the transaction is rolled back. A value of 0 indicates that the default value will be used. If you have long-running transactions, you might want to adjust the value of this attribute to allow transactions to complete.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   transaction_timeout => '3600'
   ...
}

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_jms_connection_factory:transaction_timeout']
   ...
}

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

Back to overview of wls_jms_connection_factory

transaction_xa_connection_factory_enabled

Indicates whether a XA queue or XA topic connection factory is returned, instead of a queue or topic connection factory. An XA connection factory can be used to create an XAConnection, which in turn may be used to create an XASession, which in turn may be used to obtain an XAResource for use inside a transaction manager. In addition, this attribute indicates whether or not a connection factory creates sessions that are JTA aware. If true, the associated message producers and message consumers look into the running thread for a transaction context. Otherwise, the current JTA transaction will be ignored. Note: Transacted sessions ignore the current threads transaction context in favor of their own internal transaction, regardless of the setting. This setting only affects non-transacted sessions.

An example on how to use this:

wls_jms_connection_factory {a_wls_jms_connection_factory :
   ...
   transaction_xa_connection_factory_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_jms_connection_factory:transaction_xa_connection_factory_enabled']
   ...
}

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

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory

transactiontimeout

transaction timeout on the cf

Back to overview of wls_jms_connection_factory

xaenabled

xa enabled on the cf

Valid values are absent, 1, 0.

Back to overview of wls_jms_connection_factory