We support a number of different policies which can be attached to individual destinations (queues, topics) or to wildcards of queue/topic hierarchies. This makes it easy to configure how different regions of the JMS destination space are handled.
The properties you can set on a Destination are as follows:
the producer will slow down and eventually block if no resources(e.g. memory) are available on the broker. If this is off messages get off-lined to disk to prevent memory exhaustion
tracks duplicate messages (which can occur in failover for non-persistent messages)
persistent messages are cached for fast retrieval from store
maximum number of persistent messages to page from store at a time
maximum number of persistent messages to page from store for a browser
The memory limit for a given destination. This acts as a child to the overall broker memory specified by the
memoryLimit attribute. There is no default for this value; it simply acts as a child to the overall broker memory until the broker memory is exhausted.
for non-serialized messages (embedded broker) - the assumed size of the message used for memory usage calculation. Serialized messages used the serialized size as the basis for the memory calculation
the percentage (%) tipping point at which a system memory limit will cause a cursor to block or spool to disk
the percentage (%) tipping point at which a system usage store limit will cause a sent to block
have the store respect message priority
send an advisory message when a message is consumed by a client
send an advisory message when a message is sent to a client
send an advisory message if a consumer is deemed slow
send an advisory message if a producer is deemed fast
send an advisory message when a limit (memory,store,temp disk) is full
includes the body of the original message that triggered the advisory as part of the dataStructure field in the advisory message (when applicable). Normally the message body is cleared.
delete inactive destination
inactivity period (in ms) before destination is considered inactive
the prefetch extension is used when a message is delivered but not acked, such that the broker can dispatch another message (e.g., prefetch == 0), the idea being that there will always be prefetch num messages pending. It also allows a transaction batch to exceed the prefetch value.
sets the strategy for handling slow consumers. see abortSlowConsumerStrategy
(v5.12) if 0 or greater, sets the maximum number of destinations that can be created. This is useful to limit the number of hierarchical destinations that can be created under a wildcard destination.
Additional properties for a Queue
Queue only property
use the priority of a consumer when dispatching messages from a Queue
if true queue will not round robin consumers, but it'll use a single one until its prefetch buffer is full
don't use a separate thread for dispatching from a Queue
only page in from store the number of messages that can be dispatched at time
when the first consumer connects, wait for specified number of consumers before message dispatching starts
when the first consumer connects, wait for specified time (in ms) before message dispatching starts
sets the prefetch for consumers that are using the default value
the period (in ms) of checks for message expiry on queued messages, value of 0 disables
(v 5.10) if true, before a persistent message is dispatched by the broker for the first time, the message is rewritten to reflect the possible delivery.
This ensures the message JMSRedelivered header is a reliable indication of possible duplicate delivery.
Additional properties for a Topic
Topic only property
sets the prefetch for topic consumers that are using the default value
sets the prefetch for durable topic consumers that are using the default value
send an advisory when a message is discarded from a non durable subscription
(v5.6) makes all subscribers retroactive negating the need to modify the clients to enable this feature
(v5.6) the period (in ms) of checks for message expiry on inactive durable subscribers, value of 0 disables
The following are examples of different policies that can be customised on a per destination basis
Here is an example of this in use.