Skip navigation.
Downloads | Product Documentation | Support

WebLogic Server Configuration Reference

# JMSConnectionFactory

# Description

This class represents a JMS connection factory. Connection factories are objects that enable JMS clients to create JMS connections.

# Syntax

>     <JMSConnectionFactory
>       AcknowledgePolicy=( "All" | "Previous" )
>       AllowCloseInOnMessage=( "true" | "false" )
>       ClientId="String"
>       DefaultDeliveryMode=( "Persistent" | "Non-Persistent" )
>       DefaultPriority="number"
>       DefaultRedeliveryDelay="number"
>       DefaultTimeToDeliver="number"
>       DefaultTimeToLive="number"
>       DeploymentOrder="number"
>       FlowControlEnabled=( "true" | "false" )
>       FlowInterval="number of seconds"
>       FlowMaximum="number of messages/second"
>       FlowMinimum="number of messages/second"
>       FlowSteps="number"
>       JNDIName="String"
>       LoadBalancingEnabled=( "true" | "false" )
>       MessagesMaximum="number"
>       Name="String"
>       Notes="String"
>       OverrunPolicy=( "KeepOld" | "KeepNew" )
>       SendTimeout="number of milliseconds"
>       ServerAffinityEnabled=( "true" | "false" )
>       Targets="list of Target names"
>       TransactionTimeout="number"
>       UserTransactionsEnabled=( "true" | "false" )
>       XAConnectionFactoryEnabled=( "true" | "false" )
>       XAServerEnabled=( "true" | "false" )
>     />

# Parent Elements

- Domain

# Attributes

Table 27-1 JMSConnectionFactory attributes

Attribute | Description | Range of Values and Default
--- | --- | ---
AcknowledgePolicy | This attribute only applies to implementations that use the `CLIENT_ACKNOWLEDGE` acknowledge mode for a non-transacted session. This attribute works around a change in the JMS specification. Specifically, the specification allowed users to acknowledge all messages before and including the message geing acknowledged. The specification was changed so that acknowledging any message acknowledges all messages ever received (even those received after the message being acknowledge), as follows: An acknowledge policy of `ACKNOWLEDGE_PREVIOUS` retains the old behavior (acknowledge all message up to and including the message being acknowledged). An acknowledge policy of `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. | Admin Console field label: Acknowledge Policy Required: no Default: All
AllowCloseInOnMessage | Specifies whether the connection factory creates message consumers that allow a `close()` method to be issued within its `onMessage()` method call. If selected (true), 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. If not selected (false), it will cause the `stop()` and `close()` methods to hang if called from `onMessage()`. 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. | Admin Console field label: Allow Close In On Message Default: false
ClientId | The client ID for a durable subscriber that uses this connection factory. | Admin Console field label: Client ID Required: no
DefaultDeliveryMode | The default delivery mode used for messages when a delivery mode is not explicitly defined. Message producers can get the delivery mode explicitly by calling the `javax.jms.MessageProducer.getDeliveryMode()` method. | Admin Console field label: Default Delivery Mode Required: no Default: Persistent
DefaultPriority | The default priority used for messages when a priority is not explicitly defined. Message producers can get the priority explicitly by calling the `javax.jms.MessageProducer.getPriority()` method. | Admin Console field label: Default Priority Default: 4 Minimum: 0 Maximum: 9
DefaultRedeliveryDelay | The delay time, in milliseconds, before rolled back or recovered messages are redelivered. Message consumers can get the redelivery delay explicitly by calling the `weblogic.jms.extensions.WLSession.getRedliveryDelay()` method. | Admin Console field label: Default Redelivery Delay Default: 0 Minimum: 0 Maximum: 263-1
DefaultTimeToDeliver | The delay time, in milliseconds, between when a message is produced and when it is made visible on its destination. Message producers can get the time-to-deliver explicitly by calling the `weblogic.jms.extensions.WLMessageProducer.getTimeToDeliver()` method. | Admin Console field label: Default Time To Deliver Default: 0 Minimum: 0 Maximum: 263-1
DefaultTimeToLive | The maximum length of time, in milliseconds, that a message will exist. This value is used for messages when a priority is not explicitly defined. A value of 0 indicates that the message has an infinite amount time to live. Message producers can get the time-to-live explicitly by calling the `javax.jms.MessageProducer.getTimeToLive()` method. | Admin Console field label: Default Time To Live Default: 0 Minimum: 0 Maximum: 263-1
DeploymentOrder | 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. | Default: 1000 Minimum: 0 Maximum: 231-1
FlowControlEnabled | Specifies whether a producer created using a connection factory allows flow control. If true, the associated message producers will be slowed down if the JMS server reaches Btyes/MessagesThresholdHigh. | Admin Console field label: Flow Control Enabled Default: true
FlowInterval | 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 FlowInterval seconds. | Admin Console field label: Flow Interval Units: seconds Default: 60 Minimum: 0 Maximum: 231-1
FlowMaximum | 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. | Admin Console field label: Flow Maximum Units: messages/second Default: 500 Minimum: 1 Maximum: 231-1
FlowMinimum | 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. | Admin Console field label: Flow Minimum Units: messages/second Default: 50 Minimum: 1 Maximum: 231-1
FlowSteps | 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: 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) The movement upward is linear. The difference is simply divided by the number of steps. | Admin Console field label: Flow Steps Default: 10 Minimum: 1 Maximum: 231-1
JNDIName | The JNDI name used to look up the connection factory within the JNDI namespace. The connection factory name is configured separately. | Admin Console field label: JNDI Name Required: no
LoadBalancingEnabled | For distributed destinations, specifies whether non-anonymous producers created through a connection factory are load balanced within a distributed destination on a per-call basis. If true, the associated message producers will be load balanced on every `send()` or `publish()`. If false, the associated message producers will be load balanced on the first `send()` or `publish()`. | Admin Console field label: Load Balancing Enabled Default: true
MessagesMaximum | The maximum number of messages that can exist for an asynchronous session and that have not yet been passed to the message listener. 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. A value of 0 is not valid and will cause various exceptions to be thrown. When the number of messages reaches the MessagesMaximum value: For multicast sessions, new messages are discarded according the policy specified by the OverrunPolicy attribute and a DataOverrunException is thrown. For non-multicast sessions, new messages are flow-controlled, or retained on the server until the application can accommodate the messages. 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. | Admin Console field label: Messages Maximum Default: 10 Minimum: -1 Maximum: 231-1
Name | The name of this configuration. WebLogic Server uses an MBean to implement and persist the configuration. | Admin Console field label: Name Required: no
Notes | Optional information that you can include to describe this configuration. | Admin Console field label: Notes Required: no
OverrunPolicy | The policy to use when the number of outstanding multicast messages reaches the value specified in MessagesMaximum and some messages must be discarded. If set to KeepNew, the most recent messages are given priority over the oldest messages, and the oldest messages are discarded, as needed. If set to KeepOld, the oldest messages are given priority over the most recent messages, and the most recent messages are discarded, as needed. Message age is defined by the order of receipt, not by the JMSTimestamp value. | Admin Console field label: Overrun Policy Required: no Default: KeepOld
SendTimeout | 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 accomodate 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. | Admin Console field label: Send Timeout Units: milliseconds Default: 10 Minimum: 0 Maximum: 263-1
ServerAffinityEnabled | For distributed destinations, specifies whether a WebLogic Server instance that is load balancing consumers or producers across multiple physical destinations in a distributed destination set, will first attempt to load balance across any other physical destinations that are also running in the same instance. | Admin Console field label: Server Affinity Enabled Default: true
Targets | The targets in the current domain on which this item can be deployed. | Admin Console field label: Targets Required: no
TransactionTimeout | 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. | Admin Console field label: Transaction Timeout Default: 3600 Minimum: 0 Maximum: 231-1
UserTransactionsEnabled | Deprecated. Specifiies whether 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. This attribute is now deprecated -- if the XAServerEnabled attribute is set, then this attribute is automatically set as well. 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. | Admin Console field label: User Transactions Enabled Default: false
XAConnectionFactoryEnabled | 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. | Admin Console field label: XA Connection Factory Enabled Default: false
XAServerEnabled | Deprecated. Return the value of the XAServerEnabled attribute for the connection factory. Determines whether XA-enabled JMS connections and sessions are always created when this connection factory is invoked from inside a WebLogic Server instance. This attribute is deprecated -- it is now possible to use a single XA-enabled connection factory for both XA- and non-XA purposes. | Admin Console field label: Server Side XA Enabled Default: false