Skip navigation.
Downloads | Product Documentation | Support

WebLogic Server Configuration Reference

# JMSServer

# Description

This class represents a JMS server. A JMS server manages connections and message requests on behalf of clients.

# Syntax

>     <JMSServer
>       BlockingSendPolicy=( "FIFO" | "Preemptive" )
>       BytesMaximum="number"
>       BytesPagingEnabled=( "true" | "false" )
>       BytesThresholdHigh="number"
>       BytesThresholdLow="number"
>       DeploymentOrder="number"
>       ExpirationScanInterval="number of seconds"
>       MaximumMessageSize="number"
>       MessagesMaximum="number"
>       MessagesPagingEnabled=( "true" | "false" )
>       MessagesThresholdHigh="number"
>       MessagesThresholdLow="number"
>       Name="String"
>       Notes="String"
>       PagingStore="JMSStore name"
>       Store="JMSStore name"
>       Targets="list of Target names"
>       TemporaryTemplate="JMSTemplate name"
>     />

# Parent Elements

- Domain

# Child Elements

- JMSQueue
- JMSTopic
- JMSSessionPool

# Attributes

Table 36-1 JMSServer attributes

Attribute | Description | Range of Values and Default
--- | --- | ---
BlockingSendPolicy | The JMS server's policy on whether to deliver smaller messages before larger ones when a destination has exceeded its message quota. This can occur when multiple senders are competing for space on the same JMS server. This policy is defined only for the JMS server; it cannot be set on individual destinations. The valid expiration policies are: FIFO - The first in, first out policy indicates that all send requests for the same destination are queued up one behind the other until space is available. No send request is permitted to successfully complete if there is another send request waiting for space before it. When space is limited, the FIFO policy prevents the starvation of larger requests because smaller requests cannot continuously use the remaining available space. Smaller requests are delayed, though not starved, until the larger request can be completed. When space does become available, requests are considered in the order in which they were made. If there is sufficient space for a given request, then that request is completed and the next request is considered. If there is insufficient space for a given request, then no further requests are considered until sufficient space becomes available for the current request to complete. Preemptive - Indicates that a send operation can preempt other blocking send operations if space is available. That is, if there is sufficient space for the current request, then that space is used even if there are other requests waiting for space. When space is limited, the Preemptive policy can result in the starvation of larger requests. For example, if there is insufficient available space for a large request, then it is queued up behind other existing requests. When space does become available, all requests are considered in the order in which they were originally made. If there is sufficient space for a given request, then that request is allowed to continue and the next request is considered. If there is insufficient space for a given request, then that request is skipped and the next request is considered. | Admin Console field label: Blocking Send Policy Required: no Default: FIFO
BytesMaximum | The maximum bytes quota (total amount of bytes) that can be stored in this JMS server. The default value of -1 specifies that there is no WebLogic-imposed limit on the number of bytes that can be stored. However, excessive bytes volume can cause memory saturation, so this value should correspond to the total amount of available system memory relative to the rest of your application load. This attribute is dynamically configurable. Range of Values: >= BytesThresholdHigh | Admin Console field label: Bytes Maximum Default: -1 Minimum: -1 Maximum: 263-1
BytesPagingEnabled | Specifies whether bytes paging is enabled on this JMS server for temporarily swapping message bodies out from memory to a persistent paging store when the JMS servers's byte load reaches a specified threshold. false - Server bytes paging is explicitly disabled. true - If both the BytesThresholdLow and BytesThresholdHigh values are greater than -1, then server bytes paging is enabled. If either the BytesThresholdLow or BytesThresholdHigh attribute is defined as -1, then server bytes paging is implicitly disabled--even though this flag is set to true. | Admin Console field label: Bytes Paging Enabled Default: false
BytesThresholdHigh | The upper threshold value that triggers events based on the number of bytes stored in the JMS server. If the number of bytes exceeds this threshold, the triggered events are: Log Messages - A message is logged on the server indicating a high threshold condition. Bytes Paging - If bytes paging is enabled (and a paging store has been configured), then server bytes paging is started. Flow Control - If flow control is enabled, the JMS server becomes armed and instructs producers to begin decreasing their message flow. This attribute is dynamically configurable. A value of -1 specifies that the value is not set and that bytes paging, flow control, and threshold log messages are disabled for the JMS server. Range of Values: <= BytesMaximum; >BytesThresholdLow Note: Bytes paging cannot be dynamically disabled by resetting the BytesThresholdHigh to -1. To disable paging, you could set the BytesThresholdHigh to a very large number, so that paging would not be triggered. | Admin Console field label: Bytes Threshold High Default: -1 Minimum: -1 Maximum: 263-1
BytesThresholdLow | The lower threshold value that triggers events based on the number of bytes stored in the JMS server. If the number of bytes falls below this threshold, the triggered events are: Log Messages - A message is logged on the server indicating that the threshold condition has cleared. Bytes Paging - If bytes paging is enabled, paging is stopped (if paging is occurring). Flow Control - If flow control is enabled, the JMS server becomes disarmed and instructs producers to begin increasing their message flow. This attribute is dynamically configurable. A value of -1 specifies that the value is not set and that bytes paging, flow control, and threshold log messages are disabled for the JMS server. Range of Values: < BytesThresholdHigh | Admin Console field label: Bytes Threshold Low Default: -1 Minimum: -1 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
ExpirationScanInterval | The amount of time, in seconds, that the JMS server will pause between its cycles of scanning its destinations for expired messages to process (acccording to the specified Expiration Policy on the destinations). The default value is 30 seconds. A value of 0 indicates that active scanning is disabled. That is, expired messages are passively removed as they are discovered. Setting this value to some very large value also effectively disables active scanning for expired messages from the system. Users will not receive expired messages, and any expired messages that are discovered are removed form the system. However, expired messages sitting in idle destinations (i.e., an inactive queue or disconnected durable subscriber) will not be removed and will continue to consume system resources. The scanning and processing cycle for expired messages occurs as follows: After the specified waiting period, the JMS server devotes a separate thread to scan all of its local destinations for expired messages. After the scanning is completed, all discovered expired messages are processed according to the specified Expiration Policy on the destinations (Discard, Log, or Redirect). The entire process repeats after another specified waiting period. Note: Since a new scan will not start until the current one is finished and the specified waiting period ends, an expired message could still remain in the system for the maximum scan waiting period plus the amount of time it takes to perform the scan and processing. | Admin Console field label: Expiration Scan Interval Units: seconds Default: 30 Minimum: 0 Maximum: 231-1
MaximumMessageSize | The maximum size of a message that will be accepted from producers on this JMS server. The message size includes the message body, any user-defined properties, and the user-defined JMS header fields: `JMSCorrelationID` and `JMSType`. Producers sending messages that exceed the configured maximum message size for the JMS server will receive a `ResourceAllocationException`. The maximum message size is only enforced for the initial production of a message. Messages that are redirected to an error destination or forwarded to a member of a distributed destination are not checked for size. For instance, if a destination and its corresponding error destination are configured with a maximum message size of 128K bytes and 64K bytes, respectively, a message of 96K bytes could be redirected to the error destination (even though it exceeds the 64K byte maximum), but a producer could not directly send the 96K byte message to the error destination. This attribute is dynamically configurable, but only incoming messages are impacted; stored messages are not impacted. | Admin Console field label: Maximum Message Size Default: 231-1 Minimum: 0 Maximum: 231-1
MessagesMaximum | The maximum message quota (total amount of messages) that can be stored in this JMS server. The default value of -1 specifies that there is no WebLogic-imposed limit on the number of messages that can be stored. However, excessive message volume can cause memory saturation, so this value should correspond to the total amount of available system memory relative to the rest of your application load. This attribute is dynamically configurable. Range of Values: >= MessagesThresholdHigh | Admin Console field label: Messages Maximum Default: -1 Minimum: -1 Maximum: 263-1
MessagesPagingEnabled | Specifies whether messages paging is enabled on this JMS server for temporarily swapping message bodies out from memory to a persistent paging store when the JMS servers's message load reaches a specified threshold. false - Server messages paging is explicitly disabled. true - If both the MessagesThresholdLow and MessagesThresholdHigh values are greater than -1, then server messages paging is enabled. If either the MessagesThresholdLow or MessagesThresholdHigh attribute is undefined, or defined as -1, then server messages paging is implicitly disabled--even though this flag is set to true. | Admin Console field label: Messages Paging Enabled Default: false
MessagesThresholdHigh | The upper threshold value that triggers events based on the number of messages stored in the JMS server. If the number of messages exceeds this threshold, the triggered events are: Log Messages - A message is logged on the server indicating a high threshold condition. Messages Paging - If messages paging is enabled (and a paging store has been configured), then server messages paging is started. Flow Control - If flow control is enabled, the JMS server becomes armed and instructs producers to begin decreasing their message flow. A value of -1 specifies that the value is not set and that messages paging, flow control, and threshold log messages are disabled for the JMS server. Range of Values: <= MessagesMaximum; >MessagesThresholdLow This attribute is dynamically configurable. Note: Messages paging cannot be dynamically disabled by resetting the MessagesThresholdHigh to -1. To disable paging, you could set the MessagesThresholdHigh to a very large number, so that paging would not be triggered. | Admin Console field label: Messages Threshold High Default: -1 Minimum: -1 Maximum: 263-1
MessagesThresholdLow | The lower threshold value that triggers events based on the number of messages stored in the JMS server. If the number of messages falls below this threshold, the triggered events are: Log Messages - A message is logged on the server indicating that the threshold condition has cleared. Messagse Paging - If messages paging is enabled, paging is stopped (if paging is occurring). Flow Control - If flow control is enabled, the JMS server becomes disarmed and instructs producers to begin increasing their message flow. This attribute is dynamically configurable. A value of -1 specifies that the value is not set and that messages paging, flow control, and threshold log messages are disabled for the JMS server. Range of Values: < MessagesThresholdHigh | Admin Console field label: Messages Threshold Low Default: -1 Minimum: -1 Maximum: 263-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
PagingStore | The name of the dedicated JMS file store where message bodies are temporarily swapped out from memory when the JMS server's message load reaches a specified bytes/messages threshold. A paging store cannot be the same JMS file store used for storing persistent messages or durable subscribers. A paging store can only be used by one JMS server. A value of none specifies that message paging is not supported. If no paging store is specified, then the JMS server and its destinations will not support message paging. Note: Using a JMS JDBC store is not recommended for paging since the amount of traffic and subsequent lack of performance would make such a configuration undesirable. | Admin Console field label: Paging Store Required: no
Store | The persistent disk-based file or JDBC-accessible database for the JMS server. A persistent store may only be used by one JMS server. A value of none specifies that no persistent messaging is supported. If no persistent store is specified, then destinations on this JMS server will not support persistent messages or durable subscribers. | Admin Console field label: Persistent Store Required: no
Targets | The targets in the current domain on which this item can be deployed. | Admin Console field label: Targets Required: no
TemporaryTemplate | The name of the existing JMS template that is used to create all temporary destinations, including temporary queues and temporary topics. The attribute values for a temporary destination are derived from this JMS template. If provided as part of the template, the Store attribute values are ignored because temporary destinations do not support persistent messaging. Note: If this attribute is set to none, attempts to create a temporary destination (queue or topic) will fail. | Admin Console field label: Temporary Template Required: no