Administration Console Online Help

JMS Server: Configuration: General

JMS servers act as management containers for the queues and topics in
JMS modules that are targeted to them. A JMS server's primary
responsibility for its destinations is to maintain information on what
persistent store is used for any persistent messages that arrive on the
destinations, and to maintain the states of durable subscribers created on
the destinations.

Use this page to define the general configuration parameters for this
JMS server.

The file or database in which this JMS server stores persistent
messages. If unspecified, the JMS server uses the default
persistent store that is configured on each targeted WebLogic
Server instance.

The disk-based file store or JDBC-accessible database store that
you specify must be targeted to the same server instance as this
JMS server. Multiple services on the same WebLogic Server instance,
including multiple JMS servers, may share the same persistent
store. Each service's persistent data will be kept apart.

If you specify a PersistentStore, the deprecated Store
field must not be set. If neither the PersistentStore field
nor the Store field are set, the JMS server supports
persistent messaging using the default persistent store for the
targeted WebLogic Server instance.

Specifies where message bodies are written when the size of the
message bodies in the JMS server exceeds the message buffer
size.

If unspecified, messages are written to the default
tmp directory inside the
server-name subdirectory of a domain's root
directory. For example,
domain-name/servers/server-name/tmp,
where domain-name is the root directory of your
domain.

For best performance, this directory should not be the same as
the directory used by the JMS server's persistent store.

When file locking protection is enabled, a store boot fails if
another store instance already has opened the store files. Do not
disable this setting unless you have procedures in place to prevent
multiple store instances from opening the same file. File locking
is not required but helps prevent corruption in the event that two
same-named file store instances attempt to operate in the same
directories. This setting applies to both primary and cache
files.

The amount of memory (in bytes) that this JMS server can use to
store message bodies before it writes them to disk. When the JMS
server writes the message bodies to disk, it clears them from
memory.

A value of -1 (the default) specifies that the server will
automatically determine a size based on the maximum heap size of
the JVM. This default will be set to either one-third the maximum
heap size, or 512 megabytes, whichever is larger.

The larger the buffer, the more memory JMS will consume when
many messages are waiting on queues or topics. Once the buffer is
surpassed, JMS may write message bodies to the directory specified
by PagingDirectory in an effort to reduce memory usage below this
buffer.

Surpassing the buffer size does not stop the JMS server from
accepting new messages. It is still possible to run out of memory
if messages are arriving faster than they can be written to disk.
Users with high messaging loads who wish to support the highest
possible availability should consider setting a quota or setting a
threshold and enabling flow control.

Specifies whether this JMS server can be used to host temporary
destinations.

If this field is enabled and no Temporary Template Name
is defined, then the temporary destinations created on this JMS
server will use all default destination values. If this field is
enabled, then the JMS template to be used for creating temporary
destinations is specified by the Temporary Template Name
field. If this field is disabled, then this JMS server will not
host temporary destinations.

The number of seconds between this JMS server's cycles of
scanning local destinations for expired messages. A value of
0 disables active scanning. A very large scan interval
effectively disables active scanning.

With scanning disabled, users still do not receive expired
messages and any expired messages that are discovered by other
system activities are removed. However, expired messages sitting in
idle destinations (such as an inactive queue or disconnected
durable subscriber) are not removed and continue to consume system
resources.

The scanning 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 located expired messages
are processed according to the specified Expiration Policy on the
destination (Discard, Log, or Redirect).

The entire process repeats after another specified waiting
period.

Note: Because a new scan does not start until the current
one is finished and until 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.

Specifies whether message persistence is supported for this JMS
server.

When set to true, the default, then if the JMS server has no
store configured, the targeted WebLogic Server instance's default
store is used to store persistent messages. When set to false, then
this JMS server does not support persistent messages, and instead
downgrades them to non-persistent.

Oracle recommends not setting this parameter to false. It is
available to provide compatibility with older releases.

Specifies whether production is paused at server startup on
destinations targeted to this JMS server. A destination cannot
receive any new messages while it is paused.

When the value is set to true, then immediately
after the host server instance is rebooted, then this JMS server
and its targeted destinations are modified such that they are in a
"production paused" state, which results in preventing new message
production activities on those destinations.

To resume normal new message production activity, later you will
have to change the state of this JMS server to a "production
enabled" state by setting this value to false, and
then either redeploy the JMS server or reboot the hosting server
instance.

When the value is set to default, then the
Production Paused At Startup is determined based on the
corresponding setting on the individual destination.

Indicates whether consumption is paused at startup on
destinations targeted to this JMS server at startup. A destination
cannot receive any new messages while it is paused.

When the value is set to true, then immediately
after the host server instance is booted, then this JMS server and
its targeted destinations are modified such that they are in a
"consumption paused" state, which prevents any message consuming
activity on those destinations.

To allow normal message consumption on the destinations, later
you will have to change the state of this JMS server to a
"consumption enabled" state by setting this value to
false, and then either redeploy the JMS server or
reboot the hosting server instance.

When the value is set to default, then the
Consumption Paused At Startup is determined based on the
corresponding setting on the individual destination.

Indicates whether insertion is paused at startup on destinations
targeted to this JMS server. A destination cannot receive any new
messages while it is paused.

When the value is set to true, then immediately
after the host server instance is booted, then this JMS server and
its targeted destinations are modified such that they are in a
"insertion paused" state, which results preventing messages that
are result of the "in-flight" work completion to arrive on those
destinations.

Note: For a detailed definition of "in-flight"
work/messages, see
weblogic.management.runtime.JMSServerRuntimeMBean#resumeInsertion
and
weblogic.management.runtime.JMSDestinationRuntime#resumeInsertion

To allow in-flight work messages to appear on the destinations,
later you will have to change the state of this JMS server to an
"insertion enabled" state by setting this value to
false, and then either redeploy the JMS server or
reboot the hosting server instance.

When the value is set to default, then the
Insertion Paused At Startup is determined based on the
corresponding setting on the individual destination.

Specifies whether JMS clients will get an exception when sending
persistent messages to a destination targeted to a JMS server that
does not have a persistent store configured. This parameter only
has effect when the Store Enabled parameter is disabled
(false).

When set to false, the default, clients will get an exception
when sending persistent messages to a JMS server with no store
configured. When set to true, then persistent messages are
downgraded to non-persistent; however, the send operations are
allowed to continue.

The minimum amount of data, in bytes and rounded down to the
nearest power of 2, mapped into the JVM's address space per primary
store file. Applies to synchronous write policies
Direct-Write-With-Cache and Disabled, but
only when a native wlfileio library is loaded. See Maximum Window Buffer Size.

The maximum amount of data, in bytes and rounded down to the
nearest power of 2, mapped into the JVM's address space per primary
store file. Applies to synchronous write policies
Direct-Write-With-Cache and Disabled but
only when the native wlfileio library is loaded.

A window buffer does not consume Java heap memory, but does
consume off-heap (native) memory. If the store is unable to
allocate the requested buffer size, it allocates smaller and
smaller buffers until it reaches MinWindowBufferSize,
and then fails if cannot honor
MinWindowBufferSize.

Oracle recommends setting the max window buffer size to more
than double the size of the largest write (multiple concurrently
updated records may be combined into a single write), and greater
than or equal to the file size, unless there are other constraints.
32-bit JVMs may impose a total limit of between 2 and 4GB for
combined Java heap plus off-heap (native) memory usage.

See store attribute AllocatedWindowBufferBytes to
find out the actual allocated Window Buffer Size.

The I/O buffer size, in bytes, automatically rounded down to the
nearest power of 2.

For the Direct-Write-With-Cache policy when a
native wlfileio driver is available,
IOBufferSize describes the maximum portion of a cache
view that is passed to a system call. This portion does not consume
off-heap (native) or Java heap memory.

For the Direct-Write and Cache-Flush
policies, IOBufferSize is the size of a per store
buffer which consumes off-heap (native) memory, where one buffer is
allocated during run-time, but multiple buffers may be temporarily
created during boot recovery.

When a native wlfileio driver is not available, the
setting applies to off-heap (native) memory for all policies
(including Disabled).

For the best runtime performance, Oracle recommends setting
IOBufferSize so that it is larger than the largest
write (multiple concurrent store requests may be combined into a
single write).

For the best boot recovery time performance of large stores,
Oracle recommends setting IOBufferSize to at least 2
megabytes.

See AllocatedIOBufferBytes to find out the actual
allocated off-heap (native) memory amount. It is a multiple of
IOBufferSize for the Direct-Write and
Cache-Flush policies, or zero.

The MaxFileSize value affects the number of files
needed to accommodate a store of a particular size (number of files
= store size/MaxFileSize rounded up).

A file store automatically reuses space freed by deleted records
and automatically expands individual files up to
MaxFileSize if there is not enough space for a new
record. If there is no space left in exiting files for a new
record, a store creates an additional file.

A small number of larger files is normally preferred over a
large number of smaller files as each file allocates Window Buffer
and file handles.

If MaxFileSize is larger than 2^24 *
BlockSize, then MaxFileSize is ignored,
and the value becomes 2^24 * BlockSize. The default
BlockSize is 512, and 2^24 * 512 is 8 GB.

The smallest addressable block, in bytes, of a file. When a
native wlfileio driver is available and the block size
has not been configured by the user, the store selects the minimum
OS specific value for unbuffered (direct) I/O, if it is within the
range [512, 8192].

A file store's block size does not change once the file store
creates its files. Changes to block size only take effect for new
file stores or after the current files have been deleted. See
"Tuning the Persistent Store" in Performance and Tuning for
Oracle WebLogic Server.