Administration Console Online Help

JMS Server: Configuration: Thresholds and Quotas

Use this page to define thresholds, which trigger this JMS server to
carry out events such as generating log messages, and quotas, which
specify maximums for memory use, message size and number of messages
available to this JMS server.

The maximum number of bytes that can be stored in this JMS
server. A value of -1 removes any WebLogic Server
limits.

Because excessive bytes volume can cause memory saturation,
Oracle recommends that this maximum corresponds to the total amount
of system memory available after accounting for the rest of your
application load.

The maximum number of messages that can be stored in this JMS
server. A value of -1 removes any WebLogic Server
limits.

Because excessive message volume can cause memory saturation,
Oracle recommends that this value corresponds to the total amount
of system memory available after accounting for the rest of your
application load.

The maximum number of bytes allowed in individual messages on
this JMS server. The size of a message includes the message body,
any user-defined properties, and the user-defined JMS header fields
JMSCorrelationID and JMSType.

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.

Note: Any change to this maximum affects only incoming
messages; stored messages are not affected.

Determines whether the JMS server delivers smaller messages
before larger ones when a destination has exceeded its maximum
number of messages. FIFO prevents the JMS server from
delivering smaller messages when larger ones are already waiting
for space. Preemptive allows smaller send requests to
preempt previous larger ones when there is sufficient space for
smaller messages on the destination.

This policy is defined only for the JMS server; it cannot be set
on individual destinations.

Additional information on the FIFO and
Preemptive policies is provided below.

FIFO (first in, first out) 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.